An interesting article by Niel Nickolaisen on computer world
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).”
Related reading: Defining Project Constrains
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?