Project Tracking: Where PMs Build Credibility

Dick Billows, PMP
Dick Billows, PMP

Project tracking is the key to consistent project success and to earning the stakeholder’s confidence that you are in control of the project.  It’s the way successful project managers update executives and stakeholders on the status of the project.  Last its where PMs avoid  bad surprises at the end of the project.

Project Tracking Based on Estimates to Complete

A status report is where the PM reports on how the actual results compare to the original plan. These reports are from hard data.  Every project team member should reports the hours of worked on each task and estimate how many hours of work remain to complete that task.  Good project tracking is based on numbers, not opinions or guesses. So we estimate the hours of work on each task during planning and then track the hours actually used as we execute. When we update those estimates with actual data we have the information to avoid bad surprises at the end.

Project tracking informs the sponsor about any variances to plan that exist. It also includes well formulated corrective action plans to fix the variances to the project’s plan and schedule.  Presenting those options reassures the executives and stakeholders that you are in control of the project.  Project Tracking Reports Main Page

Causes of Bad Project Tracking

You can easily erode your credibility with poor project management tracking. Most time project tracking problems come from lack of good data. a weak project plan an schedule is the primary problem.  If the project manager does not carefully define each deliverable and then estimate, with the team member, the hours of work it will require, it will be impossible to accurately track progress.  That’s what leads to those, “Uhh Boss, we’re going to finish 4 moths later than planned.”

This is especially true if one project after another has a bad surprise when it is too late to recover. Project sponsors soon think your projects are out of control and question everything you tell them. The solution is to present hard-edged data, not guesses, in your status reports. This allows you to spot problems early when they are small and easier to fix.

Project Management Tracking: Metrics

Project managers and executives too often use tracking data that hides big problems. They eventually surface when it’s too late to fix the delays and overruns they have caused. Bad surprises late in a project make executives crazy and ruin your credibility.  Why does this happen? It’s a combination of the following:

  • Inability to precisely measure progress
  • Mushy project checkpoints
  • Team members not reporting bad news when they first see it
  • Too much status report optimism.

The first step to correct the situation is to use metrics to quantify the scope and major deliverables for every task in the work breakdown structure. Those metrics provide unambiguous check points against which to measure progress and show any slippage. The next thing you need to do is work with your team to develop estimates of the required hours of work. Do not use only finish dates in your schedule. Tracking actual work versus the estimated hours of work gives you another measure of how far along each task is. In combination, those two metrics will let you spot problems early. Solving them early is a real credibility builder with executives, stakeholders and team members.

Project Management Tracking: Mushy Check Points

Project managers and executives should build a firm foundation for project management tracking in the planning process. Unfortunately, the planning often doesn’t force stakeholders to decide exactly what they want.  So the project’s foundation is built on vague wishes that can’t be measured. Those wishes don’t give you tracking metrics to measure progress. They only give you due dates.  And it’s impossible to decide what is in the project and what it not.
Those mushy definitions of scope and deliverables let people avoid hard decisions and conflict. Plans and work breakdown structures that are merely “To Do lists” let everyone think they are getting everything they want from the project.

The lack of clearly defined deliverables makes it difficult to decompose them into their parts.  It’s impossible to decide what is in the project and what is not.  It also makes project management tracking a highly subjective and judgmental process.  You’re left to track the progress of vague tasks that everyone defines in their own way. People often have to work with mission statement mush like “Deliver world-class customer service” and “Improve system response time.” What are the components of “Deliver world-class customer service?” No one knows. This vague high-level deliverable saves the project manager from committing to exactly what they expect from each team member.  The due date is the only measure of the task’s performance. So the team members start work based on a guess of what is expected. Very predictably, they spend lots of time doing the wrong things and trying to avoid blame.

You can’t be successful managing projects that have scopes like this. Projects must have measurable deliverables like, “Less than 5% of customers are on hold for more than 30 seconds.” Then you can break down the scope into component parts, the deliverables, and tell the team members exactly what you expect from them. These deliverables, must be objectively defined. You won’t give them just a due date as the only performance measure.

