Enterprise Project Management

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

When we talk about enterprise project management, we’re talking about the processes organizations use to initiate, plan, monitor and control, track and close projects. We also include processes to prioritize projects and allocate resources to them. Quite simply, enterprise project management is an organization’s way of doing projects. At a minimum, these processes should include:

1.) How the organization initiates projects

2.) What criteria each project needs to meet to be approved

3.) Assignment of a priority for using organizational resources.

That priority allows the important strategic projects to get first claim on the organization’s resources. Projects with a lower priority have to wait until the high priority projects have the resources they need. The organization should also have processes that project managers and sponsors follow as they plan, schedule and track their projects. That gives the organization’s enterprise project management consistent language, plans and reports. It allows everyone to work together more effectively. Evolution of Project Management in Organizations

A consistent approach produces significant benefits across all projects in terms of people understanding the role of the team member, sponsor, stakeholder and project manager. The role each of them plays is standard in terms of the decisions they make and the accountabilities they have on the project. Those consistent roles and processes allow for executives to become accustomed to the format of a project plan and a proposed schedule. That allows them to be more efficient and exacting in their review of projects.  This doesn’t mean the organization does every project exactly the same way. Most organizations have an enterprise project management protocol that differentiates between projects based on their size, scale and strategic significance. So in most enterprise project management protocols, small projects do not need as much paperwork and documentation as larger projects.

Enterprise Project Management Protocol

The enterprise project management may have a basic protocol for small projects. The project plan may be a short document with fewer than six elements such as: scope, requirements, estimates, resources, schedule and optimization. They include little, if any, risk management and the project has no additional quality processes beyond what is standard in the organization. Status reporting is very straightforward, consisting of identifying variances and explaining the proposed corrective action.

As projects get larger, the project plan grows to cover more topics. Risk management becomes increasingly important so they implement a risk management process with risk identification, qualitative analysis, quantitative analysis, risk response planning, risk tracking and monitoring. There is a formal risk response for each identified risks along with contingency plans if the risk response does not prevent the risk from affecting the project. Is Your Project in Trouble?

Organizations without enterprise-wide processes for completing projects have lower project success rates. They also have trouble getting the most important projects completed on time and within budget. Even worse, the lack of consistent project processes creates chaos in the trenches. Project managers battle each other for team members and no one manages people’s priorities and workloads.

Organizations with project failure rates above 50% have trouble surviving, particularly in tough economic times. But their efforts to improve performance often fail because they aim at the wrong problems.Why Do So Many Projects Fail?

Based on our experience with over 300 organizations, there are four keys to improving an organization’s project results.

1. The organization must control the initiation of new projects. Managers and executives can’t start a new project whenever they wish.

2. The organization must prioritize the projects so the major strategic initiatives get the resources they need.

3. The organization has to allocate resources to projects based on the priorities they have established. Without this, hundreds of “puppy projects” that produce very little benefit will use up to 40% of the organization’s project resources.

4. The organization has to use a consistent methodology for all projects that is scalable for the size and importance of the project. If not, small projects will be buried in too much paperwork. Project Failure Warning Signs

Enterprise Project Management Protocol Implementation

Implementing the enterprise project management protocol is a major effort. Project menterprise project managementanagers, sponsors, stakeholders and team members need to receive some level of training on how to play their roles. Organizations also face the problem of “cleaning out the pipeline” of in-process projects that have not been managed according to the new protocol. Often times the best approach is to simply let these projects wash themselves through the pipeline. But all projects started after a certain date must comply with the enterprise project management protocol. How to Implement a Project Management Protocol

A major implementation issue is the sophistication of the project management processes. The temptation is to go too far and insist on more project management processes than necessary. The protocol then takes too much time and people don’t do it. When organizations and their project managers go overboard with exceedingly complex processes, they get less than 10% compliance. It is better to adopt a simple system that requires relatively little additional time from sponsors, project managers and team members. The organization should implement a bare-bones enterprise project management protocol and use it for one year. After that time their executives, project managers and everyone affected by it is better able to discuss what could be added to or deleted from the protocol. They decide what to add by comparing the value of the additions to the amount of time and money they would require. Project Management Office Types

