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.