Emerging Tech

Project management: The lie of the "three levers"

The three-level theory says that one can move any two of the levers (scope, timeline, or cost) and the other will move independently of the others. In this blog, Patrick Gray disputes that assumption.

Most of us have seen the famous "three levers" diagram of project management. The story goes that one can move any two of the levers (scope, timeline, or cost) and the other will move independently of the others. For example you could increase the scope of a project and decrease the timeline, but your costs will rapidly spiral up. Or if you cut costs and keep your scope constant, the timeline will increase. The three levers are a nice conceptual tool, but they imply CIOs have more control over their projects than usually happens in practice. For most CIOs, scope is the only factor within their control once a project starts, and the one that should be most jealously guarded.

Once the business case for a project has been well circulated, costs and timelines effectively become set in stone, and most business cases are fairly clear in this area. A timeline is generally laid out, and a cost estimate provided with a reasonable degree of precision. What is usually unclear is a detailed scope for a project. While the CIO may have some ability to change time and costs, any dramatic changes will be regarded with a high level of suspicion. When the project actually commences, this ability is further lost; how can one request more money or time when the project has only just begun?

Therein lies the paradox that all the wonderful project management methodologies and adherents to the three levers ignore: Unless your project is floundering (usually due to poorly managed scope) you lose control of the timeline and cost on day one. Many CIOs and project managers will retain the illusion that they can control costs, hammering vendors for discounts or attempting to purchase lower-cost resources, but the real consumer of resources on any project is the actual work that needs to be done to declare it a success.

While cost management, rigorous tracking of deliverables and documentation, and tight resource management are all admirable, many projects take a dangerously cavalier attitude towards scope. I have seen businesses that require signed authorization and an escort to the locked supply closet for a fresh pen, yet allow a junior person from an implementation firm to commit the project to several weeks of additional work (and tens of thousands of dollars) without batting an eye. While CIOs should be far removed from daily project activities, they should have a pulse on the scope of a project, and rather than troubling themselves with how many deliverables were completed, should be concerned with how the project's scope is currently expanding, or more rarely, contracting.

Manage to the right metrics

To keep scope reigned in, make sure you are managing your project to the business objectives detailed in your business case, rather than focusing on deliverables that are more tied to a technical objective than a business one. If key components of the business case are not progressing, or large amounts of effort are being expended on items that do not tie back to the business case, then these should be your first signs of trouble. For one way to focus on business metrics, see the white paper Managing to the Metrics on my site.

Create an effective scope disposition process

Many projects put a great deal of thought into trivialities, but too little consideration to how they will manage changes in scope. Sure, every project claims to have a process and perhaps even some web forms with fancy buttons to boot, but these are generally so arduous that they are rarely used. Fending off scope changes starts at the highest and lowest levels of the project organization. At the high level, the CIO must present a scope change process that is fair, well-understood and not perceived as subject to manipulation or back room dealings. The CIO also needs to make it clear that an enterprise IT project is not an excuse to open the floodgates for requests that should go through other channels. At the analyst level, ensure your people are not committing the project to all manner of new requests, and that they can speak capably about how scope changes should be requested and analyzed. No one likes telling someone no, but when significant dollars ride on every request, instilling prudent scope management in your staff is exactly the same as instilling good fiscal management.

At the end of the day, if you're spending less than 50% of your time related to a particular project understanding and helping guide its scope management, you are setting yourself up for a rude awakening. Perhaps the only area where the three levers holds true is when you mange scope poorly, and are forced to trudge over to the CEO's office to ask for both more time and more money.

About

Patrick Gray works for a global Fortune 500 consulting and IT services company and is the author of Breakthrough IT: Supercharging Organizational Value through Technology as well as the companion e-book The Breakthrough CIO's Companion. He has spent ...

23 comments
paul
paul

Defining the scope is where everything dies on a project. The client will ask for everything imaginable to be included, and most projects try to include them. If they are told that the cost of including some feature to handle a once every year exception is $n and takes six weeks extra, they will usually say they don't actually need it. The 80-20 rule applies: 20% of a project delivers 80% of the benefits, the remaining 20% takes 80% of the time and budget. Get the last 20% properly costed and a business case developed, and they mostly become unnecessary. The problem is that most clients want everything, but have no concept of the implications for time and cost. Give 'em a price list and they will either drop silly ideas, or know what they are really worth. Example: in the UK cheques are virtually unused these days (supermarkets will not accept them). An online trading business that will accept cheques requires extra routines to wait for a cheque to be received after an order is placed, then wait for the cheque to clear, and deal with the situation if it doesn't. A lot of extra development of IT and processes. Not worth it if the number of cheques in a year is tiny, but many clients will ask for the facility because they have traditionally accepted cheques. tell them the cost, and show that the amount of lost business will be tiny compared with the cost of the work.

