Procurement Management Planning

In Procurement Management Planning, we plan how we will go about procuring every resource, human or material, that we’ll need to contract for in order to complete the project. We also specify the kinds contract we will use and may even draft them before we select the Vendor. If we’re asking contractors and suppliers to submit bids we identify the selection criteria we will use before the request for proposal or even sent out. This kind of detail planting protects the procurement process from the unethical and even illegal things that can happen during the procurement process. If the criteria for selecting the winning vendor is established early, it’s very difficult for people of the organization to try and change those criteria to the benefit of a friend or acquaintance.  Similarly we didn’t five the skill sets in the people we’ll be on the project team.  With all of these decisions made before we begin to execute the project plan we are much more efficient and have better making decisions on the fly as we purchase things.

This is a lecture video on Procurement Management planning by Dick Billows, PMP. The is also a Project Manager in Action Video written and produced by Dick that shows you have Project manager project sponsor and team working to develop their procurement management planning. You’ll see them negotiate with vendors and acquire people for the team from other departments in the organization.

Lecture Video

Project Manager in Action Video

Project Charter Development

Project Charter Development happens during initiation.  The project charter is presented at the end of the initiation and reviewed and hopefully approval by management. That approval authorizes the sponsoring project manager to begin detailed planning and to make use of corporate resources in that process.  That’s not a go-ahead started project would rather to start the planning.  The project charter includes at least the high-level scope, high-level risks and it appoints the project manager.  The charter also can include estimates of the amount of resources and time which the project will take as well as explanation of the assumptions that are behind the scope of the project and the constraints that it faces.  A good charter triggers a lot of discussion and occasionally conflict. But it’s much better to find out during initiation that some departments won’t lend you resources than after your 30% finished.  Charter is a very useful device for avoiding surprises by surfacing potential conflicts at the beginning of the effort.

This is a lecture video on Develop Project Charter by Dick Billows, PMP, from the Initiation Process Group and the first process in the Integration Knowledge Area.

Lecture Video

Project Manager in Action Video

Project Plan for Small Projects: Fast Food Approach


Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

Creating the Project Plan for a small project is difficult for many reasons.  One of them is that the boss wants you to start as soon as possible without “wasting” a lot of time with meetings and paperwork.  Also the boss usually doesn’t give small projects much thought before dumping them in your lap. You clearly see that this is a recipe for failure.

Good project managers know that for every minute you spend on your project plan you save 10 minutes during the execution of the actual project. The reason for that 10 to 1 payback is that a plan allows the team to focus on executing rather than deciding what they’re going to do next.  A project plan also communicates to everyone what you’re going to do and how you’re not going to do it.  So how do you deal with the boss and still get even a basic plan?

Project Plan: Drive-thru Window at “Projects Are Us” Fast Food

You can do your project plan like the order-taker at a fast food drive-thru window. The fast food approach to planning is focused on getting started quickly by finding out what you. Here’s an example of how to apply that approach to a new Supply Room Project the boss emailed you about. You’d go to his office and the conversation would go like this:

Project Manager: “Exactly what do you want me to deliver on the last day of the project?”

Boss: “I want you to clean up the file room!”

Project Manager: “That’s what you want me to do but what is the end result you want me to deliver?  What should I be able to show you at the end of the project?”

Boss: “I am too busy for games.  I want you to show me a clean file room!”

Project Manager: “What is your standard for a clean file room?”

Boss, irked: “Nothing on the floor and everything stacked neatly in part number order”

Project Manager: “I can deliver that.” But then you remember how the fast food folks at the drive-thru window always ask if they can supersize it. So you add, “Do you also want to make it easier to find supplies? Not everyone knows the numbers of the parts.”

Boss, smiling for the first time: “Good thinking. I get a lot of complaints about things being hard to find.  Let’s kill two birds with one stone.”

Project Manager: “Great. Give them to me and I will suggest some additional deliverables before I leave today!”

What did the project manager accomplish here?  First, he/she improved the chance of project success.  They would have been near zero if the project manager had just started work with a scope of “clean up the file room.” Second, the project manager enhanced their credibility by asking some good questions that earned the boss’s praise. The approach used here appeals to a lot of bosses who sponsor projects. Particularly the ones who often complain about the planning meetings and paperwork that are necessary to start a project. In the fast food approach, you’ll forget all that PMBOK® stuff and reach agreement with the boss on the project’s scope. The project manager’s “supersize” question got a great reaction from the boss and they could continue talking about what business value the project has to deliver. The the project manager can get to work.