Project Management Tracking: Gathering Status Data From the Team 

Project Management Tracking

Each week project managers must gather status information to give project management tracking updates to the sponsor. Some PMs conduct status meetings with the aim to report that NOTHING bad happened during the week.  If a team member expresses confusion on their assignment or says that finishing by the due date is impossible, the PM becomes angry. They blame the team member for not asking the right questions, for slacking off or letting down the team. Isn’t is funny how the PM doesn’t hear any bad news after that? Well, at least not until the finish date draws near. How to Write a Weekly Status Report

In this environment, the team members have to guess about what is expected or run to the PM daily to ask what they should do.  Most people do both. But because the PM doesn’t know exactly what the project should produce, their answers are vague.  Soon no one admits any problems and everyone says they’re on schedule. That’s because they quickly learned that to report anything else brings down the wrath of the gods.

The PM’s experience when reporting to the sponsor is similar.  Everything besides good news triggers a snarl. The PM soon resorts to saying, “Everything is going according to plan,” or “Every task is in ‘green light’ status.” No one is solving problems early. As the due date draws closer, the team members make a wild guess at what they should produce and they frantically slap some junk together.

This is a bad, but common, example of project management tracking. Everyone on the project is wearing blindfolds. No one actually knows what the project is supposed to deliver.  The project team members are trying to guess what’s expected of them. When they ask questions, they just hear the project due date repeated at louder and louder volume. And the project manager doesn’t know how the project is doing.

Project Management Tracking: Doing It the Right Way

How should you and project executives build a plan that lets you do effective project management tracking and solve problems early? First, you and the executives must define the scope as a deliverable with acceptance criteria that are measurable. Then you must build a high-level framework of deliverables that lead to that end result. And you must define each of those deliverables with a metric.

Next you break  the high level deliverables down into smaller tasks. You stop at the level of deliverables that each team members will produce. These deliverables tell the team members what’s expected of them. So they know what a good job is before they even start work.

With these project management tracking metrics, you and executives can measure progress against unambiguous and measurable checkpoints. You can also spot problems early. That’s possible as long as your behavior when you receive bad news encourages team members to report problems as soon as they occur. They mustn’t hold back bad news out of fear of incurring your anger.

These steps allow the project management tracking to show things like this:

“Achievement #47 – “The customer history screen lets our service reps answer 85 percent of customer inquiries in less than 60 seconds without referring a question to another department.” 

Status: “As of last Friday, this task was 23% complete and not the planned 26% complete. That is due to a snowstorm which caused absenteeism among user personnel. Without corrective action, we will finish this task 5 days late. That will cause three successor tasks to start late and postpone the project completion by 4 days and exceed the budget by $10,000. I propose the following corrective action…”

This project management tracking status report has several good features. First, the PM is reporting status on an objectively measurable business achievement. They’re not going to need a meeting or long debate to decide whether they have reached the goal. Second, it quantitatively compares “where we are as of last Friday” to “where we should be as of last Friday.” Third, our progress assessment is based on the hours of work completed as of last Friday and it estimates the hours of work remaining. Fourth, the executive is receiving data on 3 quantified dimensions of status tracking (the level of achievement, the duration and the budget), not just the due date.

These project management tracking elements set up the second half of the status report. In it the PM presents data about alternatives for solving the problem. Having three quantified dimensions for each assignment lets the PM develop quantified options for executive decision-making. These alternatives might continue the status report as follows:

We have three options for recovery. First, we can hire an outside programmer to work on the coding. This option would allow us to recapture the lost days of duration but will increase the budget by $3,000.  Second,…”

The PM proposes alternatives that involve trade-offs between the level of achievement, duration and budget. The executive can make a decision from the options because the PM has seen this problem coming and has plotted corrective action. The most important feature is that all this is happening before the task is actually late.

Project Management Tracking Summary

The foundation for effective project management tracking and status reporting is laid during project planning. That’s where the project manager and executives define unambiguous deliverables and checkpoints for measuring progress. See also our Project Manager Skills Main Page

