August 03, 2007
Agile on a Fixed BudgetVariable 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.
Table 1: Strategies.
Previous Page |
1 Agile on a Fixed Budget
|
2 Variable Scope
|
3 Variable Resources
|
4 Variable Schedule
|
 |
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