You can learn these skills for small projects in our project management basics courses.

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.

  1. 101 Project Management Basics
  2. 103 Advanced Project Management Tools
  3. 201 Managing Programs, Portfolios & Multiple Projects
  4. 203 Presentation and Negotiation Skills
  5. 304 Strategy & Tactics in Project management


How To Deliver a Status Report

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

The way you deliver your status report determines your credibility with the sponsor and stakeholders. It impacts their level of comfort with the project itself and your ability to manage it. You need to clearly and succinctly answer the questions the sponsor and stakeholders have about the project.

Status Report: Common Questions

You should answer their questions in the first five minutes of your project status presentation or in the first paragraph of your written status report. The four questions are:

  • Will the project produce the deliverables promised in the scope statement?
  • Will it finish on time?
  • Will it cost more or less, than what was budgeted?
  • Do the team members and vendors working on the project know what you expect of them? How to Write a Weekly Status Report

Status Report: Answer Questions

You should immediately answer the four questions above and discuss the problems as well as what you can do about them. How do you answer those four questions? With language that a 10-year-old child could understand.  The answers should not assume any knowledge about the project or what people said at the last status meeting. Why does it have to be that simple and straightforward? Because project managers are often their own worst enemy when they deliver status reports. They incorrectly assume everyone in the audience is as familiar with the project as they are. Status Report Template

Status Report: State Problems and Solutions

If you delay in answering these questions at the beginning of the report, people will think you are hiding something. If there are problems and variances to the plan, you should disclose them at the beginning of your status report. You need to tell people what you will do about the problems and variances and what help you need to take corrective action. You must also quantify the trade-offs between the project scope, budget and duration to solve the problems. If you can’t fix the problems, you must tell them. The sponsor and stakeholders must have confidence that you will reveal the problems as soon as you know about them. What they hate the most are problems that surprise them late in the project. Most executives will think you hid the problems for weeks or months and revealed them only when you could no longer hide them.

Status Report: Be Brief

Project managers tend to provide too much data and they assume everyone understands it. They also tend to “deep dive” into the technology of the project itself, using acronyms and discussing technical issues until the audience is bored to death. Some project managers assume this detail is the way to build their credibility and the stakeholders’ confidence in them. The opposite is true. The stakeholders think the PM is a technical geek who has a very weak grasp on what’s happening in the real world.

When a project status report confuses people, they assume the worst. They assume the project is out of control, that no one is monitoring the work and that the team members are equally confused and lost. They also assume that they are hearing only the tip of the iceberg and that many other problems are being hidden. As a result, they have little confidence in the project manager’s analysis of problems and recommendations for corrective action.  Earned Value

Status Report: Use Visuals

You can avoid this situation by using simple visual communications with the sponsor and stakeholders. Don’t assume they are as interested in the technical details of project management and the project work as they are. None of these assumptions are ever true but project managers often make them. Effectively communicating with stakeholders and sponsors requires you to use easily understood visuals that communicate the project status. The worst thing to give your audience is the classic project variance report which has 12 or 15 columns and lists every task in the project. This chart compares the planned start date with the actual start date, the planned finish date with the forecasted finish date and so on. No one can get an accurate picture of what’s going on in the project from that kind of data. Project Variances

You need to have visual charts and graphs that people can look at and understand in a moment. The Tracking Gantt chart available in many commercial software packages is ideal forStatus report this purpose. It has a bar chart for every task in the project. It shows when the task should start and when it should finish, usually in gray. Each task also has a second bar, usually in blue, which shows when it will start and when it will finish. If these two bars are stacked on top of one another, the task is on schedule. The red bar is the critical path which is the longest chain of tasks. It depicts the project’s actual start date and the projected finish date. This visual display lets everyone quickly see where the problems and opportunities are. It also makes it easy to explain your options for corrective action. Project Tracking Software – Video

Status Report: Tailor It to Your Audience

