How do you know when you’re signing up for Mission Impossible? If your project has a short time frame to design, build, and deliver, and there’s high risk around the requirements and technology, there’s a good chance your project scenario is Mission Impossible. In Scenarios, Stories, Use Cases: Through the Systems Development Life-Cycle
Example Scenario
Alexander and Maiden show a table that summarizes the project situation:
| Questions | Answers |
|---|---|
| Is there a business need to get the product to market in the shortest time possible? | Yes |
| Is there a very rapid rate of technological evolution relative to design and delivery lead-times (implying very short product lifetimes)? | Yes |
| Do you really know at the outset what exactly the problem is, what the requirements are, what solutions might be relevant, or whether the stakeholders really know what they want? | No |
| Is likely candidate technology proven? | No |
| Do you have doubts about the validity of the requirements discovery process? | Yes |
Short Time Frame, High Initial Risks in Requirements and Technology
According to Alexander and Maiden, you have a Mission Impossible scenario:
In this case you have a problem! You are faced with the challenge of designing, producing, and delivering a system in short order with high initial risks in the area of requirements and technology. This is very likely mission impossible and probably doomed to failure. You should ask yourself if you are in the right business.
Key Take Aways
Here’s my key take aways:
- Avoid Mission Impossible scenarios.
- Find ways to turn Mission Impossible scenarios into scenarios that increase project success.
- Watch out for projects where the timeline is fixed and there’s high risk around the requirements and technology, unless the scope is flexible.
Given today’s short project cycles, the rate of technology change and how difficult it is to nail requirements (user, system, and business), every software project could sound like Mission Impossible. I think the real key depends on whether there’s flexibility of the scope. In general, I find more project success when projects are interval-driven and the scope if flexible.
