Another risk with plan-driven approaches is that having a good plan that covers all the details as completely as you’d like takes a lot of time. This means implementation starts later, and if something causes you to change the plan once implementation starts you have wasted a lot of time.
When things go wrong when you are using a plan-driven approach you may hit a deadline with either a non-functional system or a system that works but doesn’t implement the most important features. Or you may discover that features that took lots of time to implement weren’t as important to end-users as the product manager expected. This a problem that I’ve seen frustrate many people.
I’ve seen many projects in which people worked late to implement a feature than ended up not being used. In some cases the team members works hard to finish as much as they could before a deadline only to deliver a system that wasn’t successful because of a small feature that didn’t get finished by the deadline.
Another common situation is that the team that delivers a somewhat complete system that was not tested thoroughly, so that it ends up being unusable. In the latter situation, a less complete, but better working system might have resulted in more business value. By focusing on managing risk and measuring the success of the project solely based on the goals of the original plan, you can lose opportunities to deliver useful systems that solve problems. With this in mind, people sometimes look to agile as a solution.
Agile Risk Management
The agile approach to risk management is based on frequent feedback and iteration. The development team and the product owners are communicating frequently in a controlled manner in order to help keep the project moving in a direction that delivers the highest value features first. Rather than defining all the steps in the plan, you spend time and energy defining the high-level goals and constraints of the project, and track progress against these goals and constraints.
You may still have a master plan that outlines the boundaries of what you’re doing. The difference is that you revisit the plan periodically to monitor progress against that plan. You spend more time and energy planning the high-priority work that you’re doing sooner.
Based on your progress and other business constraints you can then adjust your plan. In the example of running an errand, you might have time constraints and a few things that you really need to get at the store. If your child takes longer than you expected to get out of the house, you might then adjust your plan to only make the most important stops.
On an agile project you might revisit the plan every two weeks (or more frequently). To fully benefit from revising the plan periodically you also need to insist that you have a usable software system at the end of each iteration. The combination of frequently iterating on the plan and having continually working software means that you can deliver something sooner, even if your plan changes dramatically. Even when something goes wrong in an agile project, you have some faith that you can deliver a system that has implemented the highest priority features.
A challenge in adopting agile is to get everyone involved to agree that agile planning is a reasonable approach. Once you have done this, you need to change your project management and technical practices to make the approach work. This means establishing practices to allow for the iterative planning that is part of an agile project. An agile plan only works if the code is also nimble enough to adapt, so you need to establish the technical practices that make it possible to deploy a system frequently, and evolve code to meet changing requirements easily.
Team members can’t be agile unless they acknowledge that there will always be uncertainties and that they cannot plan for everything. Rather than taking comfort in a plan, they take comfort in the knowledge that they can adapt to change and still be successful.