In addition to visual aids that tell the story with pictures, you also need to tailor the status report presentation to your audience. If the attendees are all expert project managers, the status report can be concise and fact-filled without explanations. If the audience is composed of stakeholders who have had little exposure to projects or project management, you must explain the basics. You can’t assume everybody knows as much about the project itself or project management best practices as you do.

Another issue is designing the presentation to fit the personalities of the attendees. If the audience is composed of technical staff who are very detail oriented and value a chronological presentation with plenty of data, you will have one type of presentation. If the audience is composed of “big picture” thinkers, you need to present the end results first and then offer as much supporting detail as the audience wants. If you get into too much detail for these people, they’ll quickly leave the room.  Team Status Reports Video

You can learn all these status reporting skills in our online Project Management Basics courses. You work privately, one-to-one, with a expert project manager.

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.

  1. 101 Project Management Basics
  2. 103 Advanced Project Management Tools
  3. 201 Managing Programs, Portfolios & Multiple Projects
  4. 203 Presentation and Negotiation Skills
  5. 304 Strategy & Tactics in Project management


Requirements Gathering Blunders and Best Practices

Many project failures are caused by poor requirements gathering techniques. These blunders cause three separate problems for the project and each one can increase the project’s cost and duration and lower the users’ or clients’ satisfaction. Every week stakeholders submit requests for new or modified requirements because

  • The project deliverables are not meeting their needs
  • The project manager disagrees with stakeholders about whether certain features and functionality are included in the project’s scope of work.
Dick Billows, PMP
Dick Billows, PMP

Sometimes these problems are minor annoyances. Other times they’re expensive and hard to correct. Here are the classic errors you should not make when gathering stakeholders’ requirements. Requirements Main Page

Requirements Gathering Blunder #1: Secret Requirements Meetings

Some project managers think that the assembly of project requirements and specifications should be done in secret so there is no interference from users. They believe the requirements gathering process is more efficient when it’s done by technical experts, not the users or the clients. Their reasoning is that the users/clients don’t know anything about the technology at the heart of the project. So why waste time explaining it to them? The PM and technical experts will develop the requirements quickly and efficiently and then explain the results of their work to the users/client. This thinking is often based on war stories of previous battles over requirements and project deliverables with the same users/clients. The attendees at the secret requirements meetings also want to avoid listening and learning about the users/clients’ business requirements. They hope to apply their technical expertise very narrowly and give the users/clients an elegant technical solution.

These secret requirements meetings sometimes get the active support of executives who want to start work quickly and not waste a lot of time on meetings and paperwork. They also don’t want to give the users/clients control of the project by letting them specify the requirements and deliverables.

The consequence of this approach is a great deal of conflict and, most importantly, a lot of wasted time and money. The project team will undoubtedly produce deliverables that don’t meet the users/clients’ needs or lead to improvement in performance. Unfortunately, this is a downward spiral that organizations often repeat.

Requirements Gathering Blunder #2: Requirements are Just Technical Specifications 

In the second blunder, the project team experts produce a complex list of requirements and specifications that the user/client is asked to sign off on and approve. For some odd reason, the project manager believes this process will protect them from criticism if the user is unhappy with the project deliverables. In the real world, the conversations go something like this:

Dissatisfied User: “These deliverables are not giving us what we told you we needed! They do not meet the needs of our business. We told you what we wanted and you have not given it to us. This crap is useless!”

Project Manager: “But you signed off on the technical specifications and requirements that we gave you. I have a document right here and that’s what we delivered.”

Dissatisfied user: “We had absolutely no idea what that technical gobbledygook meant. We told you what we needed to improve customer service and you have not given us the tools we need.”

Project manager: “I have the signed document right here.”

Dissatisfied user: “Good.  You can show it to my boss when I tell him about all the time and money you’ve wasted turning out garbage.”

The advantage the PM perceives from compiling the list of requirements and technical specifications is that it saves the project manager and team from listening to and understanding the stakeholders business and the business problems they want to solve. Obviously, that is not an advantage. Project managers need to aim the project deliverables at the customer’s business needs, not at a sheet of technical specifications. Unfortunately, project managers often combine blunder #2 with blunder #1.  Then the projects resemble the trench warfare of World War I.

Requirements Gathering Blunder #3: Let’s Make Up a Shopping List

