May

13

Time, Resources, Scope… and Quality.

Posted by Keith McMillan

May 13, 2010 | 1 Comment

Project managers will sometimes refer to the “iron triangle” of time, resources and scope for a project. The idea here is that each of these facets of a project are the leg of some theoretical triangle, and you can adjust your project by making one of the legs shorter if you need to.  How does that relate to software projects?

In a software project, we almost always have significant unknowns. We’re typically trying something we have not tried before. If we’d built a system just like the one we’re building now, then I suggest we shouldn’t be building the one we’re currently building. By definition, we don’t know the amount of effort we’re going to need to put forth to solve the problem. Heck, it might not even be solvable.

Traditional project managers start off by asking for a “rough estimate,” just something to put on the schedule for the task at hand. A skilled architect or developer cringes at this point, because they know what’s coming next.

“I don’t know, we’ve not tried to do this before,” they say. The project manager responds “yes, I know, I just need to put down something. Please just give me an estimate.”  Putting on my project manager hat for a moment, we do need some order-of-magnitude estimate for a task, just to evaluate whether the thing we’re trying to do is worth doing: if it’ll pay for itself.  The problem arises that many times, this initial rough estimate becomes written in stone, and people are held accountable if they don’t meet it.

The traditional approach to software development is then to flog the team to meet their “commitments.” If the team is smart, or they’ve done this before, it means they’ve actually given you inflated estimates, and when they encounter the inevitable bump in the road, they’ve got buffer to take the hit. Smart PMs will also build contingency into their project plans, and this can help as well.  Some projects, though, are squeezed like they’re in a black hole: the deadline can’t slip, the staff has to stay the same, and we must have everything we asked for.  In that situation, I suggest there’s really another leg of the triangle: quality.  Well, more accurately, I think quality sits in the center of the triangle, and I’ll explain why in a bit.  First, I have to say that I don’t believe this is an original idea on my part, putting quality in the center, but at the moment, I’m unable to put my finger on the original author.

If I hold rigidly to time, resources and scope of the project, there’s another dimension can be compressed, and that’s the quality of the product that’s built. If you don’t care how good it is, how long it lasts, or how hard it is to modify after it’s done, then by all means, quality is a dimension we can short-change.  This discussion, however, should happen out in the open.  I’m OK with the idea that a low-quality solution may occasionally be what the business needs, so long as we all agree that the solution will be of poor quality.  I’ve seen far too many teams get backed into this corner, and frankly the only way out is to produce crap in order to meet the deadlines.

When adjusting a “traditionally” run software project, time and scope are inflexible, and more people get added to the project. This, unfortunately, has the opposite effect of the one desired.  Adding people to the project means that new people have to be brought up to speed on how the software works, what the design themes are, and myriad other issues.  This distracts the team that was already working on the project, and results in a short-term reduction in the amount of work that can be done, rather than an increase.  If you’ve got time to absorb this short term hit, then maybe you can make up for it, but by the time a typical project recognizes they’re behind, it’s late in the game, and you can’t afford to take that hit and recover.

An agile project holds time and resources fixed, and varies the scope delivered.  Why take this approach?  Research shows (and common sense would also tell you that), despite protests that “every feature is number 1 priority,” the value of features we build varies considerably, and there are features build in to software that is seldom, or never, used.  If we consciously put pressure on the scope of a project, the theory goes, we prioritize the most important features, and de-emphasize those of lesser importance.  This is good, because we now get the maximum payoff for the money we spend building the software.  It also places a higher emphasis on the quality of what we build, since we’re building important features, hopefully the need for quality is self-evident.

Why aren’t more projects run this way? In order to allow scope to vary, a whole constellation of stakeholders need to be on board, including project managers, customers, executives and the development team themselves.  If we continue to irrationally insist that “everything is priority 1,’ then it’s my contention that what we’ll get out the other side will frequently be of poor quality, and will contain features that could have been omitted.

Further, it’s difficult to support this model in a fixed-bid type of environment, such as I frequently see as a consultant. Customers want to control all three legs of that triangle: they want you to commit, in a contract, to scope, time and cost (and cost = resources).  That means as a consultant, I have to take a really good guess, pad it with contingency, and then rigorously prevent any change to scope via a change control process.  This doesn’t work in either my interest or the customers, but that’s the only way that many customers can visualize working.  They want the flexibility to change the scope (typically to add to it, but sometimes just to change something), and each change must be evaluated to determine if it affects the commitment we’ve made to time and resources.  In short, some customers want you, as the contractor, to assume all the risk.  This means that my contingency gets bigger.

I have to sympathize with customers in this situation as well: they don’t want to get taken to the cleaners by getting less than they paid for.  If we fixed-bid each iteration, and it’s short, then at the very least, they get visibility into how the work is going on a bi-weekly basis, and can decide not to continue at any time.

Let’s contrast that with another, idyllic world: If I contract with my customer iteration by iteration, for a fixed bid, I know exactly how much it’ll cost me, it’s simply the cost of the team for the duration of the iteration. If the scope is allowed to vary, well, that makes the customer a bit uncomfortable, so we minimize the amount of time they’re uncomfortable by making the iteration really short, like two weeks.  After that two weeks, they get to see what we’ve done, and as we progress iteration by iteration, they get an empirical estimate of how long all the work will take, based on how long it’s taken so far.  They get to vary the scope, and my need for a big contingency goes away.

I think, unfortunately, it’s a bit of a pipe dream. We’ve all been burnt far too many times in business to make this a comfortable arrangement, but it does work.  It makes me fear that we’ll continue to see teams compress quality rather than scope of a project, and I’m uncomfortable with the products they produce as a result.


Comments

RSS feed | Trackback URI

1 Comment »

Comment by Peter H. Coffin
2010-05-13 11:13:13

Quality doesn’t really sit in the center of the chart, though it’s sometimes easier to draw that way. It’s off in the Z-axis; it’s its own tone in the harmony. It’s just a little too close to “Scope” in its characteristics to get talked about much, and you need to shift the pitch (for either metaphor) to pay attention to it. Go grab a 4-sider die, sight along one of the edges, label the front corner “Scope”, the back one “Quality”, and the other two “Resource” and “Time”. What do you see then? Why, the Iron Triangle staring at you. With a sloppy hidden bit. And what goes into that hidden bit? Pretty graphics. Cross-browser compatibility in web applications. A very large chunk of it is help files, documentation, and cross-reference. Better input handling. Error messages that provide more than a code that uniquely identifies where something blew up.

Now, how many software packages that were otherwise very big Triangle-wise got delivered missing some of the above?

Reply to this comment
 
Name (required)
E-mail (required - never shown publicly)
URI
Your Comment (smaller size | larger size)
You may use <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> in your comment.

Blogroll