This process is the heart of the methodology we teach in our private, online instructor-led Project Management Basics course. We can also design a customized program for your organization and deliver it at your site or in online webinars.


Project Trade Off – Scope, Time, Cost, Risk, Quality

Dick Billows, PMP
Dick Billows, PMP

Project managers use trade offs to provide decision-makers with data on the impact of a change on scope, time, cost, quality and risks. Then the sponsor understands the full impact whenever they have a variance or a change request. Trade offs maintain the project’s feasibility. Project Manager Skills Main Page

Here is an example of  a project trade off.

The sponsor says to the project manager, “I want to move up the finish date from June 30 to May 30.  Make it happen.” The sponsor starts to leave the meeting.

The project manager says, “Yes, I can shorten the duration of the project by four weeks. Your assistant told me about that and I modeled it.  To cut a month off the duration, I will need to have two additional engineers for the month of April and the budget will increase by $10,000 for extra consultants.”

A trade off has two sides. First, there’s the positive side where the PM shortens the duration of the project. Second, there’s the negative side where the project manager says they need added budget for two additional engineers for the month and additional consultants.

The sponsor says,”No all I want is to cut the duration.  No additional people or money.”

The PM says, “If I told you I could do that it would be lie.  To shorten the date there will be other changes.  It is not possible without consequences.”

The sponsor responds, “A good PM would be able to do whatever I want!”

Then the project manager replies, “But it would be a lie.”

Requirements for Trade offs

Trade offs are part of the toolset good project managers use. You must build the project plan with quantified measurable outcomes for every deliverable. And the schedule must have work estimates and accurate precedence relationships. Then you can model every change with its compensating trade offs. Risk Management

When project sponsors want to make a change, successful project managers never say, “Oh no, we can’t add that to the project.” What they say is, “Certainly I can add that to the project, but I will need three more people full time.” Other negative sides of the trade off could be, “We will have to increase the budget by $10,000” or “We’ll have to reduce the savings in our scope by $6,000.” This is the language of trade offs. The project manager is not saying no.  Instead, they are telling the sponsor or stakeholder what it will “cost” to bring about the change they want. Trade offs maintain the feasibility of the project. Merely shortening the duration does not.

Project Trade off Language

You should do what successful project managers do and use trade offs between the scope, schedule, cost, risk and quality when assessing problems and changes to the project plan. When anyone wants to add or change something in an existing project plan, you should always assess the impact on all of the project’s dimensions. If the change is significant enough to require a change order, you should document the trade offs. That information allows the sponsor or customer to decide if the change is worth making.  You should also use trade offs when proposing corrective action for a variance to the plan. The variance should be documented in a status report.  Status Report Template

Here’s a detailed example of using project trade offs.

Let’s say the schedule has a task that was originally underestimated by the consultant hired to produce the deliverable. Now that consultant says it’s going to take an additional 160 hours of work. The PM agrees with the new estimate and quantifies the impact of that increased time on the project budget.  The 160 hours of remaining work will take 4 weeks at the rate of 40 hours a week with the one consultant. Because the task is on the critical path, this will cause a 4 week delay of the project completion date.

The project manager then develops alternative trade offs for dealing with the situation.  First, the PM looks at the trade off that comes from adding one more contractor to the task. In that scenario, the original consultant would do 80 hours of work and the second consultant would do the other 80.  If each worked 40 hours a week, they could finish the task in two weeks rather than four weeks. The cost of hiring the consultant is $100 an hour.  How much would  the project budget increase? The answer is there is no no increase. The addition of the second consultant allows the work to be spread over two people and the duration reduced. But the hours of work remains the same no matter how many people work on it.

There are many other types of trade offs the project manager could use. They might reduce the scope of the project, which usually reduces the amount of work and the duration. They might also consider trade offs for quality and risk. With this explanation of how trade offs work, let’s talk about how you can use the trade off technique in managing your projects.

Project Trade off – 4 Corners

Think of a project as having 4-Corners:

  • project scope (including quality of deliverables)
  • duration
  • risk
  • cost (human resources and materials).