This blunder is friendlier and happier, at least initially, than the preceding choices. But the project result is similar. These blundering project managers approach requirements gathering as if they were making up a shopping list. They go around and ask the stakeholders and other people what they want, then add it to the list. Several bad things happen with this approach. First, they tend to miss requirements and find out they’re missing after they have started work.  That causes delays. Second, people add things that may be good ideas but aren’t needed to produce the scope.  That wastes time and money. Third, people get in the habit of adding things to the project without justification. And that never stops, even after the PM has begun to execute the project plan.

So the PM gets many change requests people expect him to add.  They’re disappointed if they are not. The PM must do a good job limiting what is included in the project plan based on a clearly defined scope. Overruns are the result when they don’t.  If people think they can add things to the project plan whenever they wish, the project will suffer from scope creep. This means its duration and budget will grow every week. That’s when the stakeholders and other people become unhappy.

Requirements Gathering Best Practice: Prototyping

Another way to gather requirements is by prototyping, which may or may not be a blunder.  With this technique, the project team does some requirements gathering, then goes to work, and produces the initial project deliverables. Then the user/client evaluates the prototype and tells the project team about the prototype’s flaws. The team goes back to work to fix those issues. Then they produce another prototype for the user/client to evaluate, and the cycle goes on. Project managers use prototyping with certain types of projects. It’s most often used in software development where the cost of making changes to the prototype is not too expensive. They also use prototyping in manufacturing, depending on the cost of each iteration. Prototyping can take a great deal of both the user/client’s and the project team’s time, depending on the number of iterations. The arguments in support of prototyping are that it encourages continuous contact between the user/client and the project team. Proponents say this produces a higher quality result and a shorter development cycle. On the other hand, prototyping can create a situation where the project team works on the effort forever. That’s because the user’s requirements change every time they look at a prototype. More on Prototyping

Requirements Gathering Best Practices

The right way to handle requirements gathering is to have a crystal-clear scope of the project deliverable and the major deliverables that lead to it. Each of these deliverables is defined with an acceptance criteria so you are not dealing with a vague “to do” list. The entire requirements gathering process should be constrained by these criteria which are objectively measurable. Then the user/client justifies their requirements by showing the PM why they are necessary to produce the specified deliverables. If a stakeholder can’t link a requirement to a deliverable, it’s not included it in the project plan.

Let’s look at an example. This company has lots of complaints about their service. Many are tied to the fact that 20% of the customers have to call back repeatedly to get their problem resolved. So you will start by working with the project sponsor to define the acceptance criteria for improvements in the company’s telephone and web-based customer service process. You come up with acceptance criteria for the scope which is “Fewer than 3% of customers have to contact us a second time about the same problem.”

Next you work with the sponsor & senior stakeholders to detail the high level deliverables that are required to move the company from where it is now to the scope definition. That is, to go from 20% of the customers to fewer than 3% of the customers have to call back a second time about the same problem. Those high-level deliverables are:

  • Customer service system provides 18 months of customer transaction and complaint history in less than five seconds
  • Customer service cubicles have an average peak noise level of 72 dB
  • 95% of the customer service reps can answer the top 30 inquiries in less than 45 seconds
  • Customer service hourly staffing creates maximum workloads of 85% of capacity.

The above acceptance criteria give you the tools to constrain the requirements gathering. You link every requirement with one of those major deliverables or the lower level deliverables that support it. You keep track of who requests each deliverable and the performance commitment they made.

You work on requirements gathering at the beginning of your project planning phase.  The requirements are necessary for many other project management tasks. You can gather your project requirements very simply or have a much more elaborate requirements process where you track the originator of each requirement and tie it to their performance commitments.

A very common mistake when gathering requirements is to treat the process as simply making a list of everything everybody wants. This tends to keep people happy because they can add anything they wish to the project. However, you will suffer the consequences of stakeholders adding additional requirements every week. This is the classic form of scope creep where you continue to add new features, bells and whistles to the project. This process also substantially increases the project failure rate. That’s because you usually will not get additional time or resources to fulfill those requirements. So the project will be late and over budget.