You can learn more about implementing an enterprise project management protocol in our online project management courses. You work privately and individually 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 a course in your specialty.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” color=”red”]Client[/button]


Get free articles and videos like this every week





How To Do Risk Analysis

Here is How To Do Risk Analysis for your project. After you have identified the risks your project faces, you need to do a risk analysis to determine which ones call for a risk response and which do not. The purpose of risk analysis is to rank the list of identified risks in order of significance or importance.  Your risk analysis focuses on qualitatively assessing the probability that the risk will occur and the magnitude of its impact if it does. You will use this qualitative risk analysis to decide which risks are important enough to warrant a risk response. Risk Management Main Page

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

How To Do Risk Analysis: Step 1 – Qualitative Analysis

Qualitative analysis assesses how much the risk could hurt the project but is doesn’t use any numbers. Qualitative analysis has the benefits of being cheap and fast but it lacks precision.  You can easily do qualitative analysis by meeting with three or four team members and stakeholders in the cafeteria for coffee. You list the risks you have identified that can possibly affect the project. For each risk, you ask them to assess whether it is very likely to occur, moderately likely to occur or unlikely to occur. When you have that information from each attendee, you ask them about how much damage the risk will cause if it does occur. Will it cause just a little damage, a medium amount of damage or a lot of damage?

As you can see, this is not a very precise method but it does give you the opinions of your stakeholders and team members. If you have any risks that are very likely to occur and will cause significant damage, you will plan a risk response for those risks. The less significant risks you have identified are things you will watch out for but you won’t plan a formal risk response for them. On smaller projects, you will probably limit the risk analysis to these qualitative techniques and planning risk response(s) for the significant risks.  Small Project Risk Management 

You may also decide that one or two risks are so significant you should preform a quantitative risk analysis.  The cost of the higher-level quantitative risk analysis probably requires the sponsor’s approval. Risk Responses

How To Do Risk Analysis: Step 2 – Quantitative Analysis

Quantitative risk analysis is both expensive and time-consuming. Usually, it is done only on very large projects which face very significant risks. Only in that situation could you justify the cost and weeks or months of effort which can go into a quantitative analysis. Regardless of which quantitative risk technique you utilize, the end result is the expected value of the risk. You calculate that by multiplying the probability of the risk occurring times the magnitude of the impact if it does occur.
Here’s an example. Let’s say your quantitative risk analysis determined there is a 0.001% chance that the company headquarters would be destroyed by a tornado during the coming four months. It also estimated that the magnitude of that risk (the damage that the tornado would cause) could be valued at $800,000. Now that risk probability is pretty small but the magnitude is pretty large. To combine them into a single number that lets you make a good decision, you  would multiply that probability times the magnitude and come up with an expected value of the risk of $800. What that expected value means is that if you did this project 10,000 times with the same tornado risk, the average damage would be $800. So you can’t justify spending more than that amount ($800) to avoid the tornado risk. The quantitative risk analysis says you can have only a very limited risk response program if you must keep the cost under $800, the expected value of the tornado risk.  Presenting Your Risk Plan


To learn more about how to manage project risks, consider one of 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.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=”00000000″]Client Projects[/button]


Managing Project Risks Not Fighting Fires

Managing project risks is a touchy subject with project sponsors. The majority of executives who sponsor projects are hesitant to authorize risk management efforts. This is because in the past many executives have gotten burned by risk management efforts that cost a great deal of time and money and produced little or no results. So it’s hard to get the sponsor’s approval to do risk management. Often executives will say, “Start work and we will put out fires when they occur.” But firefighting is not the way to succeed on projects. Project Risk Management Main Page

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