The project is like a tube of toothpaste. When an executive squeezes on a project’s duration corner by cutting the due date by a month, the toothpaste compensates by oozing out from one of the other corners. When the sponsor squeezes the duration, it will deliver less scope, cost more, or have a higher risk of failure. Changes in one corner always impact at least one other corner.  That fact exists whether people recognize or not. It’s not realistic to assume that making arbitrary changes to one corner of the project, like the duration, can happen without any compensating effects through the rest of the project.

Why don’t sponsors recognize this impact? Because in most projects only one, or at most two, of these corners is measurable.  The completion date is always measurable and is often rock solid. In some situations, the project budget is also measurable. But most internal projects have no other measurable dimensions.  Even with the two measured dimensions of duration and budget, the business value of the project (the scope) and the risk of not delivering that scope on time are usually unmeasurable.  So executives continue to make arbitrary changes to the duration and the budget and think that it will have no impact on the project’s scope, quality or risk.

Just think about what happens when a project manager goes back to his team and says, “We have to finish two weeks earlier.” What will the team members do? They will look for shortcuts. The quality may go down and the level of deliverables produced may suffer as a result. Team members also take shortcuts that increase the risk of the project failing. But the project sponsors don’t  know this and they therefore assume there’s no risk from their arbitrary reductions in duration or budget. They are 100 percent confident in delivering the scope within the duration and/or budget.  Now every project manager knows that 100 percent confidence is ridiculous. Particularly because most organizations have a project failure rate above 50 percent.  Yet few project managers give their sponsors the opportunity to make decisions about the level of confidence they want.

Project Trade off – Using the 4 Corners™ Trade off Approach

This is a better approach. If you have a quantified measure of the project’s scope (the business value) and you follow best practices when building the project schedule and budget, you can present your sponsor with quantified trade-offs between the 4-Corners™ of the project plan.  This data-based decision-making and fine-tuning is a good platform for the sponsors’ approval. It is far better than arbitrary changes to one or more of the 4-Corners™ without any offsetting changes to the others. You will also use these quantified trade offs every time there is a variance to the plan.  Your status reports should include analysis of the trade offs between the “4-Corners.”™ That gives the executives data to evaluate the alternatives for taking advantage of opportunities and recovering from problems.

This project trade-offs approach is inconvenient for executives who want to make a change to just one corner. If they do that, you will have projects that aren’t feasible, are late, over budget and achieve less than planned. Arguing with the project sponsor doesn’t work, particularly when they are your superior or your customer. What does work is using decision-making data. That’s the benefit of using project trade offs.

Project Trade off Foundation for Scope, Budget and Duration

Here are the foundations of trade offs:

  1. You must develop alternative combinations of scope, budget and duration by building a project plan and schedule using best practices. The requirements are that you define every deliverable and every task in the work breakdown structure (WBS) with acceptance criteria. That way there’s no ambiguity about the progress or the completion. You base the project plan and schedule on estimates of the amount of work required. You cannot use just start and finish dates. With those components in place, you can offer the sponsor and decision-makers alternatives and trade offs between scope, budget and duration.
  2. During the initial presentation of the project plan, you should model at least three project trade-offs or alternative ways of doing the project. Starting from the project’s base design, you construct three trade offs to finish at least 20% earlier than the base design. You also construct three alternatives that collectively lower the cost of the project by 20%. Having these options available during the project presentation gives you the ability to answer the question that executives often ask, “How can we do this cheaper and faster?”
  3. When your weekly status report shows variances from the plan, you should use project trade offs to model alternative corrective actions to address the variances.
  4. When you have change requests, you should assess the impact of the change on the project scope, duration, risk and cost. Then you present the trade offs between those constraints.

Project Trade off Summary

It is a project management best practice to assess the impact of a change or variance on the project’s scope, cost, duration and risk.  Then you model project trade offs between those “4-Corners” ™ and give the decision-makers alternative ways to deal with the opportunities and problems.

To learn the specific techniques for framing your projects and developing these “4-Corners”™ trade-offs, look at our project management bookstore or consider taking one of our project management training courses. We offer them in-person at your site or as online courses where you work privately with your instructor according to your schedule. More on Decision Making Data,