Requirements Gathering: Step-by-Step

  1. Immediately after the sponsor approves the scope, you use the information about the identified stakeholders to conduct initial requirements gathering meetings.
  2. You meet with the stakeholders to discuss their requirements for producing the major deliverables of the project. You are not compiling a wish list. Instead, the discussion focuses on each of the major deliverables and what is required to produce them.
  3. You put every suggested requirement through a test of whether it is necessary to produce one of the project’s deliverables. If the requirement is a good idea, but not necessary to achieve the project’s scope, it is not included.
  4. You meet with as many stakeholders as possible with the intent of unearthing all potential requirements. Many of these requirements will not be included in the project plan. However, it is good to identify them during the beginning of the planning process rather than finding out about them late in the project.
  5. For every requirement that is included in the project plan, you complete the requirements register, which documents the individual who is accountable for the requirement. This documentation maintains traceability back to the originator of every requirement in the plan.
  6. When you and sponsor have considered all of the requirements and either accepted or rejected them, you and team can proceed to the development of the work breakdown structure.

More information on the lean project methodology

You can learn how to gather and manage project requirements in our customized, online courses. You work individually with your instructor and have as many phone calls and video conferences as you need. The Project Management Basics course, #101, teaches you a step-by-step process and how to use MS Project® software to make your job easier. We also offer this Basics course for IT, construction, healthcare and consulting project managers.

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.

  1. 101 Project Management Basics
  2. 103 Advanced Project Management Tools
  3. 201 Managing Programs, Portfolios & Multiple Projects
  4. 203 Presentation and Negotiation Skills
  5. 304 Strategy & Tactics in Project management


Get Our Free Project Manager Newsletter
A Free Project Article & Video Each week

By submitting this form, you are consenting to receive marketing emails from:, 125 cold springs dr, georgetown, TX, 78633, You can revoke your consent to receive emails at any time by using the SafeUnsubscribe® link, found at the bottom of every email. Emails are serviced by Constant Contact

Project Team Assignments – Deliverables Not "To Do’s"

The best project team assignments tell each team member exactly what end result you expect and how you will measure their performance against it. Too many project managers do a poor job of making project team assignments because they don’t define clear performance expectations. As a result, the project management team members don’t work as effectively as they could. And they often don’t deliver the results you want. The fault may be yours, not theirs. Project Teams Main Page

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

In my years of working with project managers to improve their results, my most common comment is, “The assignments you give your team members are not clear.”

The response I always get is, “I’m telling them exactly what to do.”

“And that’s the problem,” I reply. “You’re telling them what to do, often in great detail. But you’re not telling them what you want them to produce. Specifically, you’re not telling them what your acceptance criteria are for their assignment.”

Project Team Assignments: Bad Example

Here is an example of what I mean. Let’s say there is a project to straighten up the supply room. The project manager says to a team member, “Clean up the supply room. It’s a stinking mess with things that should be thrown away and things that should be stored somewhere else. I need that done by 5 o’clock today.” Now that’s an awful assignment. The project manager mentioned some things “to do” and the time when the work was to be done. But they did not state the deliverable’s acceptance criteria, the assignment’s measure of success.

Project Team Assignments: Good Example

Here is an example of a much better assignment. “The supply room is a mess. I would like to see all the supplies on the shelves, organized by part number. Nothing should be on the floor.  And anything that is not on the office supply list should be sent to Purchasing for them to do with it as they see fit.” That assignment makes the deliverable’s acceptance criteria, the measure of success, very clear. The person doing the work knows exactly what result they have to produce. As importantly, they’ll know if they have succeeded or failed before the project manager inspects the supply room.

The team member assignments from successful project managers are deliverables with acceptance criteria. They aren’t a list of “to do’s.” This is particularly true of PMs who are managing large project teams or multiple projects. Vague project team assignments cause more damage as the size of the project increases.

Project Team Assignments: Harm Caused by “To Do’s”

When project team members have to guess about what a “good job” is, their work is going to be less focused than it should be. When your team members are uncertain about your expectations, they naturally try to protect themselves by padding their estimates. They expect your unclear expectations to change and they need protection from blame. Successful project managers avoid this problem by making project team assignments with clear performance expectations.

project team assignmentsYou need to set the performance expectation for every assignment you give to team members. As work progresses and the team produces their deliverables, you compare what was actually produced to the original assignment. Your team members’ behavior and performance are always affected by what you “count” in making assignments and evaluating performance. If the only thing you count is how long the team member takes to complete their task, they will focus only on finishing on time. They’ll pay less attention to the quality and business value of their deliverable.

