Breaking the cycle of failed development projects
It's been a bit over two weeks since I arrived back in Australia, and things are slowly coming together. We're still waiting for all of our stuff to arrive, and for that matter a place to put it all - but at least it's sunny every day, and I'm enjoying my new role at Microsoft's Solutions Development Centre.
While it is strange going back to the world of consulting, I'm sure my tenure with the patterns & practices team will give me some new perspectives for the role. As an example, the subtle persuasion of people like Peter Provost has made me an agile development convert (although certainly not an expert!). While I believe there is a growing trend towards more agile approaches in many organisations, the p&p team is definitely ahead of the curve - but I'm very interested in applying what I've learned about agile development in my new role.
But I suspect it will be an uphill battle in many cases. One of the first tasks that was thrown at me was to read through a draft "request for tender" document from a customer. This document was essentially asking for a fixed scope, within a fixed delivery schedule, for a fixed price. I realise there is nothing particularly unusual about this request. But we all (hopefully) know that it can't be done, short of the odd fluke. Each project is governed by the "iron triangle" of scope, schedule and resources. You can choose which ones are fixed and which are variable, but you can't fix all three without sacrificing quality, unless you are extremely lucky and everything comes together within the expected parameters. Depending on which reports you believe (such as the Standish CHAOS reports), only 15-30% of projects finish on schedule and on budget, a similar proportion fail outright, and the remainder fall somewhere in between with the project delivered but not meeting expectations.
The thing I am trying to understand is why we (meaning both the development teams and the business groups) insist on playing this game by pretending it can all be done. Business, of course, wants the certainty on what they will get when and for how much. Most development and consulting shops will take a project with a relatively detailed (but never final) requirements list and fixed schedule, and happily provide a fixed price quote (probably with a hefty risk premium attached). But with such a poor project success rate, surely everybody should know that the emperor has no clothes? My cynical explanation is that this model makes it very easy for everybody to blame someone else. The business can blame the development teams for failing to meet the agreed deadlines or requirements. The development teams can blame the business that the initial requirements were not detailed or accurate enough. Everyone walks away vindicated that it wasn't their fault that the project failed.
This is where agile development approaches should really be able to help. I've had no formal training on agile so forgive me if I misrepresent anything, but as I see it one of the most fundamental concepts is that scope is never fixed, but is aggressively and continuously prioritised. Nobody should promise exactly what will be delivered at the end of the project, although it makes sense to do some upfront analysis on the minimum and preferred scope to get a reasonable idea of the how long it will take and whether this will fit into the proposed budget. Another key agile concept is the project will be broken into multiple iterations and releases, each of which will be deployable and provide real business value. This approach allows requirements questions to be addressed continuously based on customer feedback, allows scope to be reprioritised throughout the project, and mitigates "big bang" releases that often result in the business saying "this is just what we asked for, but not what we want". Finally, in theory at least, a well-run agile project should never ever run over time or over budget. It may not deliver all of the functionality the business wanted, but the functionality that was delivered should at least be usable and valuable, and more important than any scope that was not delivered.
Anyway, enough of Agile 101. My real question is more about psychology than methodology. What will it take to get people to understand, and act on the fact, that the way most projects are run doesn't work? Most of the agile success stories I hear about (including p&p, it turns out) have been grass-roots campaigns from developers who slowly convinced management teams in their own organisation to move to more agile approaches. This is a great start, and I guess it's gotten us to where we are now. But I'm not personally familiar with any examples of an external systems integrator or development shop successfully convincing a non-agile customer to think about their development approaches differently. Things get even harder in a tender situation, where the customer will have set ideas on how tenderers should respond to allow for an "apples to apples" comparison. If one response says "yes, we will deliver all of the scope in X months for $Y", and another says "We will deliver something in X months for $Y, but we can't tell you what it will be yet", you can bet the customer will choose the first option, even if the second has a far better chance of success.
I'd love to hear your thoughts on all of this, especially since I've been living in an alternate reality away from the consulting world for quite a while. Is the general state of software development really as bad as I make out? Is agile development a critical factor in addressing these problems? Have you been successful in introducing agile approaches in your own organisations or to external organisations? Is it possible to win a tender by proposing an agile approach when the customer wasn't expecting it? What do you think it will take to break the current cycle of blame and get everyone to think differently about software development?
Comments
Anonymous
June 02, 2007
I don't know where the term "Iron Triangle" comes from, but the cost/scope/time triangle (which usually contains "quality" in the centre) is a project management artifact and is termed the "Triple Constraint" in PMI-based project management circles. It's far from "iron", it's meant to show that changing any of the three constraints(time, scope, or cost) without changing (or considering) the others will impact quality. If none of the three constraints need to change you completed the project on time, on budget and in scope. If any of those values are wrong then something must give. Agile recognizes that scope can (and usually does) and builds that into the process. Processes (like waterfall) that assume scope doesn't change throughout project's life cycle are ignoring reality. You just can't compete in today's market without accepting change and being responsive to it. There's nothing wrong with promising what will be done (the scope) at the end of a project (that's somewhat the point of any project). It's unrealistic to expect scope, time, and cost won't change throughout the project life cycle, considering the PMI definition of "project" includes "create a unique product", which implies some, if not all, the work has never been done before (in which case you can't possibly know how long it will take or the cost involve to deliver the scope). The benefit of Agile is that you've got fully functional deliverables at the end of each iteration. This allows the project members to be able to accept change between iterations much easier than some methodologies because that change, in theory, will only affect future work and past work can still be used. With some methodologies, accepting change at any point usually impacts all past work because of the inherent dependencies resulting from an all-at-the-end deliverable. Whatever iterative project management methodology that is used, it's always best to socialize status with the stakeholders when one of the constraints has been discovered to be wrong (i.e. it needs to change). The earlier the stakeholders are informed and involved the least amount of pushback will be encountered. I've never been on a project where informing the customer that something has to give as soon as it is known has caused much grief. Saying "We're sorry, but we've realized today that we just can't do what you want in the time-frame". Telling the customer close to the end delivery milestone that it can't be done is always going to garner the most pushback. If the project team is responsible for the cost/time based on the customer's scope and it's off by a lot, they should think about getting someone who knows better how to estimate. If the customer is mandating all three constraints, I would explain that's just not possible. I don't think that most customers would really care what approach you use, they really just want to get what they asked for and be "in the loop" in the meantime. Using Agile will allow you to be responsive to inevitable change with a minimal impact. Again, if you're constantly telling the customer one or more of cost/time/scope needs to change, you've got a problem, regardless of whether you use Agile or not.Anonymous
June 02, 2007
Convincing customers to use Agile is one hurdle, the other is to actually make it work. I have just convinced our managers to let the next phase of our development work on an Agile basis (SCRUM + XP) using the most obvious trick ... I did a small project for them in an Agile fashion ... and it was delivered on time, with good functionality that closely matched the business owner's expectations, and most importantly, they felt involved. But from an internal [persepctive that works fine, doing it externally, that's a trickier issue... perhaps take the approach of 'we contract to you for 1 month on a rolling contract, at any point you don;t like what we are doing, you fire us and get someone else.Anonymous
June 02, 2007
Over at Ative's blog, we had a pretty interesting discussion about the subject of dealing with fixed price projects in agile organizations. The discussion is mostly in the comments, but take a look: http://community.ative.dk/blogs/ative/archive/2007/01/08/Lean-Software-Development.aspxAnonymous
June 03, 2007
Agile delivery only works when both customer and supplier are totally bought into the process, due to the amount of trust and interworking required between both parties. I remember working on waterfall projects, when the whole thing was 95% done for months at a time. This leaves the customer extremely untrusting of the IT delivery team, as there is no change to measure. However, if you can persuade them to break down their requirements into prioritised stories, then you can show them, sprint on sprint, that their project is getting delivered, and that the delivery team is highly measurable. Plus you let them change their mind! I reckon that if you can persuade your customer to accept fixed time, fixed cost, and variable scope, with get out clauses if velocity is not measurable within a month then you are onto a winner. You have to allow time for estimation to stabilise within any given team. When they realise this allows them to change their mind about what they want mid project, they really need their heads examined if they still want to tell you a bunch of deliverables and come back 6 months later to failure. Is consistent delivery more important to your company than risking reputation on one project that you are sure will fail? If so, don't take on that project! You do need to persuade your business partners. Persuading them with techy jargon (XP, Continuous integration, TDD) etc won't help. You need a business metaphor, and Mary Poppendiecks Lean approach is just the ticket. Try this video for size - http://www.infoq.com/interviews/poppendieck-lean-2007Anonymous
June 03, 2007
Tim: why does Agile delivery only work if both sides buy into it? The development team can continue to delivery complete and tested software at the end of every iteration. If the customer does nothing with any of the deliveries but the final delivery, worst case is the project was very organized and was able to accept change in an efficient way. No methodology prevents problems occurring from change, but some methodologies try to mitigate those problems by recognizing change and building its inevitability into the process to varying degrees.Anonymous
June 03, 2007
You still need to commit to specs: http://dotmad.blogspot.com/2007/06/agile-in-real-world.htmlAnonymous
June 03, 2007
Adi - specs bring in the money. Commit to them on an iterative basis. Deliver them on an iterative basis. Peter - If either side still belives that all of scope, cost and time can be fixed, then, as Tom points out, things probably will fail. Yes, the development team can use agile techniques without the customer, and this is a common pattern. But unless the customer has embraced the principle of flexible scope the chances of failure against one of the three constraints is still likely; though the visibility of impending doom through iterative delivery means that this can maybe me mitigated, as there are early warning systems in place.Anonymous
June 03, 2007
Tim: I agree with "commit on an iterative basis", that's the process of change control. Committing to one spec at the onset of the project and not accepting change is a recipe for disaster. Agreed, if the customer does not embrace change and the project manager does not manage change then failure is eminent. I've dealt with many clients that didn't want to deal with a formal process after the spec was baselined; but they weren't resistant to changing what the final product was when delivered (and almost 100% of them introduced change). You have to manage change and CYA in a scenario like that; but the in-house development process can still be Agile. I've never run into a client that didn't want to know about problems as early as possible. Granted, if you're constantly informing them of problems with schedule or cost then you've got a problem with your development process...Anonymous
June 04, 2007
Tom is back in the field again after an honourable stint at patterns & practices, and asks in hisAnonymous
June 04, 2007
Your comments about tender situations is spot on. And really the only answer is educating the customer about the realities of how software is developed. In my experience, this is much easier if the customer is development facing themselves, but it can be extremely hard to convince decision makers. In reality, changes in software happen, and it is a question of how quickly you can convince someone else that this is the case. One further point. Alot of customers are used to software architects using analogies of designing buildings as a way of explaining how we develop software. I think this view causes confusion amongst customers when we try to sell Agile, because if the building analogy held true, you would have to use a waterfall method, unless you fancied knocking the building down several times.Anonymous
June 05, 2007
IT projects that fail almost always fail due to a lack of defined Requirements. After that, IT projects usually fail because Requirements aren't analyzed and managed. Now before you start flaming me, note that I said ‘almost always’. And besides you don’t want to flame me. You won’t like me when you flame me ;-) Did you know that with a good set of requirements that are properly analyzed and managed, a good team of developers can use pretty much any methodology and will succeed. And almost any technology that the team of good developers uses will not be a material factor in their ability to succeed. I’ve been on project teams that have done fabulous things with Prolog, ANSI C, PHP, and I've also been on projects that fell flat on their face so hard using Java, C++, and C# that you probably felt the ground move when the plug got pulled. I don't mean to be flip about process, I take it very seriously, but the idea the development process, a subset of the SLDC, can make up for the failures of business case development, creating a meaningful vision, enumerating the features and quantifiable benefits of a solution, and detailed requirements for how they will satisfy the features which will ultimately allow a business to obtain their ROI, well it's impossible. Projects also fail because 'management' thinks developers writing code is like builders hammering lumber together. Who knows what it is they're building, but since they are building then progress must be being made, right? Oh wait. I didn't was a 3 car garage, I wanted a 3 bedroom house. Oh well... DougAnonymous
June 07, 2007
The comment has been removedAnonymous
June 07, 2007
TO DOUG: that's exactly the point tom was trying to make, each side wants to point the finger at eachother instead of taking responsibility. You say it's management's fault for you hammering on nails all day and them sitting complacently, but did you ever say "hey come look what we've built, is this what the users wanted?" RUP (which is agile and iterative i think) does formally say, "do a small iteration, build executable software, show it to your user, refine the requirements, do another iteration..." repeat until you get the end result that fits the user expectation. This is a process that takes responsibility and evenly distributes it across everyone involved via "Communication" and "Iteration"... flame on! :)