A project’s cost benefit analysis is important in any organization, especially in the banking sector. It always comes down to costs and benefits. The perceived value of a project and the prognosis for approval heavily depend on the ability of the project manager and sponsor to show how it benefits the organization. The tool most often used to justify projects is the Cost Benefit Analysis. Cost Benefit Analysis Main Page
Now a cost benefit analysis or CBA is meant to be an objective tool, using numbers and math to determine the true potential of a project. However, there is an issue with its total objectivity. The three basic components of every CBA are:
a mathematical analysis of the assumptions with inputs like numbers and volumes
the time series.
The last two components are objective. But the selection of assumptions is a mainly subjective process and it leaves plenty of room for creativity.
In organizations that rigorously use CBA’s, one of the tricks project managers often use is to include assumptions on benefits that are hard to measure. Examples are intangible benefits, avoided costs, avoided investment, stronger customer loyalty, stronger brand, etc. Although there is nothing wrong with trying your best to justify a project, I believe there is an issue with basing a case on difficult to measure benefits.
These assumptions often produce estimates that are difficult to prove. They look good on paper, but are easily challenged in a board room. Cost Benefit Analysis with fat numbers based on intangible benefits can be deflated and cause the board of directors to distrust the project manager. These assumptions become weak when faced with simple questions like, “Will these numbers be visible in the P&L?” And when you answer with, “No but….,” the executives most probably stop listening.
Some companies do follow-ups after projects are closed to verify the assumed benefits were realized. If a project with bloated numbers is actually approved, the project manager has a tough time proving the existence of the promised benefits.
For a current example, we can look at what is happening in the IT industry where the disconnect between promised and actual results is often large. There are many suppliers that meet with executives and promise huge savings in implementing IT best practices, such as ITIL or COBIT.
The company ITSMF, for example, makes several outrageously unsubstantiated claims in its An Introductory Overview of ITIL [version 2] . *”Over 70% reduction in service downtime, ROI up by over 1000%, Savings of £100 million per annum, New product cycles reduced by 50%.”*
However, looking at it from the other side, we see different results. *”In a survey carried out by Bruton of 400 sites, about half of the 125 organizations which were found to have adopted ITIL made no measured improvement in terms of their service performance…”*
Finally, I do not really trust nor like an “outsmart them”approach when writing a CBA. My advice: be pragmatic and state strong, measurable and clear assumptions in your figures. If the project is strategic but difficult to argue on paper, then build the case on the strategic part and state that the benefits are difficult to quantify. If there is only a 50% chance that the expected benefits will materialize, this fact should be clearly stated. By being truthful, accurate and straightforward, you can build the trust of your executive team and establish yourself as a trustworthy and effective professional.
A key part of a good consulting project plan is the work breakdown structure (WBS). We begin by defining the scope and major deliverables of the project with the client. This is when we start managing the client’s expectations about what the project will deliver. With agreement on the scope and high level deliverables, we decompose or breakdown each of those deliverables into smaller deliverables until we get to the level of an individual assignment that a consultant or client personnel will complete. As we work through the decomposition, we are specifying the end result we want from each assignment. We are not stating what we want the assigned person to do. As an example, we would not try to describe everything that a system contractor must do. Instead, we would specify that the subcontractor is to produce a GUI that the client’s payroll department staff can use to complete the weekly payroll in 5 working hours. That is a deliverable with the crystal-clear acceptance criteria. With every assignment in the consulting project WBS specified as a deliverable with acceptance criteria, we have clearly defined the work assignment for every team member, subcontractor and client personnel working on the project. The assignments or tasks in our WBS define exactly what a good job is for each assignment and how you and the client will measure it. WBS Work Breakdown Structure Main Page
Second, the work breakdown structure or WBS will show the methodology you use on the project to produce the required deliverables. If you and the client have decided to use an agile methodology, the WBS will include multiple iterations in the creation of each deliverable. It would include time for the client to assess the results and change the specifications after each iteration. On the other hand, if you use the classic waterfall project methodology, the WBS would include very detailed front end planning. You complete all the planning before you start work on the project.
Third, the consulting project WBS has to specify the testing and quality control procedures you will use at various checkpoints in the project. Some of the client checkpoints may be the testing of materials. Other checkpoints may be a government or regulatory agency’s comparison of what you have completed to the approved plans. Some testing tasks should include the number of transactions or samples you will test. That ensures you will estimate enough time for the complete testing procedure. That includes any external testing of the deliverables during development or prior to acceptance. They should appear in the WBS so the resulting schedule allows for adequate testing and quality control.
The project charter documents the project’s scope, objectives, resources, risks, assumptions, change control and the project manager’s authority. It should let the project manager identify problems and conflicts early so they can be resolved before the project work starts. It should help the project manager cope with the executive’s expectations about the project and how the PM will manage them. Project Phases Main Page
Project Charter: Common Problems
When problems arise mid-project, their impact is twice as severe as it would have been if you had dealt with them early. The project charter is not just paperwork. It’s a chance to avoid common problems that arise from the following:
Inadequate project manager authority
Misunderstandings about what the scope includes and doesn’t include
Unclear change control processes
Resources that don’t show up for project work
Risks that could have been prevented.
The project charter lays out the project’s high level scope, risks, constraints and resources. It is the framework for the detailed planning and should be approved before planning begins. Right after the scope is defined and major deliverables are identified, the project manager has the sponsor’s and stakeholders’ attention. It’s the best time to talk about what’s needed to produce the project’s deliverables. You have to be aware of the executives’ expectations, but they often don’t discuss them.
Bad Project Charter – What People Are Really Thinking
Let’s review a typical session where a project manager talks with an executive about the charter components. You’ll hear the words they say and then learn what they’re really thinking.
Project Charter: PM Authority
Project Manager’s words: “I will need the authority to coordinate the activities of the entire project team and integrate their efforts so we can achieve outstanding results. This authority must cross functional and departmental lines because the project does. I also need your support in securing resources, problem solving and change control processes.”
Project Manager’s thoughts: I don’t want a repeat of that last project where most of the team ignored their assignments. I spent hours each week begging and pleading with them to get their tasks done. This project is bigger and I’ll need executive support when there are problems.
Project Executive’s words: “Of course, you have my full support. My door will always be open if you have any problems getting things done. Now, exactly when are we going to finish and what will this cost?”
Project Executive’s thoughts: “Geez another project manager who wants to boss everyone around and have everyone in the company on the project team.”
Project Charter: Risks and Assumptions
Project Manager’s words: “I’m sure you’ve carefully read pages 46 to 77 of the project charter where I detailed the project’s risks. These are challenges that we must work together to resolve.”
Project Manager’s thoughts:I was up half the night thinking through everything that could possibly go wrong with this project and I think I got them all listed. So if any of those things happen, they can’t blame me.
Project Executive’s words: “That’s a very careful assessment of the risks. You certainly seem to have this project plan well thought out. I am in your corner.”
Project Executive’s thoughts: “Does this yahoo think this long list of excuses means that we won’t blame him? What a dope. If this project is late, the first thing I’ll do is end this clown’s career.”
Project Charter: Change Control
Project Manager’s words: “We need to freeze the project plan you’ve approved today. We all know the devastating effect changes have on our ability to finish on time and within budget.”
Project Manager’s thoughts:These executives always want to add new stuff to the project whenever they wish. But they won’t change the due date and budget. That’s why we never finish on time and why no one’s ever happy with project results. That has to stop.
Project Executive’s’ words:“Well, there is a need for flexibility but I certainly agree that we want to keep this project on course.”
Project Executive’s thoughts:“This is my project and I will add whatever I want to the plan. And this PM will salute every time I do.”
Project Charter Failure: No Problems Avoided or Expectations Changed
Here is a project that’s ripe for failure. The executive has negative expectations about the PM and their project management abilities. The project manager’s technique let the executive gloss over the problems instead of dealing with them. No one made difficult decisions or commitments. The issues of the PM’s authority, risk management and change control were left to smolder; for now. Those smoldering embers will burst into flames in mid-project, when they will do the most harm.
There is a better way to present a charter. But it does not result in everyone leaving the meeting smiling and laughing. Why? Because problems and issues must be resolved now. Issues about borrowing people across functional lines, risks and making changes must be resolved before we start work. Let’s see how a strong project charter does this.
If you’re going to have problems getting resources when you need them, you must make an explicit request in the project charter. Don’t just ask for support. That means nothing. It’s best to find out now about issues with making assignments across departmental boundaries. You should communicate about your project management authority in your project charter with words like this:
Project Manager’s words: “This project requires approximately two hours a day from each of the following first-line supervisors during the month of June (List of specific names and titles). As project manager, I will “own” those two hours every day. During that time period, I’ll be able to directly assign work to those people from the approved project plan and schedule.”
Are those words likely to inflame existing issues about cross-functional or matrix authority? Yes they are and that’s the point. By being very direct and crystal clear about the resources and the kind of authority you need to get the project done, you inflame the issues early. That gives you the opportunity to resolve them. Now is the time to do it. You can link the resource issues to the project budget and completion date. Those things are currently at the front of the executives’ minds. You can persuade them to approve your request by presenting the efficiency and benefits of these requirements. You should state the delays and postponements that will result if we don’t get them.
Project Charter: Project Risks & Assumptions
You also throw gasoline on the project risk discussion by being direct about them. Identifying every possible risk and assumption does not insulate you from blame. The fact that a PM listed 157 bad things that might happen in the project charter has never in the history of project management protected a PM from being blamed for a failed project.
Rather than list everything you can think of and have no one read it, you should identify 2-4 significant risks that will cause the project to fail. You present these risks in the project charter
with an estimate of the likelihood and magnitude of the impact. You also offer at least one risk response for each. Next you engage the executives in a discussion of the ways to mitigate the risks. This includes specific things they can do. Then the executives can make a decision about what risks they want to run and what risks they want to try and mitigate. The project charter might identify a few risks like the following:
Project Manager’s words: “Ace Consulting has a long-term contract for engineering services based on charging hourly rates on a time and materials basis. They have many friends in the organization but they have a history of budget overruns and late finishes. This has happened on 16 of the 18 projects where we used them. Delays could cripple this project and cause us to finish months later than planned. I would like the authority to issue a competitive bid on the engineering services.”
Once again, the direct approach in the project charter may seem a little pushy. However, it’s usually preferable to suffering problems with this “politically connected” vendor after they cause delays in the project.
Project Charter: Change Control Rules & Process
The last fire you want to inflame is change control. Project managers who leave change control as an informal, casual process rarely have consistent success. They and their team members are routinely caught between wanting a satisfied client/user and containing the scope of the project. The project charter must address this issue.
The cure is to set precise rules about who can approve what kind of changes to the project plan. The project charter might ask for project manager change control authority like this:
Project Manager’s words: “I recommend a rule that no change of budget, schedule or deliverable can be made without my analysis of the impact on scope, cost, schedule, risk, quality and resources. And the changes must be approved by an accountable executive.”
By being direct in the project charter, you can solve potential problems early.
Project Charter Summary
The project charter documents the project’s scope, objectives, resources, risks, assumptions, change control and the project manager’s authority. It is the framework for the detailed planning and should be approved by the sponsor before planning actually begins.
To learn more about implementing these project charter elements, consider our project management courses. You learn with an expert project manager as your coach. Take a look at the courses in your specialty.
The project lessons learned process is ineffective in most organizations. One project after another suffers from the same mistakes. What is even worse is that the bigger the project failure, the less likely they are to learn from it. The same issues that cause a project to fail also prevent the people involved from learning from the failure. Organizations need processes to make sure they don’t relive project failures. Let’s take a look at a typical project lessons learned session and then talk about the right way to do it.
Project Lessons Learned: Poking Through the Wreckage
You shuffled into your project lessons learned session, sick and tired of political games and finger-pointing. Twenty minutes later, you trudged out with the voices still echoing in your head:
“You’re responsible for us finishing late!”
“Me? You kept making changes. I’m surprised we ever finished!”
“You still aren’t finished; the garbage you gave us still doesn’t work!”
“What? We gave you what you asked for! But you didn’t train your people to use it”
“They need PhD’s to use what you built!”
You walked down the hall knowing this was your fault. Sure, there were a few jerks involved and it would be easy to blame them. But a good project manager should be able to structure things to make even the jerks productive team members.
Even though scenes like this repeat themselves after every project, many organizations don’t improve their processes for doing projects. The same problems wreck one project after another. But there is an alternative. What you need is a lessons learned process that gives the project managers an opportunity for continuous improvement. The time you invest in your lessons learned process can positively affect projects that are underway. It can also reinforce the use of a consistent project management methodology. You build the project lessons learned process in the following three stages. Lessons Learned Project Management
Our 4PM clients have increased their success by using peer reviews of projects that are nearing launch. That sounds fancier than it is. In this first stage of the project lessons learned process, project managers get feedback on a their plans from other PMs. They have a meeting (in-person or online) to discuss a recent plan. That gives PMs the chance to share ideas and renew their understanding of the methodology.
The pre-launch stage is a busy time for project managers but it’s also the point at which correcting mistakes is least expensive. The process is straightforward. The other project managers review the user’s or client’s business situation. Then they independently critique the project’s plan, scope, requirements, WBS, charter, accountability structure, team member assignments and the schedule. Reviewing several project plans doesn’t take the other PM’s very long if the organization’s project management methodology emphasizes thinking , not creating paperwork.
In the project lessons learned session itself, the other PM’s ask questions and offer ideas. The project manager whose work is under review may or may not take them but they get the benefit of the ideas and opinions of other people engaged in the same type of work. Every project manager suffers from tunnel vision as he or she works through the development of a detailed plan. The thinking of other project managers who are not buried in all the detail is very helpful. It’s easier for them to spot any disconnects between the user’s/client’s business problem and the project plan details. It’s important to keep this conversation focused on “Are we doing the right project for this business problem?” and “Does the planned control process make sense for the desired business result and resources involved?” The conversation should be at that high level and not sink into a technology debate.
Project lessons learned sessions are effective in building consistency in the use of a project management methodology. Compliance with project management standards tends to slip under the pressure of all the work to be done just prior to launch. But when project managers know their peers will be reviewing their work, they comply at a point in the lifecycle where comments from the project office or standards people might otherwise be brushed aside. These pre-launch peer reviews are ideal for reinforcing the organization’s project management methodology. You have the right people gathered and you’re dealing with real business situations and projects, not theoretical ideals. So these sessions are good opportunities to renew people’s skills in using the organization’s project management methodology.
The second stage in the project lessons learned process is regular (usually weekly) review of project variances. This can be at the end of the weekly status report or team meeting and after you have defined corrective action for the variances. You review the variances again and focus on how to avoid them in the future. You also identify other tasks or people who are likely to encounter the same issue so it can be avoided. The focus is on ways to avoid a repeat. It does not take long to identify the options.
To accomplish this project lessons learned review, the project methodology must give you a reliable method of identifying changes to the approved baseline schedule. You need a methodology that gives you objective measures of project progress plus the work and cost estimates to measure the variance.
Project Lessons Learned: Stage 3 – Project Team Culture and Leadership Style
The last stage of the project lessons learned is the periodic assessment of your leadership style and the culture of the project team. The work attitudes and effectiveness of the team members are strongly influenced by your leadership behavior. Even a professional team may suffer in silence about the project manager’s leadership and not take the risk of providing constructive feedback. Frank feedback is very useful so you have to make it safe for them to give it.
An effective technique is to ask the team to have lunch together once a quarter. You don’t attend but you ask them to a write a summary of their consensus of your strengths and weaknesses. You should digest the information but not ask questions about it. Most importantly you should not make them justify any of their negative findings. That makes you seem defensive. Good project managers act on negative feedback and make improvements. Bad PMs can’t handle the criticism so they dismiss it, learn nothing and never improve. Lessons Learned Questions
Project Lessons Learned: Summary
The three-stage project lessons learned process for project management improvement is an important element in moving the organization toward delivering consistently successful projects. It also can contribute to developing consistently effective project managers. We include this project lessons learned process in our project management methodology so organizations and their PMs get better over time and don’t repeatedly relive failures.
You can enhance your PM skills and master the project lessons learned process in our online project management courses. You work privately 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.
One path for beginning your project manager career is getting the Certified Associate in Project Management CAPM® credential. This is an internationally recognized certification from the Project Management Institute (PMI)®. This credential is an effective resume-builder because you learn the language of project management and its processes, techniques, terms and definitions. Project Manager Certifications Main Page
There is no project management experience required for this certification but you must have 23 hours of education in project management and pass a 3 hour, 150 question multiple-choice exam. The information covered by the CAPM examination represents the best practices in project management. The information covered by this exam is in the ProjectManagement Body of Knowledge (PMBOK)®. It includes the project management knowledge areas which are: project scope, project time, project cost, project human resources, project communications, project quality, project procurement, project risk, project integration and professionalism. You will learn all these project management knowledge areas and best practices in our CAPM Exam Prep course. You will read about the project management information and watch online lectures. Then you’ll take CAPM practice exams and learn from explanations of the questions you missed.
The CAPM exam is administered at Prometric learning centers around the world. You must submit an application to the Project Management Institute (PMI) to be admitted to take the examination. The test is 150 multiple-choice questions and the time limit is three hours. You will find out immediately upon completing the examination if you have passed. PMI allows you to retake the exam if you did not pass.
You may also want to learn the basics of a proven methodology with practical tools and techniques for managing projects in a particular industry like IT, construction, healthcare, consulting or general business. These courses include practice on an industry-specific project case study and step-by-step instructions for using project management software. Take a look at the basics course in your specialty.
When you write your weekly status report, remember that it’s your best opportunity to address any concerns of your project sponsor. It’s also an opportunity to get support and decisions that you need to finish the project successfully. Let’s think about the sponsor’s perspective of a new project manager with whom he or she is not familiar.
Weekly Status Report – Address Sponsor’s Concerns
Here’s what the sponsor is concerned about:
Does this project manager have control of what’s happening on the project?
Does he know about any problems or will he be surprised down the road?
Where are we today and what’s the forecast of costs and finish date?
Those are very reasonable questions and concerns for a project sponsor so you need to write your status report to answer those questions. If you can provide answers to those questions, you will go a long way in building your credibility with the sponsor and gaining their support for the things you need to finish the project successfully.
Watch this video about writing and presenting status reports.
Giving the First Status Report on a New Project
Weekly Status Report – What to Include
Before you start to put together a massive data dump, here are some things to keep in mind as you decide what to include:
The project sponsor and other stakeholders are not familiar with all the details of your project. Don’t assume they know as much about it is you do. The best approach is to assume that they know the name of the project and nothing more.
The sponsor and stakeholders have a limited amount of time to spend and they’re not going to sit through a 30-slide PowerPoint show or a deep dive into the project data.
They are primarily interested in learning if the project will finish on time and within budget. The best technique is to answer those questions in the first 60 seconds. If the news is good, it will relieve their concerns. If the news about budget and completion date is bad, you will come across as being very frank and forthright about the problems. Then you can immediately launch into discussing solutions.
You should give a very short summary of the forecasted completion date and cost. Then identify the following:
the tasks that are experiencing problems
what will happen to the completion date and cost if we don’t fix them
what you can do about those problems
what the results will be after your corrective action.
When you take this approach, you are answering three of those four questions the sponsors always have. As importantly, you are answering them in the first few minutes of your status report. You are hiding nothing. They know as much about the problem(s) when you’re done as you do. There are problems on all projects. But if the sponsors think you know what’s going on and that you’ll frankly tell them about it, you will be successful. Project Tracking Software – Video
Don’t be alarmed if some of the stakeholders or even the sponsor get up and leave after you answer all their questions in the first few minutes. These are busy people and that just means you did your job right.
Weekly Status Report – Show You Are in Control
For those people who stay beyond the opening minutes, you should demonstrate that you are in control of the project and all the project team members know what you expect of them. Your status report can:
list the major accomplishments or activities for the preceding reporting period
identify the objectives for the next reporting period
Many project managers miss the opportunity to help the sponsor and stakeholders report on project progress. Remember, they usually must prepare a report for their boss detailing how the project manager and team are performing during that reporting period. Status Report Template
The report may also include details related to the triple constraints (yes, there are six): Team Status Reports
Scope (objectives or activities)
Risk (may include issues or challenges).
Weekly Status Report – Summary
Writing good status reports requires a number of components. First, you need good status data from your team members. Second, you need reasonable knowledge of project management software so you can produce data about completion dates, forecasts and overall project performance. Then you have to actually put the data into a status report and present it. See Also Decision Making Data, Earned Value, Change Orders and Red Light Status
You learn all of those skills in our online project management basics courses. You work privately with an 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 basics course in your specialty.
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.
Requests to shorten the project schedule and finish earlier are a regular part of managing a project. The first requests to shorten the schedule come almost immediately after you release the first draft of the schedule, when the project is still in the planning phase. The sponsor and stakeholders all come to you with reasons why the project needs to finish earlier. You need the correct techniques to address these requests or you will wind up promising durations that are impossible to deliver. Project Schedule & Software Main Page
The second batch of requests to shorten the project schedule come shortly after you launch the project. That’s when executives and other stakeholders begin to realize how your project may affect other projects in the organization. That’s when the new requests for an earlier finish date arrive on your desk. Again, you need to know the proper techniques. The objective is not to deny all of these requests to shorten the project duration. If you take that approach, your relationships with the stakeholders will go downhill fast. Plus you will usually get overruled. Project Status Reports
You need to focus on preserving the feasibility of the project in the face of these requests to finish earlier. There’s nothing wrong with shortening the duration of the project if you secure additional resources to do it or you can get approval to reduce the scope of the project to allow shortening of the duration. Finally, you can shorten the duration if you get additional budget to pay overtime or hire outside contractors.
Successful project managers don’t just promise to shorten the duration and figure out how to do it later. They develop the data to show the sponsor and stakeholders alternative ways of shortening the duration. These are never free. There are always trade-offs in the project scope, cost, duration or risk for shortening the duration. Let’s look at how you develop the data for trade-offs.
Project Due Date - Finish Earlier
Project Schedule: Critical Path to Model Changes
You use the critical path method to identify the most efficient way to shorten the project duration. The first step is to use your project software to calculate the duration of every path (sequence of tasks) in the project. The path or sequence of tasks with the longest duration is the critical path and controls the project duration. All the other paths have slack or float. That is, they can finish later than currently scheduled and not delay the overall project completion date. This is significant because when you need to shorten the project duration, you do so by shortening the critical path. Reducing the duration of tasks in the project that are not on the critical path will allow those tasks to finish sooner but will not shorten the overall project duration. Critical Path
Once the project software identifies the tasks that are on the critical path, you can consider various options for shortening the duration of that path. Those options would include “crashing” the project by adding resources to critical path tasks so they finish sooner. As you are adding resources to the critical path tasks, you need to check to see if the critical path has changed. As you add resources to the tasks on a given path, the duration of that path decreases. Once another path has the longest duration, it becomes the critical path. Adding more resources to any tasks not on the critical path will not affect the duration of the project.
Let’s summarize everything we’ve covered.
When Do You Use the Critical Path?
You use the critical path technique when you need to shorten the duration of the project. The most common situation is when the initial draft of the schedule takes longer than the sponsor wants. You also use it to develop solutions for variances and to handle change requests.
Why Do You Use the Critical Path?
You use the critical path technique because it identifies where to add resources to reduce the project duration. Adding resources to the critical path tasks, (the longest path in the project) is much cheaper than adding resources to all of the tasks. The reason is that the other paths have slack; they can finish later than scheduled without delaying the project completion. It’s always useful to identify the critical path as you near the end of your project scheduling process. By knowing the critical path and how much slack the other tasks in the project have, you can identify opportunities for shortening the duration.
Project Schedule: Finish Earlier Example
Let’s examine a project with three paths. Each task in the path is identified with an alphabetic letter so the path ABDE starts with task A, then goes to B, then to D and ends with E. Here are the durations of each of the three paths and the amount of slack they each have.
Path ABDE: 10 days duration, 4 days of slack
Path ACFE: 14 days duration, 0 days of slack
Path ADGE: 13 days duration, 1 day of slack
You see that path ACFE has the longest duration, which is 14 days. You also see that path ACFE has no slack. When the path has no slack, the tasks on it cannot finish later than the baseline schedule without increasing the duration of the project. When they have slack, they can increase their duration until they use up all of their slack. At that point, that path becomes the critical path.
Chris Pimbock was a new project manager in his organization and he was preparing the schedule to present to the project sponsor. The sponsor was very clear during the initial planning session that the project had to be finished within 45 days. When Chris checked the first draft of the schedule, the duration of the project was 50 days. Chris knew he had to shorten the project duration. Chris calculated the duration of each of the four paths through the project and found that the critical path was indeed 50 days long. However, the other three paths were all less than 40 days. Chris then examined the five tasks that were on the critical path and found that one task, the engineering work, had 20 day duration. That told Chris that the easiest place to shorten the project duration by 5 days was the task with the 20 day duration. Chris looked at the resources assigned to that task on the critical path and found that one engineer was assigned to do 160 hours of work.
Chris contacted the engineering department and asked if a second engineer might be available to help on the task. In discussing options with the manager, Chris also specified that if they added a second engineer, both engineers could be finished within 10 days rather than the original 20 day schedule. The engineering department manager agreed to supply a second engineer to the project and Chris rescheduled the whole project. The duration was now 40 days and that allowed Chris to present a schedule that had 5 days of slack. That meant that the critical path tasks could slip by 5 days and the project would still finish on time.
Chris Pimbock was able to meet the project sponsor’s requirement without promising a duration that was faster than he could deliver. The key here was using data to show the sponsor exactly what had to happen to shorten the duration. This wasn’t a matter of leadership or inspiration of the project team, it was a matter of mathematics.
You can learn all of those skills in our online project management basics courses. You work privately 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.