You should define each task by its business value, the quality metric and the hours of work for the task. That is what matters on every assignment and it’s what you want the team members to focus on. You need to count what matters.

You can enhance your PM skills and master the art of making good project team assignments 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 the courses 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.

  1. 101 Project Management Basics
  2. 103 Advanced Project Management Tools
  3. 201 Managing Programs, Portfolios & Multiple Projects
  4. 203 Presentation and Negotiation Skills
  5. 304 Strategy & Tactics in Project management


Scope Creep

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

First we’ll talk about what Scope Creep is and then we’ll talk about how to avoid it. Scope creep is the addition of new features and functions after the original project plan has been approved.  These additions to the project scope are approved without any compensating adjustment to the project budget or schedule. It is the number one cause of project failure. Some organizations are plagued by scope creep on every project because their project managers don’t do a good job of defining the scope or engaging the project sponsor in scope control. These actions should be done early in the project. If not, the projects (and project managers) have a limited opportunity for success. Trying to fight every change to a project doesn’t work either. Even if the stakeholder or customer doesn’t “ram the change down your throat,” they are still unhappy with the project and the project manager. Project Scope Creep Main Page

How To Avoid Scope Creep: Planning Is The First Line of Defense

The battle against scope creep starts during project planning. You and the project sponsor need to lay a foundation where you can fend off additions to the project that are not necessary to achieve its scope. Every good idea that is proposed by a stakeholder or one of your team members must first be tested to see if it’s necessary to achieve the project scope. That means that the scope of the project needs to be defined in unambiguous measurable terms. We need a scope statement like, “less than 5% of the customers spend more than 20 seconds on hold.” Then when someone proposes a good idea, you politely say, “Please tell me why we need to include that task to achieve our goal of ‘less than 5% of the customer spend more than 20 seconds on hold.’ It seems to me the tasks we have planned will get us to that end result.”
With a measurable scope and deliverables, you have a better ability to fend off scope creep additions to the project without making the stakeholders angry. So you must spend a great deal of time defining the scope in measurable terms rather than falling prey to the “start work fast” mandate. That often prevents the development of a clear scope definition. And without that clear definition, you may start fast but you’ll finish late because of all the scope creep that is loaded onto the project. The deliverables in the project must also be defined in measurable terms. They form the first line of defense against scope creep. You need to convince your sponsor that it’s worth spending time to define the deliverables because they help you avoid scope creep.

How To Avoid Scope Creep: Trade-offs Are The Second Line of Defense

Rather than trying to fight every change, you will be more successful handling scope creep when you are able to quantify trade-offs every time a stakeholder asks for a change in the project. You shouldn’t tell them you can’t do something they want.  Instead you should say, “Of course we can make that change. Let’s talk about what it will cost and how much it will change the duration of the project. We can also discuss how much it will change the resources we need on the project team.” Then you calculate the numbers that clearly communicate the impact of the requested change on the project.

Remember there is no such thing as a free lunch. Every change has an impact on the project cost, schedule, quality, risks or resource requirements. After reviewing your estimated impact numbers, the stakeholder making the request may decide not to pursue it. Or you may follow the organization’s change management protocol and send the data to the project sponsor to make a decision. Either way, you are better able to manage the stakeholders than if you try to fight all changes. You also need to be disciplined in maintaining the stakeholders’ expectation that any change to the project will increase the schedule and duration. Here’s an example. A stakeholder says to you, “I’ve got a tiny little change I want to make to the curriculum for the service representatives’ training class. This is so small I hate to bother you with it. I want to add about four hours to the class and give them information on the best way to deal with people who are having marital problems. With the skyrocketing divorce rate, I’m sure a lot of our customers fall into that category. This change is really nothing; maybe a few minutes of preparation for the trainer and a couple of hours of additional class time. Can you just add that for me?”

The short answer is no, you can’t just add that. It’s not that this scope change is so terribly damaging. Rather, it’s the expectation it creates in the stakeholder’s mind. If you “just squeeze in this one,” next week you’ll get a change request that is just a little bit larger and hurts the schedule and budget a little bit more. You must begin to control  the stakeholders’ expectations for making changes during the presentation of the project plan. And you must continue that control every week until the project is complete. There is never a free change to the project you can “just squeeze in.”

