Breaking the Project Management Triangle
- 17 November, 2009 11:23
My first real IT job was as the manager of a large, put-the-business-at-risk systems project. In this new role, I thought the project management triangle was my best friend. At the beginning of the project, I would calmly sit down with my project customer, draw a triangle with Cost, Time, and Scope at the corners and explain the interplay among these three project constraints. My explanation went something like this:
“For any project, these three constraints are interdependent. If you decide that you want to increase the project scope, we will need to increase the time / cost combination. If you decide you need to shrink the timeline, we will need to reduce the scope or increase the cost (or both).”
I depended on my project management triangle best friend to back me up when my project customer increased the scope, decreased the budget, or reduced the timeline.
However, in practice, the project management triangle failed me. It seemed that my project customers usually forgot all about the triangle when they started to change their minds. They wanted it all! They wanted to increase the scope but hold to the time and budget constant. Or, they wanted to reduce the cost but keep the scope and timeline the same. When I tried to remind my customers about the project management triangle I had drawn for them, they nodded their heads but then assured me that they had every confidence in me and my team that we could pull off the latest project miracle.
So, being good soldiers, my team and I would embark on a death march to deliver that latest project miracle. Sometimes we succeeded. Sometimes, we failed. Whether success or failure, I soon realized that I needed to do something differently before my team and I burned-out from being project heroes.
Breaking the Triangle: A Case Study
Not wanting to repeat or exacerbate my recent experience, I started by doing honest reflection on recent death march successes and failures. As I thought through the common issues with the specific project triangles, the light went on. Rather than focusing on the interplay among scope, time, and budget, I needed to change the way we defined and managed scope! Rather than managing the project triangle, I needed to break the triangle! Let me give you an example:
In one particularly brutal death march project, we were implementing a new supply chain, inventory management, and procurement system for a specialty retailer. I had several project customers but the real driver behind the project was the Vice President of Operations. The company had, over the years, defined some very unique business rules. In particular, the company had developed, and supported in its highly customized legacy systems, a unique way of handling drop shipments. When the retailer needed to replenish its stores it would place a separate order, on a separate purchase order, for each of its retail stores. The supplier would then ship the separate order to the appropriate store. The supplier would then send an invoice for each of the purchase orders it received (one for each separate store). The retailer would then process a payable for each of multiple invoices it received from the supplier.
Now, the standard way for a retailer to handle drop shipments is to create a single purchase order – but a purchase order with multiple ship-to locations. The supplier then fills the order and ships the ordered products and quantities to the appropriate ship-to locations. Finally, the supplier sends one invoice to the retailer and the retailer pays for the entire order with a single payment.
The “requirement” from the Vice President of Operations was for us to replicate the retailer’s unique drop shipping business rules when we designed, built, and implemented the new system. As you might expect, meeting this requirement required significant customizations to not just the procurement system but also the accounts payable system. From a project management triangle perspective, this requirement was a stake in the ground of the “scope” corner. With this corner fixed, we would have to adjust the time and budget to compensate. But, what value would we generate with this customization? Would making this customization win us new customers? Would this unique way of handling drop shipments help us keep customers? Would our customers even know what business rules we used to replenish our stores? It seemed to me that all this customization accomplished was putting our project timeline and budget at risk. At first, I relied on the project management triangle to explain the impact that scope had on time and money. But, as in almost every other case, my customer wanted it all. The project management triangle failed me. But, how could I, in the future, help people make more wise scope decisions?
The Purpose Alignment Model
The result was what I call the Purpose Alignment Model. Because I invented this model, I also call it the Nickolaisen Model – that way I get some credit for my invention and leave some miniscule legacy. Purpose Alignment helps us define the purpose of project scope. Knowing purpose, we can design our project to achieve this purpose. Designing around purpose usually breaks, but sometimes shatters the project management triangle. The Nickolaisen Model works like this:
We measure our business processes and project requirements in two dimensions. First, the extent to which the process or requirement will differentiate us in the marketplace. Second, the extent to which the process or requirement is mission critical. This yields the following 4-Box Model:
The four boxes describe the purpose of our various processes and requirements.
A few of our processes and requirements are both market differentiating and mission critical. These are the Differentiating processes and requirements. The purpose of these is to win customers and gain market share. We need to be better than our competitors at these processes and functionality. In order to sustain our competitive advantage, we need to constantly innovate how we perform these processes and deliver this functionality.
The vast majority of our processes and requirements are mission critical but not market differentiating. The purpose of these is to be at Parity with the marketplace. There is no benefit in performing these processes or delivering this functionality better than anyone else. In fact, treating these as if they are Differentiating has a very high cost. First, the direct costs of the resources we spend to make these better than they have to be. Second, the indirect costs of the complexity we add as we make these processes or functions unique, interesting, or innovative. We should design these parity processes and functions in a best-practices, simplified, streamlined, and standardized way. In the example that inspired me to invent the Nickolaisen Model--how the company performed drop shipments--is a perfect example of a parity requirement. Because store replenishment was a mission critical activity, we had to do it well (otherwise, we would be below parity) but we did not need to do handle drop shipments in a unique way. We could accept (and, because it was a parity activity, needed to embrace) the standard way of processing drop shipments.
There might be some processes or requirements that are differentiating but that are not mission critical for us. Thus, to exploit this opportunity to differentiate ourselves in the market, we partner with someone to deliver this process or function. For example, suppose we differentiate ourselves with our engineering design. In addition, our designs require incredibly precise manufacturing. Rather than build our precision manufacturing capabilities, we might partner with (which is different from outsourcing to) a company that differentiates itself with its precision manufacturing.
Finally, there might be some processes or requirements that are neither differentiating nor mission critical. For these, who cares what we do?
Page Break
Using the Model to Break the Triangle
How does the Nickolaisen Model help us break or shatter the project management triangle? It is a powerful way to focus and simplify project scope. Here is a simple, yet typical example:
For the third time, we were gathering the requirements for a sales force automation (SFA) system. The previous two attempts at designing an SFA system had failed because no one had been able to figure out how to design for all of the local variations in how the sale force operated. Each region and territory had its own way of quoting jobs, tracking the sales pipeline, and generating forecasts, with the Eastern region being adamant that if they had to change these processes, their customers would disappear. This complexity had overwhelmed both the sales function and IT. I had just been hired and was handed this third attempt at the SFA project. I suppose the company figured that the SFA project was a good way to find out if I was actually worth the money they were paying me. At the project kick-off meeting, rather than draw the project management triangle, I drew the Nickolaisen Model and asked the question: Are our sales force processes and business rules Differentiating or Parity? The initial reaction was that, since the SFA was customer-facing, it must be differentiating. But, as we probed deeper into the functionality of the business rules, it became more and more clear that the specific features and functions were parity. For example, we needed to generate and track quotes in the SFA. But, did we gain market share and win customers with the mechanics of how we generated and tracked customer quotes and proposals? No, these mechanics were mission critical but were not how we won in the marketplace. As soon as the assembled team recognized that our proposal and quoting process was Parity (rather than Differentiating) the team also recognized that there was no competitive advantage in each sales region and area having their own unique process for generating and tracking quotes. It was as if the blinders fell from the eyes of the project team. The sales manager from the Eastern Region realized that there was no advantage in his unique method for generated and tracking sales quotes. Once the team realized that this aspect of the SFA was a Parity activity, the entire team was willing to accept a standard process for sales quotes. Aligning around the purpose of this process removed the emotions and allowed us to design and successfully implement a simpler, best-practices-based SFA. We broke the project management triangle.
As another example, a software company was planning a major rewrite of its flagship product. Their initial project plan included nearly 3000 function or story points. The company expected this project to last 18 months and cost millions of dollars. Before the company launched the product, they invited me to review their project plan. For my review, I drew the Purpose Alignment on the conference room whiteboard, explained the model, and asked, “Which product modules and functions will really differentiate you in the marketplace?” Our first step was to understand how this company created its sustainable competitive advantage. Sustainable competitive advantage helped us identify the differentiating functionality. We explored how we could make the differentiating elements of their software even better. With this done, all other functions and requirements fell into the Parity category. For the Parity function and story points, we found ways to reuse existing code, reduce exception handling (there is rarely market advantage in supporting exceptions to parity activities), and simplify the software design. When we were done, about 15% of the project was to support Differentiating activities. For the 85% that were Parity, good enough was good enough. The combined impact on the project was a better product – we had made the Differentiating features even better – at a reduced cost and much shorter timeline. It turned out that making the Parity functions just good enough cost a lot less time and money. For this software company, Purpose Alignment shattered the constraints of the project management triangle.
Purpose Alignment is no silver bullet that can solve any and all project problems. But, it is a common sense approach to project planning and implementation that aligns project teams, project sponsors, and project requirements with the real needs of the project customers and market.
