I have friends who don't think that this post is needed. They believe that everyone has moved to Agile and that Waterfall is dead. Within the last month, I have had other friends tell me about multi-million dollar projects that have just been killed without delivering and others who have only recently become aware of Agile and are still skeptical. I've read recent comments on blogs like "a project manager is the owner of a plan that is milestone driven." (hint: what's the business value of a milestone?)
Many battles have been waged at conferences, in meeting rooms and on web forums over which is better: Agile (iterative and incremental delivery in its various forms) or Waterfall (a sequential process with requirements at the front and a single delivery near the end). The data and the experts have spoken - and continue to speak - and the answer is not waterfall. For an excellent, detailed survey, please read Iterative and Incremental Development: A Brief History by Craig Larman and Vic Basili. IEEE Software, 2003. Despite its age, it's an enlightening read and an eye-opener for waterfall advocates. The X-15 hypersonic jet was developed in the '50s using agile practices!?
For over 15 years, the Standish Group's CHAOS Reports have consistently shown that more projects fail than don't (register at The Standish Group to access to some of these reports under Sample Research). Ah, but what is failure? They define success as on time, on budget and to original specifications (presuming that quality is non-negotiable). This is the Project Management Triangle - time/cost/scope. Failure is defined as not accurately executing to the original plan.
Is this project failure or failure to accurately estimate duration? The fundamental question is how important is on time? I am not asserting that delivering on time is unimportant, but asking what is the relative importance of on time versus the importance of business value - of Return On Investment? A project that finishes on time and to specifications, but is unusable or no longer needed is surely worth less than a project that is highly valued but finishes 10 percent late. Is the former a success? Is the latter a failure? How much different would the value of the late project be had the timeline been padded by an additional 10 percent up front?
Or, is this project failure or excess scope? Are all of the requirements equally important? What if the least important feature weren't included and the project were allowed to finish on time? How much less value would the final solution have - especially if the cost is fixed and the deadline is critical.
The above are instances of take the Project Management Triangle and pick two. Common sense. Agile methods are built for this.
A seasoned project manager, who knows their team well, has their risk mitigation plan in place and has all of the requirements written down can create a detailed Gantt chart and execute. On time delivery is practically assured.
But what are the implicit risks in this plan? What if the users weren't clear in their own understanding of their needs or didn't communicate them effectively? What if the analysts didn't capture them adequately? What if the implementers misunderstood the requirements? What if the business shifted during the life of the project? These issues are not risks - they are certainties!
The longer the project duration without iterations - without customer feedback, the more issues will arise. These implicit risks are why The Standish Group's reports look so similar from year to year. Additionally, how many projects were delivered on time, on budget and to original specifications, deemed a success by IT, but were a disappointment to their customers?
Knowing this does not make project management easier, but it does make it clear that something needs to be done differently. Ok, but how can projects be budgeted? What about systems delivered into a regulated environment (pharma, finance)? How does one do a fixed-price contract? What about late penalties? What of resource planning and opportunity costs? There are no magic potions or silver bullets, but there's been plenty written on this already. I will attempt to address these types of issues in my next post.
A seasoned project manager, who knows their team well, has their risk mitigation plan in place and has all of the requirements written down can create a detailed Gantt chart and execute. On time delivery is practically assured.
But what are the implicit risks in this plan? What if the users weren't clear in their own understanding of their needs or didn't communicate them effectively? What if the analysts didn't capture them adequately? What if the implementers misunderstood the requirements? What if the business shifted during the life of the project? These issues are not risks - they are certainties!
The longer the project duration without iterations - without customer feedback, the more issues will arise. These implicit risks are why The Standish Group's reports look so similar from year to year. Additionally, how many projects were delivered on time, on budget and to original specifications, deemed a success by IT, but were a disappointment to their customers?
Knowing this does not make project management easier, but it does make it clear that something needs to be done differently. Ok, but how can projects be budgeted? What about systems delivered into a regulated environment (pharma, finance)? How does one do a fixed-price contract? What about late penalties? What of resource planning and opportunity costs? There are no magic potions or silver bullets, but there's been plenty written on this already. I will attempt to address these types of issues in my next post.
Thank you for your time and attention.
No comments:
Post a Comment