This work is intended to be read by people who work on software projects, and those who are involved in managing software projects.
If you work collaboratively with other people in a software process, you should find Risk-First a useful lexicon of terms to help describe the risks you face.
So, if you are interested in avoiding your project failing, this is probably going to be useful knowledge.
Risk-First is a toolkit you can deploy to immediately improve your ability to plan your work and avoid pitfalls. But that’s not the only goal. Frequently, we find software methodologies “done to us” from above. Risk-First is a toolkit to help take apart methodologies like Scrum, Lean or Prince2, and understand them.
Methodologies are bicycles, rather than religions. Rather than simply believing, we can take them apart and see how they work.
All too often, Project Managers don’t have a full grasp of the technical details of their projects. And this is perfectly normal, as the specialisation belongs below them. However, projects fail because risks materialize, and risks materialize because the devil is in those details.
This seems like a lost cause, but there is hope: the way in which risks materialize on technical projects follows a pattern. With Risk-First we attempt to name each of these types of risk, which allows for a dialog with developers about which risks they face, and the order in which they should be tackled.
Risk-First allows a project manager to pry open the black box of development and talk with developers about their work, and how it will affect the project. It is another tool in the (limited) arsenal of techniques a project manager can bring to bear on the task of delivering a successful project.
Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.