(This is a Book Excerpt from "Becoming Agile" by Greg Smith and Ahmed Sidky)
Our project backlogs are full of great ideas. In some cases, we get so excited about a great idea that we disregard all the challenges and jump right in to start development. Sometimes we succeed, and sometimes we have to abort.
Many companies struggle when trying to validate a project’s value. Some companies initialize a project without knowing if it’s viable; other companies scrutinize the value of a project for months before making a decision. There are issues with both approaches.
If you perform minimal validation, you’ll frequently deliver projects that provide marginal value. You may also find that you’re aborting on projects because you overlooked major risks at the outset. In both instances, you waste company time and resources and potentially lose the opportunity to deliver valuable projects.
Companies that perform too much validation have a different set of issues. These companies create so many hurdles and gateways that a considerable expense is associated with project justification. They also minimize their ability to achieve benefits from projects that need to deliver value early: time that could be spent performing the project is frequently lost to the justification cycle.
How do you know when you’ve done enough research? How can you tell if a project is feasible without overkill? We suggest using the feasibility process outlined in this chapter. This process works for two reasons:
- The feasibility effort is time-boxed.
- The team is empowered to question the viability of the project after the Feasibility phase.
Time-boxing the effort prevents a runaway train. A time limit adds urgency to the effort and prevents waste. Acme Media has a 3-day limit for feasibility work. We suggest you create a time limit for feasibility work within your company, too. A good rule of thumb is 2 to 5 days.
Some employees won’t be happy with this time limit: they will say that each project is different and that larger projects require more time for feasibility work. They will also say that setting a fixed time for an activity is anti-agile. We agree with all these points. This is where our second point comes into play: the team can cancel the project at any time.
During the Feasibility phase, you’ll make a quick call about whether to go forward. This will prevent you from missing an opportunity due to over-analysis. You’ll use the Planning phase to learn more about each individual feature; and as you do this, you’ll continue to consider project feasibility. You can still cancel the project if you encounter risks and issues during the Planning phase.