carswell
carswell

The CIO's that I know need to bone up on their business cases. Very few IT business cases that I have seen have been comprehensive enough to define the scope, quality, cost or timeline to start a project but the expectations are always created by the business case. It is hardly surprising that the cast-iron triangle seems to be so elastic these days.

pmwork1
pmwork1

Not sure which world you are living in, but here in Australia there is no way that "a cost estimate can be provided with a reasonable degree of precision,wthout a clear scope being defiend first " do you mean a budget is set with a reasonable degree of precison ? when I first started reading this article I thought "this makes sense" but as soon as you made this statement I became sceptical about your opinion set in stone, and most business cases are fairly clear in this area. A timeline is generally laid out, and a cost estimate provided with a reasonable degree of precision. What is usually unclear is a detailed scope for a project

thomasratliff
thomasratliff

For me, the 2D triangle consists of time, money, and quality with scope adding the dimension of depth turning the 2D into a 3D model resembling a Toblerone bar. Each scope step increase adds one of those layered and very tasty triangles to the overall picture. It is impossible to eat just one triangle but that does not need to apply to a project. Building the quality component into the overall business case model helps define the scope since quality is a heavy driver of scope change. Quality should be reflected as a series of policy statements including metrics. They need to be meaningful in the context of the business need the project is fulfilling. Including this will allow the business case itself to lead the scope discussion.

PJW9779
PJW9779

You should use quality as a fourth lever. Thus making quality explicit, instead of keeping it (at best) hidden inside the scope. And by making it explicit you also force decision makers to think early about acceptance criteria and testing. Or face expensive cost overruns. It is a Devil's Quadrant, not a Triangle.

sherri.yohe
sherri.yohe

Tracks with my experience as well! Far too often PM's get hung up on the minutia of task and cost/effort tracking and miss the forest for the trees. At the end of the day, what is most important is achieving the project objectives and realizing the value proposition.And this can only be accomplished with vigilent scope management -- including getting rid of those scope items that perhaps we thought were critical during business case but are found to be unnecessary as time marches on.

dwg001
dwg001

What your comment does not take into consideration is the very definition of a project - it is a unique endeavor with definite starting and ending points - the term "unique" implies that there are uncertainties in terms of delivering the desired end product that may not be knowable until one attempts to develop them. This may cause some added scope items that could not have been anticipated until the attempt was made. Or there are complexities and interactions that have not been anticipated which will cause the scope to change. This type of situation is especially prevalent in enterprise projects and can really only be managed via some robust risk management mechanism. The point is that scope must be flexible enough to assure that the desired outcome and business value are reached - even if that means that any one of the three "levers" are changed significantly.

steven.robinson
steven.robinson

I agree with the commentary . . . as mentioned above, Scope is in the eye of the beholder, so ensuring you have a Communication Plan to all levels of Stakeholders, with Risk identification and mitigation built in is key. There are ways to get a deeper sense of accountability and ownership when people understand their role in the project.

mikifinaz1
mikifinaz1

I learned about this one day while working in an auto shop. I had a customer that was all over me about the time it was going to take to fix his car and why was it so expensive. So, in an effort to deal with the situation I had this conversation with him this: I asked him if he had 20,000 dollars. He became puzzled and I told him, that if he did I could fix his car in less than 15 minutes. He asked me to explain and I said well, if you had that amount of money I could just go down to the dealer and buy him a new car. Then I told him I could fix his car for free if he left it with me an undetermined amount of time and I would get to the work when it was possible, and it may take a year or so. The bottom line being that almost all things are possible give the trade offs of time and money. Once those constraints are defined then you get into what is possible.

hlhowell
hlhowell

Scope is very much in the eye of the beholder. Lots of things can be done, and most of them add more cost than value to a project, however value is in the use of the project. If the scope managed to overlook the input required, or the users inputs for design, then the scope will be flawed from the outset. Too many folks focus on the manager, when the folks that will actually use the software will be the ultimate arbiters of success or failure. Since these folks all too often are not heard from until launch or beta test, the essential usability has to become the "hail mary" when it should have been the kickoff.

