Project sponsors should play a critical role in projects. They should set the goals for the project, use their authority & influence to help the PM get resources and solve problems. When there are conflicts the sponsor should protect the project. While many executives understand their role and play it well, there are many who do not. The bad ones won’t commit to exactly what they want from their project. They play it safe politically by never committing to a scope. These sponsors usually want to drive the project to a completion date they often pluck from the sky. Talk to other PM about a new sponsor. If the have many failed projects and often blame the project manager and team. You have a bad. Because sponsors outrank the project manager, often by many levels, you have to use a great deal of tact in using these techniques to guide an ineffective project sponsors toward fulfilling their project role. As a project manager, you will routinely face high-pressure situations with sponsors trying to do things that will harm the project. If you let the intimidation get to you, the project will fail. Here’s what to say, and what not to say, in each situation.
Project Sponsor Situation #1 Defining a Project Scope
Number one among the project sponsor’s responsibilities is defining the scope of the project. Its the reason the sponsor initiated the project in the first place. Project sponsors need to give the you and your team a crystal-clear definition of what the project should deliver. The definition should include the acceptance criteria they will use to accept or reject the project. If they’re playing political games with the scope, doing friends favors, or won’t committ themselves to exactly what they want, the project manager and the team members are almost certain to fail. When the sponsor demands the project team to start work without knowing what’s expected of them they are headed for delivering an unacceptable product, late and over budget. There are other project sponsor obligations that project managers have to subtly guide them to fulfill. Let’s discuss them.
This occurs during the initiation of the project. In that first session you need to take a very strong position that the scope of the project must be defined in measurable terms, that is with a measurable metric. Often times you have to “sell” the sponsor on the benefits of a scope that defines what he or she wants with numbers rather than vague, subjective definitions.
Project Sponsor Situation #2
Another make or break situation occurs when you discuss your authority to direct the project team. If you are borrowing team members from another department, you want to be able to give them assignments directly rather than going through their supervisor. You also want to be able to evaluate their performance and have input into their annual performance review.
Project Sponsor Situation #3
Other critical situations are change orders affecting the project scope, duration or cost. There is no such thing as a free lunch. Every scope change affects the project’s duration and cost. Similarly, the project sponsor can’t cut the project’s duration without affecting the scope and cost or cut the budget without affecting the scope and duration. Project sponsors don’t want to hear this so you must be able to show them options for managing changes to the scope, duration and cost.
Project Sponsor Situation #4
Finally, status reports with a bad variance are a critical situation. You must present viable solutions to fix the problems of schedule or cost overruns.
Effectively handling each of these situations is critical to your relationship with the sponsor and to the success of the project.
You learn all of those skills in our project management basics courses. Take a look at the basics course in your specialty.
At the beginning, when you and Dick talk to design your program and what you want to learn, you will select case studies that fit the kind of projects you want to manage. Chose you course and then select the which specialty case study from business, or marketing, or construction, or healthcare, or consulting. That way your case studies and project plans, schedules and presentations will fit your desired specialty.
Managing project duration to make sure the sponsor and stakeholders are happy is the number one challenge for most project managers. Many executives think the most important metrics are the project duration and the finish date. Sometimes they are the only measures the sponsor and stakeholders ask about.
Project Duration: Why Do Stakeholders Manage Only Dates?
In a date-driven project world, the project managers have usually given the stakeholders nothing else that is measurable. Here’s why:
The scope statement is three pages of mush with no metrics
No one cares about cost because the project managers don’t measure it
There’s no data on hours because the project managers don’t gather it
Risk is not managed and most projects don’t bother to identify even the major risks
No one tracks the hours of work used by the project because everyone figures the people would be paid anyway.
It’s no wonder the stakeholders only pay attention to dates.
Project Duration: What Tools Do You Need?
Project managers must have tools to handle requests to finish earlier, increase the deliverables or that cut the costs. Tools like critical path analysis are an essential weapon in your tool kit when dealing with these requests. The tasks on the critical path control the project’s duration. Stakeholders need to learn they can’t arbitrarily make changes to critical path tasks, their resources, or deliverables and keep the same finish date. The best way to illustrate that fact is to model the change and show them the impact on the finish date. See Project Schedule & Software Main Page
A skillful project manager doesn’t try to prevent all the changes requests that come up during the initiation and planning phases. They will also arise once you begin to execute the project plan. Those requests usually result in increases to cost or changes to scope so they are difficult to manage. There is a right way and a wrong way to manage these requests. Unfortunately, project managers often handle requests to finish earlier the wrong way. They try to prevent any change to the project plan. Simply denying requests triggers a great deal of conflict. That results in unhappy users or customers who simply go over the project manager’s head.
Project Duration: Model the Impact of Changes
The better way to handle these requests is to welcome change requests. Then you model the changes in the project software and show the stakeholders the impact on the finish date. Next you lead a discussion about the impact of implementing the duration or scope changes. These changes usually include increasing the resources on the project team which often increases the cost of those resources. Models showing the impact of the changes give the stakeholders information they need to make informed decisions. The project sponsor also has this information to use when the change requests come to them for approval or denial.
You can learn all the skills for managing project duration and change requests in our project management courses. Take a look at the courses in your specialty.
When project managers handle project change control badly, it irritates stakeholders and cause overruns on budget and duration. Fighting all changes doesn’t work and neither does accepting all of them. We’ll discuss the mistakes project managers make on change orders. Then we’ll review a methodology for doing it the right way.
On many projects, the project manager faces a never-ending stream of additions and changes. These begin five minutes after the sponsor approves the project plan and continue until five minutes before they accept the last deliverable. Watch this video of a typical change control process.
Walking out to the company parking lot, you ran into the executive who was the sponsor on your current project. The sponsor said, “The project is really coming along well but I do need to add a couple of things.” They handed you a page from a yellow notepad with 35 items on it. You knew it was time to exercise project change control. But the sponsor continued, “These items are really vital to what we’re trying to achieve on our project.” How to Manage Change Order Requests
You looked down at the paper and replied “We couldn’t possibly make any additions at this point. The due date and budget are in danger now. If we keep adding things we’ll be way over.”
The sponsor said, “But these are critical! Without these additions, this whole project will certainly fail.”
You responded, “I think the project will contribute a great deal even without these items.”
The sponsor disagreed, “These were really part of the original requirements. You must have missed them.”
You replied, “I’m sorry but these items were definitely not on the original list of requirements you signed.”
The sponsor grew re-faced and retorted, ”These were part of the business plan for customer service. I don’t care what was on that long list of technical mumbo jumbo you designed. It was just geek talk that none of us understood!” Scope Change Video
You looked back down at the list and tried to calm the sponsor by saying, “Anyway, these seem to have limited business value.”
The sponsor barked, “I’m the one running this operation and I know what’s necessary. And the items on the list are essential if we’re going to maintain competitive levels of customer satisfaction.”
You took a deep breath, “We will be late if we add anything.”
The sponsor took a breath, smiled and said, “These items really won’t take much work. So they should only hurt the schedule or the budget a little. I know you can squeeze them in.”
You frowned, “That is not the case. We will have overruns. They won’t be my fault because these items were never in the approved requirements.”
The sponsor snapped, “If you won’t add these items to the project schedule, I’m going to bump this problem up the line to the VP.”
Project Change Control with Several Endings…All Bad
1. In the first ending, you said, “OK your satisfaction is my goal. We will figure out a way to squeeze these in and not finish too late. But these must be the last changes we make or we’ll have a disaster! “
The sponsor gave his solemn promise, “Absolutely! These are the last changes.” (If you’re naive enough to believe that, you can forget about project change control.)
The next week the yellow sheet of paper had 47 additions, the project finished 3 months late and you took the blame.
2. In the second ending you refused to add the additional requirements. Five hours later your boss called and angrily said, “The senior VP just chewed me out about my project managers not being responsive to our management team. Why are you stirring up trouble with your sponsor? We need his support!”
You started to explain about the changes to scope and the boss interrupted saying, “Add the damn changes…just get these people off my back.” You started to agree just as the boss slammed the phone in your ear.
The next week the yellow sheet of paper had 47 additions, the project finished 3 months late and you were blamed.
3. In the third ending, the boss listened as you said, “I’m trying to be customer-oriented but those changes could set us back a couple of months and cost lots of money.”
The boss said, “Give me a memo on exactly how much later and how much more it will cost so I can show the vice president.”
You thought for a long moment and said, “Well, it’ll take quite a bit of time to put that together.”
The boss grunted in exasperation and said, “I need something to show the vice president today. So you’d better just add the changes they want and have everybody work harder. Use your leadership skills.”
The next week the yellow sheet of paper had 47 additions, the project finished 3 months late and you were blamed for not exercising project change control.
Why Does Bad Project Change Control Happen Over and Over Again?
It happens because project managers lack the tools to exercise project change control. One key to project change control success is project planning that develops quantifiable acceptance criteria for the project scope and each major deliverable. These are not technical specs but measured business outcomes in the customer/user ’s organization. Those acceptance criteria with metrics are the foundation of project change control. That kind of scope definition lets you win the argument about whether changes are necessary for project success. That type of scope metric makes the argument about what was and what was not included go away. Everybody knows what was originally included. Then you aren’t arguing the merits of a change or whether it’s a good or bad idea (you will always lose those). Instead, you are discussing whether or not you can achieve the scope without including the change.
The second key to successful scope and project change control is using a software tool that allows you to quickly quantify the impact of a change. You can use the software to quickly estimate, and then model, exactly what effect a change will have on the project’s cost and duration. With this modeling capability, the conversation with your customer/user is quite different. Let’s see how it goes using both these tools for project change control.
Project Change Control the Right Way
The customer stepped into the your cubicle and said, “The project is really coming along well but I need to add a couple of things.” They handed you a page from a yellow notepad with 35 items on it and then continued, “These items are really vital to what we’re trying to achieve on our project.”
You looked down at the paper and said, “These are great ideas. OK, let’s quantify the added work and the added time.” The customer’s first item was additional training for customer service reps so they could discuss three new products with customers. You said, “We would have to change the training achievement from “Customer reps can answer questions about 37 products accurately 90% of the time,” to ’40 products.’ I’ll ask the trainer to give me an estimate of the hours required for the change.” You called the trainer who gave you a rough estimate of 12 additional hours of prep time on the new products and 15 additional hours of class time.
While you were writing, the customer said, “It should only take a few more minutes. Anyway, I thought these new products were in the original specs.”
You pulled out the plan for the deliverables and said, “No, here is the trainer’s work package we used for the estimate. It has 37 products.”
The customer agreed the new product training was not covered in the original project scope and plan.
You commented, “If you want to eliminate three of the original products, it would be a wash.”
The customer responded, “No, we need all 40.”
You said, “The trainer says that will add 27 hours of their time and the class itself will be longer for the attendees. You opened the project schedule on your PC and entered the additional hours. Then you leaned back and said, “As you can see, these changes would add 7 days to the project duration and would increase our costs by more than $16,000.”
The customer was surprised at the cost and said, “But these are necessary. They are good and worthwhile additions.”
You smiled and said, “I’m sure they are very good ideas or you wouldn’t have brought them to me. But our question has to be; can we hit our project’s measured achievement of, “Customer reps can answer questions about 37 products accurately 90% of the time” without them? They clearly expand the project scope and I will need to add extra time and money to accomplish what you want. That’s how project change control works.”
The customer said, “Well, I want you to include these items in the project or I will escalate the problem to the senior VP.”
You smiled again and said, “That’s appropriate because in our project change control process, it is the senior VP’s role to approve changes of this size. We have the data now so let’s go speak to the VP. We’ll ask if she is willing to expand the scope and add the cost and duration of your change. But I’ll be honest with you. I don’t think we need any of these changes to hit the original scope we committed to for this project. It’s nothing personal. I’m just trying to exercise project change control.”
A Consistent Project Change Control Methodology
You need the right tools to do project change control correctly and that means a consistent methodology. The methodology begins with the initial planning of the project and gives the you tools and processes to identify the measured business achievements the customer/user wants the project to produce. This is not just the technical specifications. The project change control methodology guides you step-by-step through the development of a dynamic schedule and budget. Those tools allow you to quickly calculate the impact of a change order so you can exercise project change control. This methodology is also used in status reporting. You do the same modeling to calculate the impact of the corrective actions that are needed to solve variances.
You can learn a methodology to effectively manage project change control in our Project Management Basics course. It is private online training where you have as many video conferences and phone calls with your instructor as you need.
The critical path is the longest sequence of tasks in a project. The tasks on the critical path control the duration of the entire project. Any increase in duration of a critical path task will always cause the project’s duration to increase. The Critical Path is a great tool to help you shorten the duration of your project and plan corrective action. It lets you focus your attention on the tasks where adding resources will allow the project to finish early. Most project management software automatically calculates the critical path if you set up the schedule properly. That means you don’t enter start and finish dates. Instead, you use estimates of the amount of work and predecessor relationships between the tasks. This requires a little extra effort in the beginning but it gives you the critical path method for the life of the project. Project Schedule & Software Main Page
Use the Critical Path to Crash the Plan
You should use critical path analysis to optimize the project schedule. First you examine each of the tasks on the critical path, looking at the resources they are utilizing. You can shorten your critical path by adding resources to these critical path tasks. That’s called crashing the plan.
As you add these resources, the critical path can change. Although the critical path is the longest path, there are always several paths through the project. As you shorten your critical path, its duration will decrease. After you add resources, a different sequence of tasks often becomes the critical path. That’s why most project software is continually calculating the critical path. It identifies the tasks that are on it, usually by coloring them red. After your critical path has changed, you examine those tasks for opportunities to add resources to shorten the tasks’ duration and, thus, the project’s duration. Remember that you gain nothing by adding resources to noncritical path tasks.
Use the Critical Path to Fast Track the Plan
You can also change the duration of the critical path by altering the predecessor relationships between the tasks. You look at the tasks on your critical path and focus on those that have a finish-to-start predecessor relationship. For example, task A and task B have a finish-to-start relationship if task A must finish before task B can start. Some tasks must have finish-to-start predecessors. If you are building a house, for example, the foundation (task A) must be dry before you can start building the walls (task B). But there are some tasks where you can alter the pure finish-to-start predecessor relationship. You can start the second task a few weeks earlier than the pure finish-to-start predecessor would allow. An example is a design task (task A) followed by a construction task (task B). You might be able to begin the construction task (task B) before the design task (task A) is totally complete. Once again, you would only do this on critical path tasks so that the fast tracking change will shorten the project’s critical path.
Use the Critical Path for Trade-offs
Whenever the project sponsor talks with you about finishing earlier (and that may happen weekly), you can use the critical path and your project software to model options. If the sponsor asks about finishing 10 days earlier, you would use your critical path and schedule software to calculate how many more resources you need to do that. You would examine your critical path tasks and focus on the longer ones because you want to gain 10 days of duration. If you found task #31 on the critical path and it was currently scheduled for a 20 day duration (4 weeks), you might look at it more closely. If that task had one engineer doing 160 hours of work, you might model an option of adding a second engineer and spreading the work between two people. That should come close to reducing the 20 day duration to 10 days or so. Then you could offer the sponsor a trade-off off by saying, “If you give me a second engineer for task #31 for two weeks, I can cut the duration by 10 days.”
Use the Critical Path for Change Requests
Every project manager has to deal with requests to change the project finish date, the budget or the scope. These “requests” come from people who outrank you or sign your paychecks. You can use the critical path method to assess the trade-offs between the various dimensions of the project. Then you can present options to the sponsor and stakeholders for changing the project’s scope, duration, cost or risk to better fit their requirements. It’s wise to go into meetings with options for those changes already modeled so you can present them when someone asks. You’ll have the data available to tell them what the scope change will cost in terms of increased budget and increased duration. The best technique is to use trade-offs between the project’s dimensions, the “4 corners” of scope, duration, cost and risk, to handle the change request and maintain the project’s feasibility.
Critical Path Requirements
You use trade-offs analysis between scope, duration, cost and risk during planning, during each week’s status meeting, and on all change requests/change orders. The critical path technique helps you calculate them. You can:
Decide which problems you have to solve and which you can safely ignore
Find the cheapest way to shorten the duration of the project
Assign your best people to the tasks that control the project’s duration.
So why don’t more project managers use the critical path methop? Because it requires you to use the following scheduling techniques:
You must base durations on availability and work (i.e., a task with 12 hours of work for a half-time person takes 3 days’ duration)
You must use predecessor relationships to control task sequencing (i.e., start-to-finish or finish-to-finish) rather than entering start and finish dates.
Those two techniques are the foundation for critical path analysis. They will save you hours of work because your schedule will dynamically update. That makes learning them worth learning. In the picture below, the tasks in red are on the critical path, the longest sequence of tasks. The tasks in blue are not on the critical path.
Critical Path in the Software
Notice how the sequence (or path) of red tasks takes longer than the other paths. Now look at the blue tasks that run from row #14 – Row #25. They finish almost a month before the red tasks on the critical path. How could you use that information? Remember that if any of those blue tasks finish a little bit later than planned, it’s not going to increase the overall duration of the project. So if you want to shorten the duration of the project, you could take resources off some of those blue tasks (which would make them take longer) and have them work on a critical path task. That’s one way to shorten the duration of your project and you should model that option in the software. An added bonus is that when you can identify that kind of opportunity, shortening the duration doesn’t increase the project’s costs.
Another way you can use the critical path is to decide how serious a problem is. As an example, if the person working on task #18 tells you they made an incorrect estimate and their task is going to take five days longer than planned, should you become hysterical? No. A quick look at the critical path information shows you that task #18 can finish weeks later than its current scheduled completion date without affecting the duration of the project. Consistently successful project managers have information that lets them decide which schedule variations they have to solve and which ones they can accept. That saves a lot of wear and tear on you and the project team.
Using these critical path techniques save you time and give you information to make better decisions about your projects. We cover these critical path tools and techniques in all our customized, personal online training courses. You will work individually with an expert PM and learn how to optimize schedules so the project finishes as soon as possible. You’ll also learn to present the project stakeholders with trade-off options based on your critical path analysis. You work privately, 1-to-1, with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish. Take a look at the courses in your specialty.
Let’s talk about why you need a Change Control Process. Have you ever had one of those days, when you have reviewed the schedule and the project is running tight? Then a manager walks into your cube and tells you to “squeeze in” a change to the scope and maintain the current completion date. You explain that the schedule and scope have already been approved. So you will have to assess the effect of the change on the schedule and present it to the project sponsor for approval. The manager says that you have always done a great job delivering your projects on schedule. So they are confident you can make this simple change and still meet your schedule. Change Control Main Page
No Change Control Process
Let’s consider what can happened if you don’t have a Change Control Process. Your boss asks you to squeeze in a requirement. On the surface, the requirement looks simple and should not take much time. You do not want to disappoint your boss, so you agree. You decide to have Janet work on this since she has time before her next task starts. Janet explains that she is working on another project during her slack time between tasks on your project. She could not possibly work on this new requirement. Gosh, that is right. The project team is only being loaned to you. You don’t “own” all their time.
Well maybe Bob could slip this into his schedule. Bob is amenable. He can start work on the change and try to complete it in the time that will allow you to stay on schedule. One week later, the day before the due date, Bob comes to you and says he’s sorry but he cannot finish the task. His manager is pulling him back because Bob has used all the hours his boss agreed to for this project.
Now you must find someone to finish Bob’s task by tomorrow. What are you going to do? The schedule is slipping since Bob is not available to work on the task. Your brain starts rushing, thinking about who could fill-in for Bob. Then your thoughts turn to dread. How are you going to explain the slip to the sponsor? You accepted the change from your boss without going through the Change Control Process. Where are you going to get the additional resource to finish Bob’s work without disrupting something else? What following work is affected by slipping Bob’s task?
Change Control Process
You know that any change comes with a cost or an effect on the project baseline. To support an additional requirement, a company manager or stakeholder must follow the Change Control Process or they must create another project. Changes and additional requirements add to some aspect of a project; the time, cost, quality, resources, scope, or risks. If the additional requirement can be handled on a non-critical path task, it may be possible to support the manager’s or stakeholder’s request. Nevertheless, you should follow your Change Control Process and ask the manager to help you complete the appropriate change request form. You will review the change with the team to assess the effect on the current schedule and other aspects of the project. The change request and the estimated impact will be presented to the project sponsor for their consideration. The project sponsor will make the determination if the change is important enough to modify the current, approved project plan and baseline.
Having and following an established project plan and Change Control Process coordinates everyone’s work to achieve successful project completion. Changes are often necessary and change requires the stakeholders, project manager and the team to follow the Change Control Process to successfully continue the project work and meet the objective.
The point of the project change management process is not to prevent changes. It is to ensure that changes to the baseline project plan are carefully analyzed and are necessary to produce the approved project scope and deliverables. Change order requests are a central element in the project’s change management process. All changes to the project baselines for scope, budget, schedule, quality and risk are documented and analyzed as part of the project change management process. It’s the project manager’s job to gather the information about each change request and analyze the effect of the change on the entire project. This information, along with the project manager’s recommendation, goes to the project sponsor, the change control board or the configuration management committee for final approval or disapproval of the request. Change Control Main Page
The project manager’s responsibility in the project change management process is important from several perspectives. First, you need to ensure your stakeholders and team members submit change order requests and go through the change management process. You should never allow stakeholders to make changes to team members’ assignments, the specifications of deliverables, or to add new deliverables or tasks without going through the change management process. By adhering to this requirement, you prevent scope creep. That’s where the project plan changes without explicit analysis, approval and control.
Second, your job is not to prevent changes to the project. You should encourage people to come up with new ideas and better ways of doing things because that improves the project. By encouraging change requests, you maintain good relationships with the project stakeholders.
Third, a consistent project change management process built around change order requests ensures that all ideas are treated the same. Requiring change order requests whenever someone wants to alter the scope, duration, or budget is a best practice. It allows you and the sponsor to consider the consequences of that change on the rest of the project. Without change order requests, seemingly inconsequential changes to the scope can cause substantial increases in the duration and/or the budget that no one anticipated.
Fourth, a little bit of thought about consequences, especially unintended consequences, is worth the time invested in the analysis. Many people can request a change to a project but you, the project manager, should always assess the impact of that change on the project’s scope, duration, cost, risk, quality, and resources. You should also include your recommendation on whether the sponsor should accept or reject the change order request.
Project Change Management Process
It’s very easy to go too far with paperwork in the project change management process. The point is not to make change control a bureaucratic jungle of forms and procedures. You want to make it easy and straightforward so you can promptly process change order requests and give decision-makers the data they need. As importantly, the change management process should not aim at reducing everything to a single piece of paper. It’s wise for you, or others engaged in evaluating change order requests, to actually talk with the people who submitted it. Stakeholder management is most effective when people feel that you are listening to their ideas or the problems they have identified.
Below is a bare bones change order request with the key elements you and sponsor need. A stakeholder does not have to fill out this form. An effective processes is for you to use it as a guide in your discussion with the stakeholder about a change.
Project Change Management: Minimum Change Order Request Elements
The dates of each step and the identity of the people should be included in the change control process.
DESCRIPTION of the change. The focus should be on the specifics of how a change order request will alter a deliverable’s specification or the process used to produce it.
REASON the project plan should change. Include specifications of the problems this change order request will solve.
SCOPE- Impact of the change order request on the project scope. The project plan is a pyramid of deliverables with the scope at the top. The deliverables throughout this pyramid support the higher-level deliverables above them. You need to analyze changes to lower-level deliverables in relation to the impact the changes will have on the higher-level deliverables.
RESOURCES & WORK – You need to assess, and usually re-estimate, the work required in the tasks affected by the change order request. That should include a description of changes required in the skill sets of the people working on the tasks affected by the change.
COST – You should estimate the cost impact of the change request in terms of materials, equipment and supplies as well as changes to existing contracts and the cost of the people assigned to the task.
DURATION & SCHEDULE – You should use project software to model the impact the change order request will have on the duration of the affected tasks. The software will determine if the change will affect tasks on the critical path and how the change will ripple through the project and affect the overall completion date.
RISK – You should review the list of identified risks and determine if the change request affects any of the existing risks or creates new risks.
QUALITY – You should assess whether the change order request will affect the quality or specifications of any of the project deliverables.
It is a useful stakeholder management tactic to include the person making the change request in the analysis. At the very least, you should review the analysis with them before passing it on to the project sponsor. It’s best if the requester can agree with your analysis. But it’s also important that you know where you disagree before passing the change request on to the decision-maker(s).
Project Change Management Process Steps
Step 1: As the project manager, you receive a change order request. The first step is always to see if the situation can be resolved with corrective action that would not change the project plan or any of its components.
Step 2: If corrective action fails or is not an option, you analyze the change orderrequest. You document each of the items listed above and make your recommendation for approval or rejection of the request. You should complete the analysis in a timely manner and include quantification of the impact of the change on the project scope, budget, duration, etc. as detailed above.
Step 3: You forward your analysis of the change order request to the project sponsor with your recommendation for approval or rejection of the request.
Step 4: The sponsor decides whether to approve or reject the change order request and the consequences. You document the result.
Step 5: If the sponsor approves the change request, you implement it by changing the project budget, schedule and scope as necessary. Then you alter the team member assignments to reflect the changes. You follow these same steps for all change order requests.
Step 6: You should archive the change order request and all supporting documentation. This information is invaluable for handling future requests.
Project managers use trade-offs during project planning and every week during the life of the project whenever they have a variance or a change request. Project Manager Skills Main Page
Here is an example of a project trade-off. The sponsor demands an earlier finish date and the project manager says, “Yes I can shorten the duration of the project by two weeks. But to do that, I will need to have two additional engineers for the month of April.” A trade-off has two sides. First, there’s the positive side where the PM shortens the duration of the project. Second, there’s the negative side where the project manager says they need two additional engineers for the month of April. Trade-offs are part of the language good project managers use. You must build the project plan with quantified measurable outcomes. And the schedule must have work estimates and accurate precedence relationships. Then you can model every change with a compensating trade off. Risk Management
When project sponsors want to make a change, successful project managers never say, “Oh no, we can’t add that to the project.” What they say is, “Certainly I can add that to the project, but I will need three more people full time.” Or the negative side of the trade-off could be, “We will have to increase the budget by $10,000” or “We’ll have to reduce the savings in our scope by $6,000.” This is the language of trade-offs. The project manager is not saying no. Instead, they are telling the sponsor or stakeholder what it will “cost” to bring about the change they want. Trade-offs maintain the feasibility of the project. Merely shortening the duration does not.
Project Trade-off Language
Successful project managers use trade-offs between the scope, schedule, cost, risk and quality when they assess problems and changes to the project plan. When anyone wants to add or change something in your existing project plan, you should always assess the impact on all of the project’s dimensions. If the change is significant enough to require a change order, you should document the project trade-offs. That trade-off information allows the sponsor or customer to decide if the change is worth making. You should also use trade-offs when a status report shows variances to the plan and their proposed corrective action. Status Report Template
Here’s a detailed example of using project trade-offs. Let’s say the schedule has a task that was originally underestimated. Now the team member working on that task says it’s going to take 160 more hours of work and two weeks longer than originally planned. The PM agrees with the new estimate and quantifies and documents the impact of that increased time on the project budget. The remaining 160 hours of work will take 4 weeks at the rate of 40 hours a week with the one team member. That will take the task duration four weeks beyond the baseline plan. Because the task is on the critical path, it will cause a 4-week delay of the project completion date.
Knowing that the sponsor will not accept that slippage, the project manager then develops alternative trade-offs for dealing with the situation. First, the PM looks at the trade-off that comes from adding one contractor to the task. Then the existing team member would do 80 hours of work and the contractor would do the other 80. If each worked 40 hours a week, they could finish the task in two weeks rather than four weeks. The cost for hiring the contractor is $100 an hour so the project budget would increase by $8,000. The project manager would present this trade-off as reducing the duration by two weeks for a cost of $8,000.
The project manager decided to also model the trade-off of hiring two contractors. Then the PM could divide the 160 hours’ worth of work among three people. Each person would have to complete 53 hours of work, which would take each of them 1.3 weeks. That duration is a material reduction from the first trade-off. Now we come to the matter of the cost and this is the part people usually get wrong. Adding the second contractor would not double the $8,000. The contractors together would do approximately 160 hours’ worth of work at $100 an hour. So the fees for the contractors in this example would be $16,000. That gives the PM a second trade-off to present to the sponsor.
There are many other types of trade-offs the project manager could use. They might reduce the scope of the project, which usually reduces the amount of work and the duration. There are also trade-offs for quality and risk that could be considered. With this explanation of how trade-offs work, let’s talk about how we use the idea of trade-offs in managing the project.
We can think of a project as having four corners:
project scope (including deliverable quality),
cost (human resources and materials).
Think of a project like a tube of toothpaste. When an executive squeezes on a project’s duration corner by cutting the due date by a month, the toothpaste compensates by oozing out from one of the other corners. When the sponsor squeezes the duration, it will deliver less scope, cost more, or have a higher risk of failure. Changes in one corner always impact at least one other corner. We have those effects whether people recognize or not. It is not realistic to assume that making arbitrary changes to one corner of the project, like the duration, can happen without any compensating effects through the rest of the project.
Why don’t sponsors recognize the impact? Because in most projects only one, or at most two, of these corners is measurable. The completion date is always measurable and is often rock solid. In some situations, we have a project budget that is also measurable. But most internal projects have no other measurable dimensions. Even with the two measured dimensions of duration and budget, the business value of the project (the scope) and the risk of not delivering that scope on time are usually unmeasurable. So executives continue to make arbitrary changes to the duration and the budget and think that it will have no impact on the scope of the project. Just think about what happens when a project manager goes back to his team and says, “We have to finish two weeks earlier.” What will the team members do? They will look for shortcuts. The quality may go down and the level of deliverables produced may suffer as a result. They also take shortcuts that increase the risk of the project failing. But no one knows.
Therefore, project sponsors assume there’s no risk from their arbitrary reductions in duration or budget. They are 100 percent confident in delivering the scope within the duration and/or budget. Now every project manager knows100 percent confidence is ridiculous. Particularly because most organizations have a project failure rate above 50 percent. Yet few project managers give their sponsors the opportunity to make decisions about the level of confidence they want.
There is a better approach. If you have a quantified measure of the project’s scope (the business value) and you follow best practices when building the project schedule and budget, you can present your sponsor with quantified trade-offs between the “4-Corners” ™ of the project plan. This data-based decision making and “fine-tuning” is a good platform for approval. It is far better than arbitrary changes to one or more of the “4-Corners”™ without any offsetting changes to the others. You will also use these quantified trade-offs every time there is a variance to the plan. Your status reports should include trade-off analyses between the “4-Corners.”™ That gives executives data to evaluate the alternatives for taking advantage of opportunities and recovering from problems.
This project trade-offs approach is inconvenient for executives who want to make a change to just one corner. If they do that, you will have projects that aren’t feasible, are late, over budget and achieve less than planned. Arguing with the project sponsor doesn’t work, particularly when they are your superior or your customer. What does work is using decision-making data. That’s the benefit of using project trade-offs.
Foundation for Project Trade-Offs For Scope, Budget & Duration
The foundation for developing alternative combinations of scope, budget and duration is building a project plan and schedule using best practices. The requirements are that you define every deliverable and every task in the work breakdown structure (WBS) with acceptance criteria. That way there’s no ambiguity about the progress or the completion. You base the project plan and schedule on work estimates, not just start and finish dates. With those components in place, you can offer the sponsor and decision-makers alternatives and trade-offs between scope, budget and duration.
During the initial presentation of the project plan, you should model at least three project trade-offs or alternative ways of doing the project. Starting from the base design, you construct three project trade-offs to finish at least 20% earlier than the base design. You also construct three alternatives that collectively lower the cost of the project by 20%. Having these options available during the project presentation gives you the ability to answer the question that executives often ask, “How can we do this cheaper and faster?”
When your weekly status report shows variances from the plan, you should use project trade-offs to model alternative corrective actions to address the variances.
When you have change requests, you should assess the impact of the change on the project scope, budget and duration and then present trade-offs between those constraints.
Project Trade Offs Summary
It is a project management best practice to assess the impact of a change or variance on the project’s scope, cost, duration and risk. Then you model project trade-offs between those “4-Corners” ™ and give the decision-makers alternative ways to deal with the opportunities and problems.
To learn the specific techniques for framing your projects and developing these “4-Corners”™ trade-offs, look at our project management bookstore or consider taking one of our project management training courses. We offer them in-person at your site or as online courses where you work privately with your instructor according to your schedule. More on Decision Making Data,
To master these techniques and the way to present them to the project sponsor, take a look at our advanced techniques courses in your specialty.
In many organizations, saving failing projects is a regular part of the job of all project managers. Most PMs have had to rescue their own projects from time to time. In fact, one of the traits of superstar PMs is that they can bring their own projects back from the edge of defeat. So how should you do a project rescue? Enterprise Project Management Main Page
Let’s say that toward the end of your project’s planned time and budget your weekly monitoring of results shows a continuing slide toward overruns. You realize that continuing to hope for outstanding performances from a few team members will most likely not let the team catch up. Before you surrender and call the sponsor, there are a few things you can do to avoid failure.
Project Rescue: Continuous Monitoring
First of all, continuous monitoring of your project’s schedule and cost with estimates to complete (ETC) is an essential part of all effective rescues for turning your project around and managing expectations. Let me give you an example. One of my projects still had about four months in duration but from my control sheets, my personal opinion, and the history of change requests and challenges, I was pretty sure that we would not deliver the entire scope that was originally agree upon. Here is my point. Because I had monitoring tools in place, and because I kept a personal log on where we were in the project, I was able to come to that conclusion a lot earlier than I would have if I would have not had these statistics in place.
Project Rescue: Clarity on Project Scope
Second, as I pointed out in one of my earlier posts, (Project Failure Warning Signs) I had a visual representation of the agreed scope in place and the supporting high-level deliverables. This picture was another component in my planning and forecasting toolbox. Using this picture, I was able to mark those components that were in danger of failing. Combined with my statistics, I was able to draw a picture of what was still possible. Project Failure
You can usually see when things start to turn against you and try to steer against those tendencies. However, in my case, my actions did not result in total victory. At one point, I had to tell my stakeholders that we had a problem at hand. What I would like to encourage you to do is this: when things don’t work out, the sooner you raise your concern the more time you have for implementing workarounds. Furthermore, if you are able to visualize what you have already accomplished and what is feasible by your determined project deadline, you are in a much better position than if you just inform your sponsor via email. In my situation, I was able to point out why we were behind, what we would be able to accomplish and how that would improve the company’s overall situation. I can’t point out this action often enough: visualize your arguments. With a picture of the original scope and the “realistic” scope at hand, I was able to show that even though we would not complete everything, we would complete the most important components. Project Catastrophes
Project Rescue: Work through Alternatives
In addition, since we raised the red flag early enough, we had enough time to work out alternatives and refocus our development team. My project has not yet finished but I am pretty sure that we will produce a result that will be more than acceptable, even though we didn’t hit a bull’s eye.
Project Rescue: Summary
In conclusion, I encourage you to do the following:
Have a clear project scope and supporting high-level deliverables
Continuously track your project progress. Visualize what you have already accomplished and what is feasible
Don’t just raise a red flag, visualize your arguments. Show what you can do and how this result will still improve your organization’s processes
Start working on alternatives and a fallback solution as early as possible. Don’t wait for someone else to point out the problems.
Every project manager does project scheduling. Some do it on a yellow note pad, others use an Excel spreadsheet and still others use software specifically designed for project management. Some project managers have very little data to help them successfully managing their projects, deal with change orders or respond to variances. They may not even know when they have a variance.
Other project managers are able to quickly gather information about problems and opportunities. This allows them to profitably handle change requests and control variances. The PMs using project scheduling software can also optimize their schedules. In this article we’ll show you how to do these things
Previously, project managers justified not using project management software on the basis of the software cost and the amount of time they would spend learning how to use it. Those two excuses are no longer valid. There are some adequate project management software programs that are free and easy to learn. It only takes 30 to 40 minutes to learn how to use the software through the entire project lifecycle. Gantter is a free program with your Gmail account. There are editions for smart phones, tablets and desktops. This software provides all the capabilities you need for small and medium-size projects. The learning curve is short considering the benefit you get. Project Schedule & Software
More capable software for larger project scheduling includes Microsoft Project®. It is almost $600 but provides more capabilities and a tremendous amount of decision-making data. It includes the ability to do budgeting and cost tracking and also manage multiple projects. These features are adequate for even large projects. You will need to invest a few hours of time to learn it.
Advantages of a Software-based Project Scheduling
Now lets talk about how a project manager using a yellow note pad, an Excel spreadsheet, or project scheduling software would handle three common situations.
Project Scheduling: Telling the Client the Finish Date, Changes & Status
The project manager doing project scheduling with a yellow note pad can quickly tell the client the finish date by using his or her ability to pick a number out of the sky. There is no basis for this completion date other than a guess about how long the project will take. This “yellow pad project manager” makes a similar guess about the cost. Projects scheduled on yellow pads usually finish late and cost more than anticipated. This means the project manager and their company lose money if they’re doing a project for a customer or client. This project manager uses the same approach when the customer wants to change the project or the deliverable in some way. The project manager guesses about the impact the change will have on the finish date and the cost. And they are usually wrong. The yellow note pad project scheduling technique gives project managers a very limited career future.
The PM doing project scheduling with an Excel spreadsheet does a bit better. He or she enters start and finish dates for all the tasks they can think of. Then they let the program give them an idea of how many days or weeks it will take to complete those tasks. The problem with using Excel spreadsheets for project scheduling is that if the client wants to make a change, the project manager has to redo the entire spreadsheet. The same is true if the client adds a task or alters a finish date. The “Excel spreadsheet project manager” spends endless hours laboring over their PC instead of managing the project.
The project manager who uses project scheduling software does the best of all. If they are using the software correctly and following best practices, they base the project schedule and budget on work estimates. Instead of picking a finish date with a Ouija board, this project manager works with historical data, published estimating information, and the opinions of the project team members. They use this data to build a schedule based on estimates of the amount of work required. Then the project manager lets the software do all the calculations. They decide how much work each team member can do and the project scheduling software will assign the work to the team members so the project finishes as soon as possible. This takes about two seconds. This project manager can work with similar speed on a change request. They merely change the amount of work for the task(s) the client wants to alter. Then a nano second later, the software re-schedules the entire project and gives the project manager a new completion date reflecting the change request. If the project manager has entered hourly rates for the team members and the material costs, the software will also calculate a budget and give the PM data on the cost of that change request.
Finally, the project manager can give accurate status reports based on the team’s estimates of the amount of work they still have to complete on their tasks. This lets the project manager anticipate problems early, not after getting hit in the face with them. There is a very good reason consistently successful project managers use project scheduling software. It allows them to spend their time managing the team and solving problems. They don’t have to spend their time making guesses or laboring over an Excel spreadsheet or a yellow note pad. And when project managers also use work estimates, they gain all the benefits of the project scheduling software.
Project Scheduling: Optimizing the Schedule
Too many project managers control the sequence of tasks in their projects using the start and finish dates. They should use project scheduling software with predecessor relationships. For example, these relationships tell the software that Task B can’t start until Task A is finished. Or that Task A and Task B must finish at the same time. Entering start and finish dates wastes an enormous amount of time during the original creation of the schedule and every week after that. Project managers who don’t use project scheduling software with predecessor relationship spend hours updating their schedules and changing all the start and finish dates. Even worse, the schedules they create with this fixed date technique almost always have longer durations than they should. However, project managers can experience these problems in project scheduling software like Microsoft Project®. This happens if they use start and finish dates to control the sequence of tasks rather than using predecessor relationships.
Dynamically Scheduled Projects Make the PM More Efficient
Predecessor relationships are the key to building dynamic schedules. These are schedules that update themselves whenever you make a change. As an example, if you discover that Task D is going to finish two weeks early, or two weeks late, you merely enter that fact into your project scheduling software. It will automatically change the start and finish dates for every one of Task D’s successor tasks. The alternative is to manually change each task’s finish date. Using predecessor relationships saves you hours in the initial project scheduling and significant time every week for the duration of the project. That is reason enough to use this project scheduling technique. How To Use Dynamic Project Scheduling
Dynamically Scheduled Projects Finish Earlier
Using dynamic scheduling, you set up our predecessors in the software by identifying the type of relationships that each task has with its predecessors and successors. There are three types of predecessor relationships:
A Finish-to-Start predecessor relationship between Tasks A and B is scheduled by the software so that Task B starts after Task A is finished. You’ll use this type of predecessor 85% of the time. That is why it is the default in project scheduling software.
A Finish-to-Finish predecessor relationship between Tasks A and B is scheduled by the software so that these two tasks start at the time that’s required for both of them to finish at the same time.
A Start-to-Start predecessor relationship between asks A and B is scheduled by the software so that these two tasks start at exactly the same time.
You can get fancier with predecessors by using leads and lags. But these three types are the basics and are a great way to get started.
Parallelism and Concurrency Also Let Projects Finish Earlier
You make a project take less time to finish when you sequence the tasks by building in parallelism. This means you have many things happening at the same time. It makes sense that if a project has three or four tasks going on at the same time it will finish earlier than a project that has only one task happening at a time. In other words, you don’t want the whole project to be a long sequence of Finish–to–Start relationships. Instead you want to design the predecessor relationships for each of your major deliverables so as many tasks as possible are occurring at the same time. The simplest way to create parallelism using the project scheduling software is to give a task multiple successors. Here’s an example of a task with multiple successors that creates three parallel paths in the project. Whenever you can do that, you will shorten the project duration. A parallel design is always going to take less time than scheduling those three tasks to occur one after another.
There are obvious limits on parallelism, such as limits on how much work a person can do and the technical or physical dependencies between tasks (e.g.: the materials must be delivered before they can be installed). But using predecessor relationships lets you avoid unnecessarily long task sequences. That makes reporting and updating faster and saves you hours of time.
Take a look at our online Project Management Basics course where you can learn these techniques from an expert PM. In this instructor-led online training you have as many phone calls, e-mails and live video conferences with your instructor as you need.