Breaking the Project Management Triangle
- Breaking the Triangle: A Case Study
- The Purpose Alignment Model
- Using the Nickolaisen Model to Break the Project Management Triangle
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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 that 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 that 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 that my team and I could pull off the latest project miracle.
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 reflecting honestly on recent death march successes and failures. As I thought through the common issues with the specific project triangles, the light went on. Instead of focusing on the interplay among scope, time, and budget, I needed to change the way we defined and managed scope! Instead of 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 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. Over the years, the company had 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.
Most retailers handle drop shipments by creating a single purchase order with multiple ship-to locations. The supplier fills the order by shipping the specified products to the individual locations and then sends one invoice to the retailer, which pays for the entire order with a single payment.
In this case, however, the retailer replenished its retail stores by placing a separate purchase order for each store. The supplier would ship those orders separately to the individual stores and then send an invoice for each of the purchase orders it received (one for each store). The retailer would process a payable item for each of the multiple invoices it received from the supplier.
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—not just to the procurement system, but also the accounts payable system. For the perspective of the project management triangle, this requirement was a stake in the ground of the "scope" corner. With this corner fixed, we would have to adjust time and budget to compensate. But what value would we generate with this customization? Would it win us new customers or help us keep customers? Would our customers even know what business rules we used to replenish stores? It seemed to me that this customization just put 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 for this project. But, as in almost every case, my customer wanted it all, so the project management triangle failed me. In the future, how could I help people to make wiser scope decisions?