黑料不打烊

Revisiting the Three Constraints Associated with Managing a Project

Program ParticipantsAs I mentioned in my last article, project management has become a critical skill for efficiently and effectively aligning valuable resources to achieve an organization鈥檚 important operational, strategic and sales projects. In this article, I鈥檇 like to address something that all three of these categories of projects have in common. They are all constrained by three elements 鈥 Time, Cost and Requirements. Time is simply the project鈥檚 due date, money is the cost to complete the project and requirements are the agreed upon customer expectations for the final deliverable(s) being produced by the project. Most everyone agrees with the time and money constraints, but there doesn鈥檛 seem to be agreement within the project management community on the third side of what is often called the 鈥渋ron triangle.鈥 A quick Google search on triple constraints will show some references using 鈥渟cope鈥 and others 鈥渜uality.鈥 Since I鈥檓 not a fan of the word 鈥渟cope鈥 and the word 鈥渜uality鈥 is too general for me 鈥 I prefer 鈥淩equirements.鈥 I suspect that this lack of agreement on the third constraint is what led to the Project Management Institute dropping the triple constraints from their publication A Guide to the Project Management Body of Knowledge (PMBOK Guide) Fifth Edition. I鈥檝e also read that it was dropped because it is no longer relevant, but I totally disagree with that. So let鈥檚 revisit the concept and you can decide its relevancy.

In my recently published book, Pursuing Project Excellence: Six Ideas to Improve Your Projects, I included some thoughts on the importance of working with the triple constraints when managing a project. There are two key concepts 鈥 the first is an important reality to acknowledge (and many don鈥檛) regarding the triple constraints. This concept is that the constraints are interdependent. If you modify, change or play with one constraint, the other two constraints will be impacted. For example, a project that has an aggressive due date will almost always cost more than the same project with a realistic due date. Likewise, projects with aggressive due dates will also almost always result in compromises being made with regards to requirements. Projects that are underfunded will almost always take more time and also result in compromised requirements. The danger of compromising requirements in the above two scenarios is that you have now created issues with the project鈥檚 customer(s). Ironically, an external customer isn鈥檛 really concerned about your increased costs to complete the project, but they will certainly be concerned about compromises to their requirements.

The second key concept is that at the start of a project it is important for you to rank the triple constraints and then check the ranking during the project to see if conditions being placed on the project have caused the ranking to change. So what are the criteria for a constraint to become ranked at the top or to become what I call the 鈥渄river constraint? 鈥 For time or money to be the driver, two criteria must be met. You must have a fixed due date or dollar amount and you believe that due date or dollar amount is aggressive or possibly unrealistic. Time-driven projects are commonly referred to as fast-track projects. Most professional sports stadiums built in the United States over the past twelve years have been fast-tracked. Owners don鈥檛 want to wait the normal three years to get their stadiums built. Most are completed in about half that time and most have gone over budget. In Cincinnati, Paul Brown stadium was originally budgeted for $280 million, but by the time the stadium was completed in 2000, the cost exceeded $500 million. The new stadium for the Los Angeles Rams is budgeted for $2.6 billion and is scheduled to take three years to complete.

As for requirements being the driver constraint, the criterion is different than for time and money. The unrealistic criteria can鈥檛 apply since you don鈥檛 have a viable project if the requirements are unrealistic (I鈥檇 like to say the same thing about unrealistic due dates and dollar amounts, but sadly many of those projects are initiated, planned and executed - often with dire consequences). For requirements to be the driver, the requirements as agreed upon with the customer must be met even if this results in additional time and money being spent. Most customers want their requirements met, but you often won鈥檛 find out how committed they are to this until you approach them with a delay in the project in order to meet the requirements. Given this choice, their decision will tell you what is most important to them. As the old idiom says, 鈥測ou can鈥檛 have your cake and eat it too.鈥

Why is ranking the constraints important? The ranking impacts decisions that are made throughout the project. Most of the decisions made in a project will impact one or more of the triple constraints. In order to make consistent decisions throughout the project, they should be made based on the ranking of the constraints. For example, suppose someone submits a change request during a project that will require additional time to complete the project. If the project is time-driven, which means it was essentially behind schedule before it got started, this change request would have to be denied. The same would be true with any change that requires additional funds if the project is money-driven.

Over my 35 years of managing projects, I鈥檝e had to address the reality of the triple constraints with many project sponsors and customers 鈥 especially those who have imposed aggressive due dates or budgets on projects. The challenge for any project manager is to balance the triple constraints to create an optimal time-cost-requirements equilibrium for the particular project and then to communicate that with the project鈥檚 key stakeholders. While there are certainly many constraints that can be associated with managing a project, understanding and managing the triple constraints 鈥 time, money, and requirements 鈥 are as relevant today as when the concept was originally introduced in 1969. Identifying and controlling their hierarchy can mean the difference between success and failure on any of the three types of projects encountered in an organization.