JamesRL
JamesRL

There are always constrained resources. The project may require subject matter experts that you can't just hire off the street. Timelines are often determined by external factors not in your control. Budgets are not unlimited. Too many projects have to deal with these issues because, to use a football term, their are trying for a hail mary - a project that gets them to the end zone in one fell swoop, instead of a series of projects, each of which moves you closer to the end goal.

MikeGall
MikeGall

Also some levers have natural limits. There is only so much stuff that you can do in parallel for example so it doesn't matter past a certain point how much money you throw at a project it still won't get done faster. Second there is a natural limit in the opposite direction too: there is a certain amount of work that needs to be done and it will cost a certain amount to do it without overtime. Lengthening the timeframe will slow the burn rate but the project will end up costing the same just taking longer to complete. A wishful thinking solution: have it written into the project documentation that any scope changes need to be accompanied with a transfer of funds to cover the extra costs and a plan for how they are going to fund it if the extra features end up costing more than expected. It is amazing how many feature requests become unnecessary when the requesting department has to pay for them :-)

Tony Hopkinson
Tony Hopkinson

Most business cases have an IT component. The chances of one being put forward by IT, not having some IT in it are admittedly slimmer. But the business case, should be. This will reduce our costs by X, increase our revenue by Y, or for infrastructure related expenditure, enable us to continue reducing X and or increasing Y for another Z years. If a business case doesn't say at least one of the above, it isn't one. There's still a lot of arcane in IT, often hard numbers are hard if not impossible to get to, but even a village idiots dog should be able to figure why business's have IT. Everytime I see someone trying to seperate IT from business I see a problem not a solution.

Tony Hopkinson
Tony Hopkinson

One assumes the quality you are referring to then, is the percieved qaulity of the end product as opposed to the often awful mess that was used to deliver it....

Tony Hopkinson
Tony Hopkinson

"unnecessary" item in the scope that gets dropped in a resource squeeze. What we should do is document that, and then when and I mean when we get problems attach the cost of dealing with them to the decision. You never know someone might learn from it. Oh look a flying pig... :(

Tony Hopkinson
Tony Hopkinson

Inflexible deadlines and resources based on the scope before it flexed, now that we have an issue with....

Tony Hopkinson
Tony Hopkinson

If you told me I'd be getting a system which automatically produced orders to keep my warehouse stocked. Scope failures are forgot to mention link to purchase ledger, or even having one at all... Scope changes are going from basic re-order level to vendor performance driven JIT. The former whoever was responsible takes it on the chin as what you were going to produce would not filfill the need. The latter, is a new project. Can is not an issue, one way or another I can make it do what you want. Should I though? Of course taken as a given no more resource the further away the plan is from the need the crappier the eventual product. But that was what you wanted, wasn't it?

v r
v r

Agreed. If the project involves application modification or creation, prototyping during the scope/project definition period is tremendously valuable. Infrastructure projects require more mapping and showing the sponsors the mapped results of the project. They may not understand it, but they will have a better grasp of the cost of their request(s).

Tony Hopkinson
Tony Hopkinson

I was thinking CIOS and PMs doing acts of contrition. :) Cthulu knows more than few of tham have a lot to be contrite about.

Tony Hopkinson
Tony Hopkinson

All too often they end up as Version 1 of something based on whatever time you have left. The other probability is that calling it a prototype means everyone important spends the entire resource for doing the real thing f'ing about, but no one adjusts the deadline. This used to be called RAD. Really Awful Deployment..... There are two levels of prototyping. One is a wind tunnel model to test aerodynamics, the other is the full car to see if it works. You can't buy either in a retail showroom.... I prototype but to look at a particular aspect, a new UI, or a new algorithm. Don't whatever you do make a working one, if it doesn't need wheels don't stick cardboard circles in the wheel arches to make it look right.. Sales will sell it and you'll have to do rims, tyres, steering and brakes in about minus two weeks.

JamesRL
JamesRL

I've been on a few projects where they want to upgrade the infrastructure, then implment some new technology all at once. Its like talking to a wall sometimes. But if the new tech can support the existing system, upgrade the infratrsucture as one project, wait a few months, then implement the new tech. So much safer. So simple, you'd think a CIO would grasp it.

Tony Hopkinson
Tony Hopkinson

there might be an echo... There are only two sorts of scope changes. Ones that should be in another project because they have naff all to do with this one. and ones that should be in another project because they do have something to do with this one.

Editor's Picks