You can learn these skills in our basic and advanced project management courses. Take a look at the courses 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.

  1. 101 Project Management Basics
  2. 103 Advanced Project Management Tools
  3. 201 Managing Programs, Portfolios & Multiple Projects
  4. 203 Presentation and Negotiation Skills
  5. 304 Strategy & Tactics in Project management

Project Risk Management

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

You should spend some time doing Project Risk Management even if your project is small.  Let’s say your boss is the sponsor and your project has just two team members. That means you will be completing tasks as well as performing project manager duties.  Most projects are small like this but you still should perform some Project Risk Management on them. Risk Management Main Page

Now you shouldn’t tell anyone that you are starting the Project Risk Management process. That will make them think you’re going to waste time doing fancy mathematics, having all kinds of useless meetings and generating worthless paperwork. But you’re not going to do that fancy, expensive stuff. You’re just going to do simple risk management so you can solve some problems early in the project. In fact, risk management lets you solve some problems before they start.

This early problem solving begins during the planning phase. Let’s say your project is to reorganize the department’s supply room. First you identify the problems (risks) that may affect the project. Then you think about how likely each of those problems is to occur and what the damage will be if they do. The ones that are likely to seriously affect the project are the ones you should do something about. Next, you analyze the identified problems and think about how you might avoid each one. In other words, you think about how you might dodge them completely.

Project Risk Management – Early Problem Solving 

For example, when you think about the problems your supply room project will face, you come up with two of them that are likely to occur and will have a big impact if they do. The first problem is that people may not keep the supply room well-organized after you finish the cleanup. The second problem is that it will take people longer to find what they want than it does now because the supplies will probably be in different places. Let’s tackle each of these problems (risks) separately.

The first risk comes down to making sure that the new organization of supplies is maintained. You and your two project team members discuss possible incentives for the people who stock the supply room shelves. You believe you can avoid this problem if you involve the staff in the design of the supply room and hold them accountable for maintaining it. The three of you agree on that task and you add it to the project plan.

You go on to the second risk of people not being able to find the supplies they want because the supplies have been moved to different locations. You certainly don’t want complaints about your reorganization. So you discuss what would make it easy for people to find things. You finally agree to place the high-volume supplies, the ones that are needed most often, near the entrance to the supply room. After you’ve included the supplies that cause two-thirds of the trips to the supply room, you agree to organize the remaining items by category (paper products, writing instruments, clips and staples, etc.).

project risk managementThe amount of risk management you do depends on the size of your project. On a very small project, the risk management effort might be completed over a lunch with the project manager, the sponsor and some team members. Here’s what that discussion will do:

  1. Identify the risks the project faces
  2. Assess the likelihood of the risk occurring and the size (magnitude) of its impact on cost and duration if it occurs
  3. Develop risk responses to avoid or reduce the impact of the risk.

Project Risk Management Steps

Here are the steps you can follow for your project risk management process. You may do some or all of them, depending on the size and complexity of your project.

  1. You and the team members begin by reviewing the list of identified risks, both positive and negative. That list is called the risk register. Then each person assigns a rating of high, medium or low to the likelihood (probability) of each risk occurring and the size (magnitude) of the impact if it does.
  2. You gather and correlate the individual assessments of probability and magnitude and calculates the average for each risk in the risk register.
  3. You and the team members review the average ratings and select those risks that are important enough to justify a response. This is called qualitative risk analysis.
  4. You present the qualitative risk analysis to the project sponsor. The goal is to obtain their approval to plan responses to the risks.
  5. You and the team members develop risk responses for the positive and negative risks. For positive risks, you design the response to increase the probability and/or the magnitude of the beneficial impact. For negative risks, the response should decrease the probability or magnitude of the adverse impact.              Risk Responses
  6. You present the recommended risk responses along with an analysis of their impact on the project’s cost, schedule and budget. For the risk responses that the sponsor approves, the project manager makes changes to the project plan, schedule and budget to reflect those risk responses.

Summary of Project Risk Management

Even on small projects, risk management helps you identify and solve problems before you begin work. This increases your project success rate, which helps you advance your career.

