Issue 2-Balancing the Triple Constraint
The number one cause of project schedule and cost overruns are scope changes
PMI certified and experienced project managers realize that cost, schedule and scope (the Triple Constraint) are critical factors for a successful project.
For a successful project, the PM must effectively control scope for the proper balance of the Triple Constraint. The role of a Project Manager is to show the impact of scope changes on the project’s cost and schedule and to create a balance between them. Scope control assures all requested changes and recommended corrective actions are processed through the project’s Integrated Change Control process. Project scope control is also used to manage the actual changes when they occur and is integrated with the other control processes.
Uncontrolled changes are often referred to as scope creep. Change is unavoidable but it requires a formal change control process. There will be occasions when requested changes have to be made to comply with policy changes, legal regulations, changes in the business direction of the organization, or where technology may require change. Non-essential changes can be avoided, however, through an effective formal change control process.
Scope Creep Strategies
Here are a few pro-active strategies to reduce the likelihood of schedule or budget overruns caused by scope creep:
1. Set clear expectations of the entire community of stakeholders during the Kick-Off meeting
Ensure your client knows that the project has to be completed at a certain level of quality, in a certain amount of time and at a particular price to make the project successful. If the project has a schedule constraint, you may need to look into increasing the resources assigned to the project, or have the quality/scope reduced.
2. Recognize all stakeholders
Most importantly include level 1 stakeholders, i.e., department heads and sponsor, and include them in defining the scope baseline as well as requirements specs. Establishing the scope baseline means describing the product (business functional requirements) in detail early. The scope should also detail what is not in scope. The requirements specifications define the product to the level of detail that allows all project groups to perform their activities productively. When the product is properly defined the project manager and team members know “what is in and what is out of the project scope”.
3. Gain formal agreement from the project sponsor and other “approvers”
Getting approval on the detailed scope statement and publish the scope baseline. Get the agreement from the right people, or organizations, on the business and functional requirements of the product being built. All groups dependent on complete and accurate product specifications must approve the document to ensure that it meets their needs. When the product being built meets the needs of the users fewer changes need to be made. I like to have the vision, project objectives and scope baseline displayed on large posters in the “war room” so that the team can keep their eyes on the ball.
4. Create a Change Control Board (CCB)
Carefully impose a formal change control process and ensure the change board (change approvers) is filled with the right people. Some changes are to be expected during the product build, and a formal process must be defined and followed to make sure all changes are necessary, approved by the CCB, communicated to all affected parties and followed in an orderly manner.
Implementing an EFFECTIVE Change Control Process
I would suggest the following components are a must in implementing an effective change control process:
1. Determine the decision makers in the CCB along with the project sponsor
The Project Manager should ensure he or she is also on the CCB. Some larger projects will include relevant department leaders in the CCB
2. Strictly enforce the use of a Change Request Form (CRF) for ALL changes, no exceptions
Project Managers should not act on change requests received verbally. There is just too much room for misinterpretation on both ends. Ensure the change requestor defines the business value to the project. The CCB will need this information to make a final decision.
3. Review and evaluate the requested change
The Project Manager should assign the change request to a team member or self assign for further investigation. The team member will first determine how much time it will take to investigate the change request. If the time required to perform the analysis will cause deliverable dates to slip, the request must first be taken to the sponsor to determine whether the request should be investigated or not. If the sponsor gives the initial approval to proceed, the work plan and budget may need to be updated to reflect this new work. If the sponsor does not agree to investigate the change request, then the request status should be “closed”.
4. The Project Manager or team member should document the resolution or course of action in the Integrated Change Control Process
The Project Charter should also be updated if an approved change results in a substantial change to the project. When a change occurs (that is accepted) all project team members need to re-examine their project documents and schedule. Any corrective changes go to the Project Manager and new plans and schedules are produced. Then a process of verifying the scope occurs.
I would be remiss if I did not include a couple of other components to the Triple Constraint:
Time/Risk:
Project Risk is the rope itself in the tightrope walker analogy. Stakeholders are making the rope sag, shift, lower and rise. These risks are mostly disadvantageous. Regardless, adjustments must be made. To manage the Time/Risk factor, Project Managers must use schedule management techniques. Fast tracking and crashing are two of the better known and most used schedule techniques (Come to think of it, I may devote a future blog to project schedule techniques!). Expert judgment and the project’s industry standard metrics are necessary to thoroughly understand impact of the risks. This is why Project Managers should always add a contingency reserve in the budget.
Project Risk is the rope itself in the tightrope walker analogy. Stakeholders are making the rope sag, shift, lower and rise. These risks are mostly disadvantageous. Regardless, adjustments must be made. To manage the Time/Risk factor, Project Managers must use schedule management techniques. Fast tracking and crashing are two of the better known and most used schedule techniques (Come to think of it, I may devote a future blog to project schedule techniques!). Expert judgment and the project’s industry standard metrics are necessary to thoroughly understand impact of the risks. This is why Project Managers should always add a contingency reserve in the budget.
The weather, the government, the stock market, all of these could provide your project with threats or opportunities. These factors can be included as management reserves. Management reserve is money set aside by senior management for the project. The Project Manager does not have authority over these funds and has to request it from management.
Cost/Resources:
This factor considers what resources need to be applied or assigned to the project in terms of money and effort in order to implement the project. Trouble in attaining the right people for the project will most certainly throw the Triple Constraint off balance. If you are an independent contractor run away from any project where the client wants the impossible. Your reputation is more important.
Getting your balance on the tightrope – By making adjustments to any of the three components and knowing the effects each has to the project, you will be able to plan your projects better, analyze project risks, protect your organization from the problems of unrealistic client expectations, and manage the project itself better. There’s never too much time devoted to planning.
Finally, the main three components of the Triple Constraint help the project manager determine whether a project’s objectives are being met and whether the project is on schedule and at budgeted cost.
As always, comments are welcomed. Our next blog in the series of “Why Projects Fail” will focus on Unrealistic Estimates.