To master these techniques and the way to present them to the project sponsor, take a look at our advanced techniques courses in your specialty.

[ctct form=”28721″]

Emergency Projects

Dick Billows, PMP

Emergency projects challenge every PM’s professional discipline. When the emergency strike High ranking execs want fast action now… they don’t want thinking, or planning. If you are not moving at high speed… Get out of the way! Everyone else is frantic and if you don’t start responding franticly, they’ll think you don’t care. These hysteria enablers won’t be still until they have a to do list headed, “Start Work NOW!”

So give them the todo list and then use the resulting silence and calm to identify the decision makers who will judge the success of the emergency response. Let them define success then you can start the planing with a quantified deliverable which defines the scope. 

What if people/property are in danger!

If the emergency is in the “Act of God” category (fire, flood, earthquake, tsunami, meteor strike), there will be law, public  safety and political officials all over the place.  They each will have their own goals want to be in charge of saving people and property. You won’t begin work until all the people and property are secure.  But in the meantime, you can plan so once the people and property are secure you can start work with a developed and detailed plan for whatever type of emergency you face.

Marketing/Operational Emergency 

Another type of emergency is affects the organization’s:

  • market positions
  • product competitive positions
  • systems integrity
  • loss of prized human resources 

There are many examples of these emergencies. In one of them a competitor might exclusively acquire a new technology that will allow them to profitably sell your #3 product for 35% less than you do.  Resulting in a potential drop in your revenues of 23%. 

Recovery Project Scope

The initial thinking about the scope of the recovery project is often focused on “getting back to where we were.” In other words, the recovery project should aim to make us just like we were before the emergency.  But a better way to think through the planning is to recognize that we may

Often the best thing to do is take 5 minutes to assemble a todo ir only It doesn’t matter if you are the most experienced PM out there or if you just started your career in this field. There will be times when things don’t go your way and  you have a crisis project. As a matter of fact, if things wouldn’t go wrong from time to time, we would not have an opportunity to learn from our mistakes. However, it is also important to remember that no matter what the situation, a good PM always turns to problem analysis and planning first, that’s good crisis management. Project Planning Main Page

Towards the end of last year, I was reminded of the importance of planning during times of crisis. We had just completed a smaller migration project. This project was a rather routine exercise, as we had done similar projects multiple times before. The objective of the project was to move a number of trading transactions from one book to another in our main trading platform. We had a standard plan for this kind of project, everyone had signed-off on the plan, we had a number of test rounds, and finally, we did the migration in our production system. And then came the crisis. During our initial analysis and throughout the implementation phase, we had overlooked a small, but rather important parameter, and as a result we had produced a little mess in our main general ledger. Needless to say that most of our users had a tendency to panic, and the first thought was to move into action immediately, and to just adjust the ledger manually. This would have taken a whole day, and it would have bound numerous resources.

Crisis Planning

So how do you convince a crowd not to just jump into action, but to first perform an analysis and a planning session? You remind them about the consequences if the quick fix doesn’t work. The reason we had been in this situation was that we overlooked something before; hence, I reminded them that we don’t want to do the same mistake twice. Obviously, not everyone agreed, but most users understood the importance of analyzing the error and planning the response. So we did our analysis and created a simple “project plan”. This was not an endless document, on the contrary, it was an email, but a structured one. The email had the following sections:

  • Objective including a “business case”, which was the result of the error analysis
  • List of Stakeholders
  • Risks & Constraints
  • Procurement (we concluded that we can fix the problem ourselves)
  • A brief WBS
  • Communications Plan

During this “crisis” planning phase we discovered a very simple method of fixing the error, so the fix was truly “quick” and required a lot less time and resources than the original quick fix. Once the fix was implemented, I produced a lessons learned document and adjusted our standard plan for procedures like this. By following the standard project management during a crisis situation, we had forced ourselves to think first and agree on the way forward. In our case, the analysis part revealed a better solution, but even if we would have had to manually correct the error, we would have brought everyone back into the boat.

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

[ctct form=”28721″]

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