You can learn more about managing risks 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 the 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.

  1. 101 Project Management Basics
  2. 103 Advanced Project Management Tools
  3. 201 Managing Programs, Portfolios & Multiple Projects
  4. 203 Presentation and Negotiation Skills
  5. 304 Strategy & Tactics in Project management

Project Team Ground Rules

Project team ground rules are a necessity. Almost all project teams have frequent meetings and even more frequent communication in various forms. If the project manager doesn’t set ground rules for these meetings and communications, a significant amount of time is lost. Together, the project manager and team identify and formulate the ground rules that members of the team should follow when they interact. These rules cover video conferences, in person-meetings and telephone conferences. The ground rules can cover a wide range of team member and project manager behavior.ground rules

Project Team Ground Rules: Examples

The ground rules may include the “completed staff work” concept. That approach to meetings aims at substantially reducing the amount of time the team members waste when people at the meeting are not ready to discuss the topics. The completed staff work concept is based on an agenda. Anybody can add an item to the agenda. The only requirement is that they distribute materials to all the team members before the meeting. That allows everyone to come ready to discuss the issue. Another rule is that you cannot raise an issue at the meeting that was not on the agenda with preparatory materials distributed. These rules help avoid bad decisions being made when people have not had time to thoroughly consider the issues.

Other ground rules may deal with interpersonal conflict. As an example, a ground rule may prohibit discussing work issues on previous projects. Other rules may bar personal criticisms, (“you’re very stubborn”) versus criticizing behavior (“you would not listen to my side of the problem”).

It is very easy to get carried away with too many ground rules. You don’t want people to have to consult a lengthy document to decide how to handle an interpersonal situation. The ground rules should fit on one side of one piece of paper. Remember, the goal is to avoid wasting time in meetings or making bad decisions because people are  unprepared or rushed to make a decision.

Project Team Ground Rules: Project Meeting Scenario

A status report meeting I participated in some months ago lasted 2 hours. Approximately 20 people attended, including the project team, test leaders, team leaders, PMO staff, etc. The meeting had many elements that are considered best practices. They included the following:

  • all attendees sent the PM their issues before the meeting
  • the agenda was distributed before the meeting
  • no other issues were brought up in the meeting

Long story short, it went something like this. Each person went through the status report covering their work stream, what they did, what they were going to do, issues, risks, decisions to be made, etc. I noticed that after the first 30 minutes, some of the attendees lost interest. After one hour, most were either checking their phone or chatting about something with the person next to them. You can imagine how the situation was after 2 hours.

I share this example to make the point that following what are considered best practices does not mean you are efficient or effective. In the above example, if you calculate 20 people * 2 Hrs = 40 Hrs (40/8 =5PD) of effort for a single status meeting.  One meeting a week adds up to 260PD a year, which is a significant effort.

Project Team Ground Rules: The 30 Minute Meeting

Below is an approach that has worked for me. I call it the 30 minute meeting.

  1. Schedule important meetings early in the day. A meeting is a pit-stop (as in Formula One racing) where all the team members must get the overall picture. It must be kept short and to the point.
  2. The core of a status meeting is the status report. Prepare it beforehand. I like to prepare a presentation vs. a written document.
  3. A picture (or better a chart) shows no more than 1,000 words. The PM must give the bigger picture, showing all relevant charts in perspective. That includes the actual, planned, and forecast.
  4. All topics that are on track don’t need to be discussed one by one. They are only referenced in the status report (preferably in a chart). Include all the details in the appendix for the people who want to read it on their own time.
  5. Deal with topics that need bilateral attention outside the meeting. Time is precious so nobody is allowed to waste it. The PM must ensure the status meeting is not a place for everyone to dump their issues and problems.
  6. Keep it short and keep it clean. Be brave to exclude from the meeting all less relevant content. A short and to the point meeting is too important to be sacrificed for side topics.

Finally, a PM needs to keep the right balance of management overhead and actual work product in their meeting ground rules. My rule of thumb for overhead is not to exceed 10% of the total efforts. This approach to status report meetings works for me. It leaves the team energized, their attention sharp through the entire meeting and minimizes the management overhead.

Get free articles and videos like this every week

Project Duration

Dick Billows, PMP
Dick Billows, PMP
Dick’s Books on Amazon

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.

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

[button link=””style=”info” color=”#1e14a8″ window=”yes” bg_color=”00000000″]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 Projects[/button]