Breaking the cycle of failed development projects

re: Breaking the cycle of failed development projects

Peter Ritchie — Sun, 03 Jun 2007 05:01:07 GMT

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.

re: Breaking the cycle of failed development projects

Casey — Sun, 03 Jun 2007 13:16:40 GMT

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.

re: Breaking the cycle of failed development projects

ploeh — Sun, 03 Jun 2007 13:38:56 GMT

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.aspx

If your customer doesn't buy it, find another customer

Tim — Sun, 03 Jun 2007 21:23:49 GMT

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-2007

re: Breaking the cycle of failed development projects

Peter Ritchie — Mon, 04 Jun 2007 01:12:47 GMT

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.

re: Breaking the cycle of failed development projects

Adi — Mon, 04 Jun 2007 01:30:08 GMT

You still need to commit to specs:

http://dotmad.blogspot.com/2007/06/agile-in-real-world.html

No, I mean it!

Tim — Mon, 04 Jun 2007 14:19:51 GMT

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.

re: Breaking the cycle of failed development projects

Peter Ritchie — Mon, 04 Jun 2007 14:39:11 GMT

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...

Re: Breaking the Cycle of Failed Development Projects

Jezz Santos — Mon, 04 Jun 2007 19:38:03 GMT

Tom is back in the field again after an honourable stint at patterns & practices, and asks in his

re: Breaking the cycle of failed development projects

Simon Evans — Tue, 05 Jun 2007 13:39:35 GMT

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.

It's the Requirements, stupid!

Doug Ramirez — Wed, 06 Jun 2007 04:10:59 GMT

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...

Doug

re: Breaking the cycle of failed development projects

James Peckham — Fri, 08 Jun 2007 04:40:40 GMT

As our CEO is infamous for saying "it's politics". AKA "someone whined hard enough to get their way". I've been learning and practicing Rational process, which is fairly iterative, but i don't know if it is considered 'agile'. The term 'agile' seems to be this catch-all phrase for a multitude of SDLCs and has become this giant buzzword for the staffing industry (that i work in) to the point where i want to puke every time i hear the word because it's inevitably misused or used without any idea of what it means.

"The iron triangle", does that reference come from the old triangle bells rang for 'dinner time', like on little house on the prairie? Obviously businesses who have no idea about the triangle have never participated in their own business projects! The one i'm in now for example has no 'business' projects, everything is 'each man for himself' and 'hope it comes together'. However, my last place of employment was so 'project triangle oriented' that it long since forgot about treating it's employees with any dignity, respect, or trust. We were all just one side of the triangle, the icky one too, cost.

Since this blog post of yours seems to be a great rant, i'm going to continue my rant about businesses so focused on the project that they lose sight of the people involved. Where i was at the high level vp's, ceo, etc all created projects, those projects were a multitude of other little projects (basically a big project to delegate a bunch of little projects), which in turn became projects that delegated out a bunch of littler projects to people below them, and so and until finally the people at the bottom (our helpdesk) was the only team actually doing any of the real foot work on any of the projects... we did implementation, maintenance, software/hardware/network support, conversions, upgrades, recovery, training for the end users (rather the lack of training or documentation meant they called us for every little thing), we created our own support knowledge base, we weren't allowed to escalate to tier 3 support without a congressional appeal, and all of our reviews were completely subjective even though they were represented as being objective based on ridiculous statistics that incented the whole helpdesk to close issues before resolving them. Such as closing calls within 4 hours, getting penalized for escalating issues above the group (even if congress was in favor!), and more points for software than for hardware (causing hardware to get ignored).

Anyhow, when you write out a project plan, plan all the way down to the lowest man on the pole to be sure everyone's doing their equal part!

re: Breaking the cycle of failed development projects

james peckham — Fri, 08 Jun 2007 04:48:15 GMT

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! :)