Software Development
March 2003
Its your first day on a new project; youve just left the kick-off meeting and the energy is palpable: A senior vice president explained the projects importance, management promised complete support, and key stakeholders pledged their loyalty to your team, which is staffed with experts. Why, in the face of all this bonhomie, do you have that sinking feeling? Because you know that the project will failand theres nothing you can do about it.
The Iron Triangle
Failure is inescapable because the project is constrained by the iron triangle:
The powers that be made it clear that none of the three critical factorsschedule,
budget and scopewill be allowed to vary. When this triumvirate remains
rigid, without adjusting to the inevitable changes that crop up in every development
project, the triangle becomes unbalanced and will break. If you try to define
the exact schedule, the exact cost and the exact scope to be delivered, you
virtually guarantee failure because you have no room to maneuver. The only course
left to you is to let quality sufferrarely an option. To be sure, if you
set the factors to a very small scope, a very large budget and long schedule,
success might be possible, but most organizations desire the exact opposite,
without providing sufficient funds to develop all of the requirements within
the time allotted. Somethings gotta give.
When each factor is supported by a protagonist with a singular focus, it becomes difficult to negotiate a reasonable approach. The IT department will insist on high quality, the finance department will insist on a streamlined budget, senior management wants the system now, and the user community will insist on a robust set of features. If no one budges, the project team is positioned for failure. |
How Long Will It Take?
The Project Management Institute (www.pmi.org)
defines time as the first corner of the iron triangle. Unrealistically tight
scheduling is a familiar problem for most developersaggressive schedules
are fine; unattainable ones are not. Equally troublesome is setting a multiyear
schedule without interim deliverables, guaranteeing that no practical progress
will be made for the first year or two because of the lack of motivating milestones.
Agile project teams organize their schedules into short iterations, typically between one and four weeks, during which they implement a subset of the requirements. The primary product is working software that fulfills the most important requirements to date. With this approach, you can set the schedule, but leave some leeway in terms of the product delivered at deadlineor you can set the scope, but allow some flexibility in the time frame. By stretching one corner of the triangle, you dramatically increase your chance of delivering a working system, at the negligible cost of additional management uncertainty.
What Will It Cost?
Budget is the triangles second corner. Here, an inflexible attitude will
almost always doom a project. Funds are often mismanaged, assigned early on
to rigid categories, resulting in artificial under- and over-funding on the
same project. How often have you seen teams secretly take money from the training
bucket to pay for development tools that they desperately need?
Are you ready for a shock? I believe that annual budgets are the bane of effective management. First, they encourage people to focus on financial issues only at budgeting time. Second, they promote a bucket mentality: This year, we have $50,000 to spend on training, $10,000 for books and $20,000 for tools instead of We have $80,000 to spend wisely. Third, they create a stack of money mentality. Although thinking that you have $80,000 to spend wisely is a step in the right direction, better yet is the attitude that you should invest whatever you need to get the job done. No, you cant expect an unlimited budget, but you will spend what you have wisely and adjust your strategy as required.
How can you manage project resources in an agile manner? Think of money as flowing from a tap instead of from a collection of prefilled buckets. The traditional approach is to define a project as a six-month, half-million-dollar effort. This is a fundamental mistake. Instead, give the team $100,000 for the first month. At the end of that time, evaluate their progress and base next months resources on their track record. If they did a good job, let them have $125,000; if they did a poor job, cut their budget to $75,000 and put them on notice of cancellation. Scrum is one proven method (www.controlchaos.com) that espouses this philosophy.
The advantage? By directing your resources to the teams that are cost-effective, you get the most value for your investment. The disadvantage? You dont know what youre going to spendbut thats the reality of all budgets. The Canadian government recently discovered that its national gun registry project went 500 times over budget: Originally estimated at $2 million, the agency spent $1 billion before it got caught. The fundamental trade-off? To ensure that your money is spent wisely, you dont exactly know what youll get or exactly when youll get it.
What Will I Get?
Scope forms the triangles third corner. Traditional project teams mistakenly
try to define most of the requirements early onthe classic Big Requirements
Up Front (BRUF) tactic. BRUF adherents must understand what needs to be built,
so they can accurately plan and develop a robust system design. This approach
doesnt reflect the fact that requirements change as knowledge and environments
evolve. Worse yet, when people try to get everything they want into a single
release, requirements bloat beyond recognition. At best, this approach results
in building too much of the wrong thing, while at worst, nothing gets built
at all, because youre too busy trying to get the requirements right.
Agile developers invest some timeperhaps a few hours or daysinvestigating the systems initial, high-level requirements. This gives them a handle on the scope and enables them to start assigning functionality to iterations based on priority. Agile developers implement the highest-priority requirements in each iteration, ensuring that they deliver the greatest value to their stakeholders at all times. They also deliver working software in each iteration, thereby providing tangible results from the projects inception. New requirements are prioritized and put onto the stack for future iterations, enabling a simple yet effective change-management process. The primary problem? Its difficult to define exactly what youll have after six months of effortbut you do know that youll have the most important functionality built with the resources available to you at the time.
Will It Be Good Enough?
Quality is at the center of the iron trianglebut that center will implode
when you refuse to manage schedule, cost and scope properly. Nobody is willing
to settle for a low-quality product, though that much-desired element is in
the eye of the beholder: To developers, a high-quality system is easy to maintain
and evolve; to users, perhaps its a system thats simple to use.
Reviews, which enable other sets of qualified eyes to examine artifacts for defects, are the traditional way to guarantee quality. But is this the best approach? No. Instead of looking for defects after the fact, wouldnt it be better to create an error-free product to begin with? From the agile viewpoint, the desire to hold an inspection is an indication that youve failed to be effective elsewhere. For example, if people are qualified to validate that the system meets the corporate architecture standards, why didnt they work on the architecture at the outset?
On agile projects, quality comes through collaboration. Coding standards and modeling guidelines help, as does test-first development and active stakeholder participation. Extreme Programmings practice of collective ownership is one way to promote high quality; when many eyes are on the watch, mistakes are more likely to be found and fixed. Furthermore, the use of generalizing specialists (see "Isnt That Special?", Jan. 2003) ensures that developers have a sufficiently wide range of skills to understand every aspect of the software theyre building. By promoting effective collaboration, you ensure that the qualified eyes are present from the start to ensure a high-quality product.
Its a Matter of Trade-Offs
The most effective managers realize that, to ensure project success, the iron
triangle has to give, accommodating change as the need arises. At the XP/Agile
Universe conference in 2002, the Software Engineering Institutes Watts
Humphrey, father of the CMM, made a statement that goes to the heart of the
matter: What people really want is a high-quality system that implements
everything they want, at no cost, right now. Everything else is a trade-off.
By maintaining the elasticity of these three critical factors, making adjustments
as the project evolves, you can successfully build and deliver high-quality
working systems that meet your users needs.
Scott Ambler is a senior consultant with Ronin International Inc. His latest book is The Elements of UML Style (Cambridge University Press, 2002).