����ֱ��

As I mentioned in my last article, project management has become a critical skill for efficiently and effectively aligning valuable resources to achieve an organization’s important operational, strategic and sales projects. In this article, I’d 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’s 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’t seem to be agreement within the project management community on the third side of what is often called the “iron triangle.” A quick Google search on triple constraints will show some references using “scope” and others “quality.” Since I’m not a fan of the word “scope” and the word “quality” is too general for me – I prefer “Requirements.” 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’ve also read that it was dropped because it is no longer relevant, but I totally disagree with that. So let’s 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’t) 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’s customer(s). Ironically, an external customer isn’t 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 “driver 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’t 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’t apply since you don’t have a viable project if the requirements are unrealistic (I’d 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’t 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, “you can’t 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’ve 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’s 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.