Skip to content

Audience

Rob Moffat edited this page Jan 4, 2019 · 8 revisions

This work is intended to be read by people who work on software projects, and especially 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.

But here's a warning: this is going to be a depressing book to read. It is book one of a two-book series, but in Book One you only get to meet the bad guy.

While Book Two is all about how to succeed, this book is all about how projects fail. In it, we're going to try and put together a framework for understanding the risk of failure, in order that we can reconstruct our understanding of our activities on a project based on avoiding it.

So, if you are interested in avoiding your project failing, this is probably going to be useful knowledge.

For Developers, Testers and Business Analysts

Risk-First is a tool you can deploy to immediately improve your ability to plan your work.

Frequently, we find software methodologies "done to us" from above. Risk-First is a toolkit to help take apart methodologies like Scrum, Lean and Prince2, and understand them.

Methodologies are bicycles, rather than religions. Rather than simply believing, we can take them apart and see how they work.

For Project Managers and Team Leads

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 ways in which risks materialize on technical projects is the same every time. With Risk-First we are attempting to name each of these types of risk, which allows for a dialog with developers about which risks they face, and the order 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.

Clone this wiki locally