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?
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.