Variable Schedule
When your schedule is allowed to vary, you are better able to focus on time-to-market considerations and other competitive considerations. A common strategy is to release a system incrementally instead of all at once. The initial release can be the hardest to predict because you know the least about your stakeholders actual needs at the beginning, you haven't built up a good working relationship with them, and you haven't established a team rhythm yet. The first release must implement sufficient and cohesive value for your stakeholders yet still be timely. Subsequent releases must also have the same characteristics, and over time you'll find that you'll be able to stabilize the release dates and thereby bring greater predictability to your schedule.
It's important to understand that even when your schedule is allowed to vary, you still need to plan for certain types of inflexible events that just aren't flexible. Examples include your operations department having a fixed release schedule that you must conform to, needing to schedule in advance technical writers to produce external documentation or translators for your internationalization efforts, a team member is getting married and will be going on her honeymoon, or a training course that several team members want to attend is scheduled at a specific time. The implication is that your schedule may be partially variable and partially fixed.
Release dates are often fixed due to regulatory concerns or for competitive reasons in the marketplace. These dates may not be as fixed as you think—regulations often change and market-driven dates are often based on perceptions that can change. Furthermore, the fact that a large percentage of IT projects are delivered late clearly implies that many software development project schedules vary. Instead of having circumstances late in the project force you to make unpalatable scheduling decisions anyway, perhaps it's better to simply choose to vary your schedule from the start.
Egads, I've Been Constrained!
So, what do you do when one or more of the three management factors of the iron triangle are constrained? Table 1 summarizes the strategies available to you for each combination of constraints that could be inflicted upon your project team.
As you've seen, you can still take an agile approach to development even when constraints are imposed upon the team. The secret is to understand the implications of the iron triangle and then act accordingly. Project management is enhanced because if you identify which factors can vary, you can still work as effectively as your constraints let you—all is often not lost. Portfolio management, where the goal is to identify and then execute IT projects in a manner that reflects the goals and direction of your organization, is also enhanced because you can start projects off on the right foot when stakeholders understand the implications of constraining the three project factors.
| Constraints | Strategy |
| None | Count yourself lucky. |
| Fixed Resources | Address work items in priority order, allowing them to vary as dictated by your stakeholders. Release the system incrementally, the initial release being at the point where you have implemented sufficient cohesive value for your stakeholders. You may need to cut the project short if you discover that your burn rate is higher than expected. |
| Fixed Scope | Ensure that very good modelers are involved with up-front requirements definition because you rely on getting the requirements right at the very start. Note that the longer the project goes the greater the chance that the requirements will change, regardless of how "fixed" you think they are. Ensure that money is being spent wisely by delivering working software regularly. |
| Fixed Delivery Date | Implement the work items in priority order, allowing them to vary over time. Validate expenditures through the regular delivery of working software. |
| Fixed Resources and Scope | Pad the budget as much as possible to give you some flexibility, then set the delivery date to reflect the work to be done. As the project progresses, update the delivery date as needed to reflect the team's actual velocity. |
| Fixed Resources and Delivery Date | Identify an appropriate iteration length, i.e. two weeks, determine the number of iterations the delivery date allows, then divide the budget by this number to determine your average budget per iteration. Implement the work items in priority order, allowing them to vary as appropriate, thereby ensuring that stakeholders receive the greatest ROI. |
| Fixed Scope and Delivery Date | Do a really good job of modeling the requirements at the beginning of the project and estimate them to the best of your ability. Determine the number of iterations that you intend to work to, then assign work items in priority to the iterations. Initially, pad your schedule with a few empty iterations at the end so that work can slip if required. |
| Fixed Resources, Scope, and Delivery Date | Either lift one or more constraints or cancel the project because your project is pretty much doomed to failure. If you deliver at all, your system is likely to be late, over budget, and of low quality due to "shortcuts" took during development. |
Scott is a DDJ Senior Contributing Editor and author of numerous IT books. He can be contacted at www.ambysoft.com/scottAmbler.html.