There is an unfortunate emphasis in many organizations on firefighting as opposed to careful planning. This includes planning for the risks the project faces. Many project sponsors like the idea of not committing to highly detailed project plans. They think, and rightly so, that this limits their ability to “be flexible” and make changes whenever they want. Project managers who buy into this thinking have happy sponsors in the beginning of the project because they can start work fast. In this situation, the team puts little effort into project planning and there certainly is no project risk management. Unfortunately, the same project managers are routinely surprised by risk events that easily could have been anticipated during the planning phase. Because there was no risk management, the team has to stop work and figure out what to do about the risk(s) that smacked them in the face.

Managing Project Risks The Wrong Way

Let’s think about what happens when a project manager and team rely on firefighting instead of having a well thought out risk response plan. Let’s talk about a specific example. A project manager is relying on an outside contractor to produce a “super tech” deliverable that is required by three major project deliverables. In other words the super tech is an input to three other deliverables. There had been discussion among the project team and the organization’s legal staff about the contract with this vendor. But the team had worked with him before and assumed the super tech deliverable would be exactly what they need.
The project has started fairly quickly because no detail plan is being formulated. Over the first month everything goes well but then the vendor calls and says, “Super tech is going to be delayed because four of my best people have just walked off the job to go to work for a competitor in California. I don’t know where the heck I’m going to find people to do your super tech work. But I’ll get to work on it right now and keep you posted.” The project manager tries to find out how much of a delay they’re facing and the vendor says there’s no way to tell at this point.” The project manager also reminds the vendor that there’s a contract requirement to deliver super tech by the end of June. The vendor says, “That’s a long way away. I’m sure we’ll get it worked out by then.”
The project team is stuck because they gave no thought to the possibility of the vendor being unable to produce the deliverable by the end of June. They had done no risk analysis or planning about this critical project deliverable. There was no contingency plan and no money to pay for hiring another contractor to do the work. They also hadn’t planned for the option of buying a pre-built or “canned” deliverable as a substitute for super tech. So the project team must stop work on other project activities while they and the project manager try to find other options for super tech. Even if they find a substitute, the project will be significantly late because of the delay.
This type of risk event occurs all the time.  People who try to respond to this type of risk with firefighting fail to recognize one thing. All the thinking that they’re going to do in this firefight should have been done as part of the risk management process.  Then they would have had a contingency plan approved by the sponsor which they could implement the moment the contractor called with bad news.

When the project is late and over budget because of a couple of these risk events the sponsor’s not happy. Project managers need to remind executives of these failed projects to “sell” them on the need for rimanaging project riskssk management on future projects. Presenting Your Risk Plan

Managing Project Risks The Right Way

A risk management process can pay big dividends, particularly when it is scaled to fit each project. In fact, the entire risk management effort for a small project can take place during lunch with the sponsor. The sponsor and project manager spend one hour to identify the risks, analyze them and plan ways to avoid or mitigate the significant ones. There are bare-bone risk management techniques that don’t require a lot of paper work. Small Project Risk Management 

To learn more how to manage project risks,  consider 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.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=”00000000″]Consulting[/button]


Project Charter

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

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

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

project charter

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.

Project Charter: Project Manager Authority & Resource Specifics

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.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]


Project Lessons Learned

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.

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com
Dick’s Books on Amazon

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

Project Lessons Learned: Stage 1 – Pre-Launch Peer Review

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 Project Lessons Learnedindependently 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.

Project Lessons Learned: Stage 2 – Portfolio Management & Change Control 

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 acProject Meeting Rescuetion 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.

[button link=”” style=”info” color=”red” window=”yes”]IT Projects[/button]

[button link=”” size=”medium” style=”download” color=”#1e14a8″ border=”#940940″ window=“yes”]Business[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Construction[/button]

[button link=”” style=”info” color=”#1e14a8″ window=”yes” bg_color=“00000000″]Healthcare[/button]

[button link=”” style=”info” color=”red” window=”yes” bg_color=“00000000″]Client[/button]

Critical Path

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

Dick Billows, PMP
Dick Billows, PMP
CEO 4pm.com

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 work breakdownyou 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:

  1. 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)
  2. 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

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.

More on Decision Making Data,

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.