Project Planning Template

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

You can use this project planning template to define the project scope and identify major deliverables. You can also use it to manage the project risks and constraints as well as the resources it requires. On every new project, you need to decide what Project Planning Template elements to include, what to exclude and how to develop them on each particular project.   For 90% of the projects done in most organizations, your project plan should be 1–2 pages long. Managers are more likely to read a short, concise document.

Project Planning Template 1st Step – Define the Scope

You need to define the project scope as a deliverable with measurable acceptance criteria. To do that, you talk with the project sponsor, ask questions and then develop the scope statement. Next you define 4 to 7 high-level deliverables and their associated acceptance criteria. Those criteria tell everyone exactly what the project must deliver. They also help you control expectations by making it clear what the project will and won’t deliver. Fast Track Project Plans

When you ask the sponsor what he or she wants, they might say something like, “We really need to have this project cut costs for us.” You immediately try to get to quantified acceptance criteria by asking, “How much cost reduction would make this project a success?”

When the sponsor says, “$15,000 of cost reductions,” you have the scope definition with an acceptance criterion that tells you how much cost reduction the project has to deliver. This is the key to the project plan template. You can then drive the rest of the project from that number. (On larger projects consider the scope reach) How to evaluate a project plan

This is a simple example of top-down planning but most project managers don’t ask the right questions. They are satisfied with a To Do list of the first dozen things the project sponsor wants them to do. That is a terrible basis for your a project plan and it’s disastrous if you start work with no more information than a To Do list. To successfully plan a project and have high odds of project success, you need to know what the boss wants in measurable terms.  How to Plan Top Down

Project Planning Template 2nd Step – Define Major Deliverables

You then break down the measurable project scope into its major supporting deliverables.  There are several different ways to do this. The simplest is where the high-level deliverables literally add up to the scope and its acceptance criteria. Therefore, in a conversation with the sponsor, you might talk about how to break down the scope. The sponsor might say, “I want each department to develop their share of the overall savings.” During further discussion, you might identify the savings amount for each of those departments. You use them as your high-level deliverables with the acceptance criteria being the dollar amount of savings each department has to produce.

You see the major deliverables below and how they add up to the project scope of $15,000 of cost reductions.

  • Reduce order intake monthly operating expense by $4,000
  • Reduce production monthly operating expense by $2,000
  • Reduce order production monthly operating expense by $3,000
  • Reduce inventory monthly operating expense by $2,000
  • Reduce shipping monthly operating expense by $4,000  project plan template

Project Planning Template 3rd Step – Identify Major Risks

Depending on the size of the project, you may invest a great deal of time identifying the risks that threaten the project. You can do this in brainstorming sessions with the project team and stakeholders. But on a small project, you might develop your list of risks over coffee. In either case, you’ll include them in the project plan along with ideas for mitigating those risks. See example risks you would enter into the project plan template below:

  •  Layoffs may result in labor actions which disrupt operations
  •  Production may drop as much as 25% for 3 – 5 months.

Project Planning Template 4th Step – Identify Project Team Resource Requirements

Using the major deliverables, you now identify the number of hours of work and the skill sets required to create each deliverable. You would total those estimates up to the level of the entire project and make very rough estimates of the people and skills required. Below are examples that you would enter into the project plan template.

  •  Bill – full time 3 months
  •  Mary – half time 2 months
  •  Raj – full time 3 months
  •  Sharmaine – quarter time 4 months
  •  Henry – full time one week

Project Planning Template 5th Step – Break Down to Individual Tasks

The last of the five steps in creating the project plan is to decompose those major deliverables developed in the second step. You break them down into smaller deliverables until you reach the level of a deliverable that’s an appropriate assignment for one team member. That’s the level of your work breakdown structure (WBS). It completes the project planning process in the project plan template. Then you can move on to the scheduling process.

Project Planning Template in Practice

In many organizations, project planning is a combination of vague generalities about the objective of the project. But the one thing that is often rock solid is the completion date. That date is frequently the only measurable project result. Because project managers don’t know what the executives want them to deliver, they have no ability to exercise control over the scope of the project. As a result, the objectives change weekly. Project team member assignments are vague and ever-changing. That is why estimating is inaccurate and why 70% of projects fail when they are planned that way. Let’s look at the best practices for project planning and then look at a project plan template for projects of different size.

Project Planning Template “Best Practices” In the Real World

Very often, project managers face a difficult organizational environment. The organization lacks the processes to do project management right and the executives don’t know how to play their role correctly. In these situations, the PMs need best practices that allow them to do things effectively, even though the executives and the organization’s processes are obstacles and not assets. The project plan template will help. The purpose of this intense project planning process is to make all the decisions before starting work. The approach of making the project plan and then executing it is much more efficient than a “plan as you go” process. However, it is very difficult in many organizations.

For this approach to work, the organization, its executives and project managers must do things correctly. That is, the executives must specify exactly what they want the project to deliver. They cannot make the project assignment using vague generalities where the only thing that is specific is the due date. The organization must have processes for evaluating and prioritizing projects and giving them access to resources based on those priorities. Last, the project managers must know how to do top-down project planning. That means they are able to take the clear acceptance criteria, specified by the executive/sponsor, and decompose it down to the level of specific assignments for each team member. Most organizations fail to meet one or more of these criteria and that is why we rarely see an ideal project planning process. There are two major ways to go Large Project Planning Techniques or for less paperwork and meetings,  Small Project Planning Techniques.

Project Planning Templates by Scale of the Project

We utilize three tiers of project plans techniques in the project plan template. They depend on the scale and complexity of the project:

  • Tier 1: Small Project Plans – Done within a department with the boss as the sponsor.
  • Tier 2: Medium Project Plans – Affect multiple departments or done for customers/clients.
  • Tier 3: Strategic Project Plans – Organization-wide projects with long-term effects.shutterstock_96175697

Identify Stakeholders

  • Tier 1 – Identifying stakeholders is not necessary on an in-department project where the manager is the primary stakeholder.
  • Tier 2 – We must identify stakeholders across the organization and find out their requirements early. Requirements cost more late in the project than they would have at the beginning.
  • Tier three – Requires an elaborate process of surveys and interviews to identify internal and external stakeholders so we can consider their requirements.

Project Business Case

  • Tier 1 – We often skip this since we don’t need formal project approval on an in-department project.
  • Tier 2 – Organizations with sound project management processes require a business case to justify a project’s priority versus other projects in the portfolio.
  • Tier 3 – The scale of financial and human resources usually requires detailed justification and demonstration of the strategic impact of the project.

Project Charter

  • Tier 1 – A 1-page broadbrush plan with achievement network, risks, resources and PM authority.
  • Tier 2 – This project charter addresses the project acceptance criteria, business justification and rough estimates of the resource requirements (human and financial).
  • Tier 3 – The size of the investment in these strategic projects usually requires extensive documentation of risks, benefits and impacts on other strategic initiatives and the entire organization.

Gather Project Requirements

  • Tier 1 – Usually limited to a meeting with the boss where the PM defines the project’s scope and decomposes it into the major deliverables.
  • Tier 2 – We survey project stakeholders for their requirements. Each requirement is reviewed and either included or explicitly excluded from the project.
  • Tier 3 – We follow an extensive process of identifying and analyzing requirements gathered from the stakeholders. It includes assessing stakeholders in terms of their interests and their ability to influence the project’s success.

Project Scope Statement

  • Tier 1 – A short statement of the project’s desired result and the acceptance criteria.
  • Tier 2 – A more detailed scope statement that also covers assumptions, constraints and the major deliverables.
  • Tier 3 – A full scope baseline development with exploration of alternative means of delivering the project scope.

Work Breakdown Structure (WBS)

  • Tier 1 – Decompose high-level deliverables into the deliverable for each team member’s assignment.
  • Tier 2 – Decompose high-level deliverables and use WBS sections from previous projects that are similar.
  • Tier 3 – Usually developed in sections with the people responsible for that major deliverable doing the decomposition.

Project Planning Template Summary

This project plan template uses a five-step project planning process. You can modify the planning to fit projects of different sizes depending on their complexity. You can learn to use this template in our online Project Management Basics courses. You’ll work privately with Dick Billows, PMP, an expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish.

During an introductory video conference, you and Dick Billows, will design your program and what you want to learn. You will choose you course and select your case study from business, marketing, construction, healthcare, or consulting options.  Your case study-based assignments that include project plans, schedules and presentations will fit your project specialty.

Lessons Learned Review

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

The lessons learned processes are ineffective in most organizations. Consequently, they suffer from the same mistakes on one project after another. Even worse, the bigger the project failure, the less likely the organization is to learn from it. The same issues that cause a project to fail also prevent the people involved from learning from that failure. Organizations need lessons learned processes to make sure they don’t relive project failures. Let’s take a look at a typical Lessons Learned review session and then talk about the right way to do it. Project Lessons Learned Main Page

Lessons Learned: Poking Through the Wreckage

You shuffled into your post-project review session, sick and tired of the political games and the finger-pointing. Twenty minutes later, you trudged out with the voices still echoing in your head:

    “No, you’re responsible for us finishing late!”
    “Me? You kept making changes. I’m surprised we ever finished!”
    “You still aren’t finished. The crap you gave us still doesn’t work!”

           “What? We gave you what you asked for! You just didn’t train your people to use it

           “They’d need PhD’s to use what you built!”

You walked down the hall knowing this was your fault. Sure, there were some jerks involved in the project and it would be easy to blame them. But you knew that a good project manager could structure things to make even the jerks productive.

As scenes like this repeat themselves after each project, the organization’s processes for doing projects don’t improve. The same problems wreck project after project. But there is an alternative.

Living Lessons Learned

What you need instead is a living lessons learned process that gives the organization and its project managers an opportunity for continuous improvement. The time you invest in your post-project review should also positively affect projects that are underway and reinforce the use of a consistent project management methodology. You gain these advantages with a living lessons learned process conducted in three stages.

Lessons Learned: Step 1 – Pre-Launch Peer Review

We have experienced good success with our 4PM.com clients using peer reviews of projects thatLessons Learned are ready to launch. That sounds fancier than it is. This just means that PM’s get feedback on a their plan from other PM’s. Sometimes they hold a live web meeting to discuss a recent plan. That gives PM’s the chance to share ideas and renew their understanding of the methodology.

While the pre-launch stage is a busy time for project managers, it’s also the point at which correcting mistakes is least expensive. The process is straightforward. The other project managers review the business situation faced by the user or client. Then they independently critique the project’s strategic planning, scope statement, requirements, WBS, charter, accountability structure, team assignments and schedule. If the organization’s PM methodology places a premium on thinking (not paperwork), it does not take the other project managers very long to review several project plans.

In the review session itself, the other PM’s ask questions and offer ideas, which the project manager whose work is under review may take or ignore. The project manager gets the benefit of the thinking of other PM’s engaged in the same type of work. Every project manager suffers from tunnel vision as he or she works through the final development of their detailed plan. So the thinking of other project managers who are not buried in all the details is enormously helpful. They can spot disconnects between the user’s or client’s business problem and the project plan details. However, it is important to keep this conversation up at the project management level, focusing on “Are we doing the right project for this business problem?” and “Does the planned control process make sense for the desired business result and resources involved?” The conversation should not sink into a technology debate.

Sessions like these are effective in building consistency in the use of a project management methodology. Compliance with project management standards tends to slip under the pressure of all the work that must be done just before launch. But when project managers know their peers will be reviewing their work, they comply at a point early in the lifecycle when comments from the project office or standards people might otherwise be brushed aside.

These pre-launch peer reviews are ideal for reinforcing the organization’s project management methodology. The right people are dealing with real business situations and projects, not theoretical ideals. As a result, these sessions are good opportunities to renew people’s skills in using the organization’s project management methodology.

Lessons Learned: Step 2 – Corrective Action and Changes

The second step is regular (usually weekly) review of project variances. The PM and team members decide on corrective action on variances at the weekly status report meeting. Then the PM should go through the variances again. During this second round, they focus on how to avoid the same variances in the future. They also identify other tasks that are likely to have the same issue. The focus is on ways to avoid a repeat and it does not take long to identify the options.

To do this review, the project methodology must give PM’s a reliable method of identifying changes to the approved baseline schedule. The organization needs a methodology that gives the PM objective measures of project progress plus the work and cost estimates to measure the variance.

Lessons Learned: Step 3 – Team Culture and Leadership Style

The last step is the periodic assessment of the culture of the project team and the project manager’s leadership style. Obviously the project team members’ work attitudes and effectiveness are stroLessons Learnedngly influenced by the leadership behavior of the PM. But even a professional team may suffer in silence about the PM’s leadership rather than take the risk of providing constructive feedback.

Constructive feedback is very useful so we have to offer a “safe” environment for team members to give it. An effective technique is to ask the team to have lunch together once a quarter without the PM. They write a summary of the PM’s strengths and weaknesses on which they reached consensus. The PM should digest the information but ask no questions about it. Most importantly, the PM should not ask them to justify any of the negative feedback. That makes the PM appear defensive. Good project managers act on negative feedback and make themselves better. Bad PM’s can’t handle the criticism and learn nothing.

Lessons Learned Review Summary

The Lessons Learned review is a three-step living lessons learned process for project management improvement. It is an important element in moving the organization toward delivering consistently successful projects because it is a process through the entire project lifecycle. It also contributes to developing a cadre of consistently effective project managers who get better over time and don’t repeatedly relive failures.

More information on lessons learned

We include this post-project review living lessons learned process in our project management methodology.  We teach it in our online project management certifications and training seminars for clients.

Project Initiation: It’s Not Like a Fast Food Drive-through Window

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

The Project Initiation step is often crushed  by executives who hysterically shout, “Get started quickly! We’ll plan when we have more time..this project is critical.” This hysteria saves them from having to commit to exactly what they want. Avoiding a commitment about what they want the project to deliver makes it easy to blame other people when the project fails. To be fair, however, the executive may not know what the project should produce.  A person higher up the chain of command may have dumped the project in their lap.

Experienced project managers know the bitter consequences of skipping Project Initiation. They include scope creep, time wasted on pointless tasks and significant overruns.  So experienced PMs try to stop the freight train and say, “Sir, if the project is that critical, we can’t take short cuts. We have to initiate the project properly.  I certainly wouldn’t want to explain why we skipped the initial planning step if the project fails.”  That approach works some of the time. Project Phases Main Page

A professional project initiation process for small or large projects addresses the following important decisions:

  1. The sponsor tells the PM how he will measure the result of the project  at the end. That is the scope of the project. It’s how will the sponsor will measure the success of the project. In other words, he defines a good job on the project with metrics (costs are reduced 23%, sales are up 10%, turnaround time is reduced 1.5 days, error rates are reduced 4%).  The end result is the target the PM and team aim for.  You will waste a lot of person hours if you don’t know the project’s scope.
  2. With the scope defined you can talk about the path to reach it from  where you are now.  You define this path with measured deliverables. These are numbers that define success, just like the scope.  Each deliverable must be a metric.
  3. Next you breakdown each deliverable until you reach the level of a task that our team can deliver in less than two weeks.

The Project Initiation Drive-through

Failed projects are often initiated like the sponsor ordered at the drive-through window of a fast-food joint. In this situation, you, the project manager, can’t control the scope so the project finishes late and produces very little business value. Consistent project failure usually starts when PMs and sponsors initiate projects with fast food order-taking techniques. Let’s see how this order-taking process works.

The project manager stands at the drive-through window wearing a red and yellow cap that says “Projects Are Us.” The executive drives up in a shiny black car, stops at the drive-through window and says, “I want to clean up customer service by March 30th.”

The project manager nods eagerly, gives the executive the “thumbs up” signal and screams at the project team:
“You two, put some new software on the grill!”
“Dan, dump some training into the deep fry!”
“Monica, we need more service rep cubicles and new computers, now!”

The executive smiles, “Wow, you know how to manage a project; no needless meetings or endless paper work.”

The order-taker project manager gives the executive another toothy grin and says, “We are cranking and everything is in green light status. We’re already about half done.”

The executive leans back thinking, then says,”I’d like a network with 30 nano-second response time and 50 gigamondo disk drives. And…can we add mauve wall coverings in the computer room? How about multi-lingual training?”

The order-taker project manager grins and says, “No problem; we’re flexible. I can make any changes you want.”

The executive frowns, “I’m in a hurry, so speed it up.”

The order-taker project manager whirls and whispers to the project team, “Let’s go! Get something slapped together by the due date…we can tweak it later. Let’s get to it!” Then he smiles at the executive and gives the thumbs up sign.

The executive returns two weeks later and says, “Your crappy software doesn’t work. No one knows how to use it and the new computer room is a fire hazard. The customers are still howling about being on hold too long. That’s what I wanted fixed. This is another project disaster!”

Happy Executives at Project Initiation… or at the End of the Project

The sad thing about this order-taking technique for Project Initiation is that it makes some executives and users happy. When you initiate projects like this, you and the team start work quickly. Executives like that. They also like that they can avoid deciding exactly what they want the project to produce. That lets them off the hook for committing to the project scope. However, the odds are nearly zero of the PM delivering a successful project and having satisfied executives/users/customers when the project is complete. This order-taking approach begins a process that allows changes every week. Why is that? Because the order-taking process does not produce a scope definition that is objectively measured or controlled. Order-taking does not make the executives commit to what they want. Even worse, when the PM acts like an order-taker, that’s how the executives perceive them. So what is the best Project Initiation process?

The Best Practice for Project Initiation

First, you must abandon the order-taking process of listing vague requirements and starting work quickly. Instead, you must ask questions to learn enough about the executive’s business problem so you can help them define the project scope.

Project InitiationExecutives who are not used to project managers asking questions may resent it. But a successful project manager responds to these objections with a reasonable statement like, “How can I deliver the business end result you want if I don’t know precisely what it is?”

Executives may not like that push back. But it’s worth some early executive dissatisfaction because it helps you define a measured business result for the project scope. It helps you avoid a list of ever-changing requirements. Let’s return to our story and see how to do this correctly.

How to Use the Best Practice for Project Initiation

The executive stops at the drive-through window and says, “I want to clean up customer service by March 30th.”

The project manager answers, “Exactly what result are you looking for?”

A flash of anger washes across the executive’s face, “Just get started. I’m in a hurry. When are you going to start work?”

The project manager says, “We’ll start immediately after I understand the results you’re looking for. What’s the result you want from the project?”

“I need better efficiency,” snaps the executive.

The PM says, “I understand. How much improvement in efficiency?”

The executive frowns in anger again, “Why are you asking all these questions instead of starting work?”

The PM politely responds, “Because you won’t be pleased with our work if it doesn’t help you achieve your objectives. So I need to know what they are. What amount of efficiency improvement do you need?”

“Enough to cut costs by 12% from the customer service department. We need training, new systems, new cubicles, etc,” the executive says.

“Well, if you want to have a 12% cost reduction by cutting staff, each customer service rep will have to be able to handle 12% more customer calls.”

The executive smiles, “Right. Then we could gradually let attrition reduce the staff. Now let’s get into the details of how to do that…”

Using this approach, the project manager avoided starting a project that was almost certain to fail. A results-focused approach to project initiation and planning produces benefits for the entire portfolio of projects. Learn more about how to initiate and plan projects.

You can learn all these skills in our project management courses. Take a look at the courses in your industry specialty.

Project Planning from the Top Down

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

In many organizations, managers and senior management view project planning as a waste of time. To them, the project plan is needless. They want to “start work immediately without wasting time in useless planning meetings and creating mounds of paperwork.” As a result, project managers have difficulty engaging management in the project-planning task. Why do they have this attitude? Why are they unwilling to invest their time in project planning? Here are a few of the reasons:

  • They have never seen a project properly planned so they have no understanding of how smoothly things can run.
  • Project planning requires that the sponsor and stakeholders know what business result they want the project to produce. Often executives start projects to fix a problem they have just heard about. They have no idea how to solve it.
  • The sponsor and stakeholders are unwilling to make commitments about the acceptance criteria for the project’s deliverables. They are unwilling to take the risk of specifying precisely what they want. Project Plan Template Main Page

Project Planning: A Waste of Time?

Why do many managers and executives have the attitude that project planning is a waste of time? The first and most common reason is that the organization doesn’t exercise control or justification for starting a new project. There is no reason to plan if they can start a project any time they want and the organization doesn’t require a return on investment (payback) from doing the project. On the other hand, executives must plan their projects if the organization requires the following:

  • a cost-benefit analysis for new projects
  • a clear specification for the business results the project will produce
  • its cost and duration.

A second and very common reason for these attitudes is that many executives have never sponsored, run or even worked on a properly planned project. As a result, they have no idea of the benefits a properly planned project can deliver. Their projects usually miss their planned completion dates and budgets. They rarely deliver the project scope or any business value. Project teams don’t know what they are accountable for delivering, what performance level the project manager expects or how the PM will evaluate their work. As a result, the project manager must tell the team members what to do each week. The executives also have no practical experience with change control. They don’t realize that a well-conceived project plan gives them and the project manager tools to manage changes to the scope, budget, quality and resources.

Despite the reasons why the executives have the attitude that project planning is a waste of time and resources, you (as the project manager) must persuade them of the benefits of doing a project plan. When executives want to start a project, you must describe the right steps and explain how that process benefits the organization. Finally, you must discuss the required top down project planning techniques, documents and meetings. Executives also need to understand that you cannot use the same project planning techniques for every project. You should not bury a small project in needless paperwork. But a large strategic project will suffer if there isn’t sufficient planning, control and risk management.

Project Planning: Top-Down Benefits

A well-planned project uses the top-down project planning technique. That means the sponsor identifies the overall scope of the project and the deliverable(s) the project has to produce. Then you and the sponsor identify the acceptance criteria that the executives will use to approve those deliverables. This lets you and every project team member know exactly what the executives want in a deliverable before you start work. On a well-run project, you and the team members don’t have to stop work to figure out what to do next. Each team member’s assignment or task is specifically defined so they know what a good job is before they begin work.project planning

Project teams that must stop and figure out what to do next are working on a project with a To Do list plan. The project manager planned the first thing they’re going to do, then the second and then the third. Things get a little vague after that so the team members must stop work and ask the PM what to do next. That process continues until the planned completion date is looming on the horizon. At that point, the PM and team members must stop work and plan what they can quickly finish before the completion date. This is a disaster for the project and the PM’s career.

When you use top-down project planning, you make as many of the decisions as possible during the planning process before you start work. This lets the team focus on executing, not re-planning the project. You save several hours of meetings, talks and arguments for every hour you spend planning before the work actually begins.

Top-down project planning also saves you from doing the wrong things on the project. That’s because you have done all the thinking on the deliverables before you start work. And that means you don’t incur the costs of having to produce “missing” deliverables at the last moment.
You are certain to have a failed project if you fall into the trap of starting work immediately without using the top-down project planning technique. The executives who forced you to start work quickly will be exceedingly dissatisfied with the results as well as the money and the time spent to produce them. The only way out of this situation is to explain to the project executives that success is a direct result of a solid planning effort.  You and the sponsor must define the scope of the work and the acceptance criteria that the project stakeholders will use to judge its success. That’s the key to top-down project planning. When you have a clear scope definition, you can break it down into high-level deliverables. Then you have the basis for a work breakdown structure (WBS) that minimizes the amount of work required to deliver the project scope.

Consider our online project management courses to learn how to use all the tools and techniques for project management plans. You’ll work privately with an expert project manager as your instructor and coach. You begin when you wish and control the pace and schedule. You can have as many phone calls and live video conferences with your instructor as you wish. Take a look at the courses in your specialty.

Get free articles and videos like this every week

Project Estimator – How to Play the Commitment Game

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

The project estimator knows how to play the commitment game. The project sponsor wants commitments about the project’s duration and cost very early in the project. The process is often political and involves much more than numbers. But experienced project estimators play the estimating game properly and don’t get caught committing to numbers that have a low probability of success.

Project Estimator: The Tactics

Let’s look at some of the games surrounding project estimates and then discuss what tactics the project estimator should use. In the real world, estimating a project’s duration and cost is a high stakes game. The client or executive wants an accurate estimate of the project’s costs and duration. And they want the project manager to commit to hitting those numbers. When an executive asks for those estimates during the initiation process, project estimators often respond with some of the following answers:

  1. I’m 60% confident that we can finish the project within a duration range of 3-8 months and a cost between $50,000 and $250,000.
  2. We’ll be done in approximately 5 months and the cost will come in at about $110,000. But that’s just a rough guess!
  3. I will have no idea until we detail the deliverables, estimate the work and find out how many people I will have to do that work.
  4. When do you want us to finish and what’s the budget?

Answer #1 – It’s truthful but it enrages executives.
Answer #2 – Executives quickly forget the“rough guess” and are happy.
Answer #3 – It’s the whole truth but it’s useless for executives.
Answer #4 – It’s very ingratiating to executives but it’s a project deathtrap.

Which choice do most project managers make? Choice #2. It deals with the reality of the situation. Executives are under the gun to make cost/benefit and priority decisions about projects. There are also strategic realities that force certain completion dates on everyone.

The project estimator, you, are caught in a vise when asked to provide estimates. That’s especially true when the scope of the project is vague and the availability of resources is largely unknown. Project estimator tactics can make this situation a little better for everyone.

Project Estimator: The Four Stage Process

You should announce this four-step estimating process during the project initiation process. You explain the estimates you’ll give executives in each of the four stages in the project lifecycle.

  1. Project Initiating: Use project-level order-of-magnitude estimates that are based on similar projects.
  2. Early in Planning: Use analogous estimates for major deliverables that are based on similar project deliverables.project estimator
  3. Final Stages of Planning: Use bottom- up estimates based on data from project team members.
  4. Status Reporting: Use rolling estimates weekly until the project is completed.

Project Estimator: Stage One

Let’s look at a four-stage estimating process that you might use on a very simple project. An executive invites you into the conference room and says, “All these weekly reports from the branches come in with different data in different formats. I want you to develop a consistent template. Pronto. This is a high priority for me and you’ll get everyone’s cooperation. I have to run to a meeting now but come back at 3:00. I want to know when you and your team can get it done.”

You think through your experience with similar projects and access the archives for estimates from those projects. At 3:00 you’re ready and tell the executive, “During the project I will give you 4 different estimates. The accuracy will improve as I know more about the project. The best I can do now is give you a project-level, order-of-magnitude estimate based on prior experience. I’m 60% confident we can have it done in 18 to 35 working days.”

The executive gives you a poisonous look and says, “Okay, come back when you can give me a better estimate.”

You reply, “I can give you a better estimate as soon as we have finalized the scope and major deliverables and you have signed off on what you want.”

The executive frowns and replies, “I was planning to delegate that.”

You smile, “I would still need a sponsor’s signature on the scope and deliverables.”

The executive nods glumly, “OK let’s get together tomorrow at 8:00 AM.”

Project Estimator: Stage Two

After the following day’s morning session, the executive frowns at you and asks, “Now, how long will the project take?”

You look over your notes and say, “At this point, I can give you a better project-level estimate. We’re still working from the top down based on similar projects. But I can give you a somewhat tighter estimate. I’ll apply some ratios to that and give you project estimates for each phase. I’m 75% confident we can finish in 23-30 working days. Using my experience and the ratios between phases on previous projects, I can also say that I’m 75% confident of the following phase estimates:

  1. Requirements sign-off: Branch office managers sign off on requirements: 4-7 days
  2. Development test: test group can complete the template in < 60 minutes: 5-8 days
  3. Training: Users can complete the template in 45 minutes: 4-5 days
  4. Roll-out and enforcement: 95% user compliance: 10-15 days.”

The executive frowns again and asks, “When will I get better numbers?”

You answer, “As soon as I detail the work estimates and get commitments on the people here at headquarters and in all the branches. Then, I can give you a bottom-up estimate, which will be more precise than the top-down estimates I’ve been using. Bottom-up is more accurate because I’ll be using estimates from the people who will be doing the work. Then I’ll aggregate them into the overall numbers.”

Project Estimator: Stage Three

A few days later, you return to the executive’s office and say, “Here is the bottom-up estimate I mentioned. With the work breakdown structure completed and the resource commitments I’ve noted, I’m 60% certain we can finish within 24-28 working days.”

The executive gives another slightly less venomous sigh and says, “Okay, this is getting better but I’d still like really tight project estimates.”

Project Estimator: Stage Four

You nod and say, “The fourth type of estimate I’ll be giving you is a revised estimate each week. As work progresses, the uncertainty will decrease and I’ll  give you new, more accurate, estimates every week. We call these rolling estimates. As an example, after the stakeholders approved the requirements, the uncertainty in the development work decreased a lot. So I can give you a much tighter estimate.”

Project Estimator Tactics: Statistical Hocus Pocus?

This four-step process illustrated how a project manager changed estimating techniques as the uncertainty about the project declined. In the example, the project manager used analogous estimates based on information about earlier projects. Next working top-down, the PM estimated major deliverables using ratios from prior projects. This information could have come from several sources:

  • an organizational project databank
  • commercial estimating methodologies
  • elaborate statistical analysis of previous projects.

Whatever the source of the data, the top-down estimates provided relatively broad ranges in the overall estimates.

In the third and fourth estimating techniques, the PM used the project work breakdown structure (WBS) and duration/work estimating techniques at the level of individual team member assignments. The numbers got a lot better because the PM used a bottom-up approach. They aggregated the estimates from project team members to develop the overall project estimate. In this bottom-up approach, the PM based the project estimate on the team member’s own estimates for their individual assignments. The fourth estimate type was rolling estimates. They’re also based on a bottom-up approach where the team members make regular weekly re-estimates of their work/duration. As the team completes tasks and deliverables each week, the uncertainty decreases and the estimates become more accurate.

There was one consistent thread through each step. The PM had the benefit of a clear and unambiguous scope definition. And they had  measurable outcomes for each of the assignments and project deliverables. Estimating is difficult enough without the burden of a vague project scope or team member assignments that can’t be measured.

Project Estimator Tactics: Archived Estimates

A major step to consistent project success and vastly improved project estimates comes from archiving data from previous projects. This is a modest investment that makes the entire estimating process more effective. When data from completed projects is archived, the organization can stop playing estimating fantasy games. They have a consistent database and methodology for developing the kind of “better and more accurate” estimates we’ve been discussing.

To learn more about these estimating techniques consider our project management courses over the Internet. You work individually with your instructor and have as many live video conferences as you want.

Get free articles and videos like this every week

Critical Path Method for Shortening Duration

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

The critical path is the longest sequence of tasks in a project. It determines the project’s duration and completion date and it can change  minute to minute. It’s easy to use the project critical path method to cut the duration and optimize your project plans to finish as quickly as possible. Let’s see an example of how to correctly use the critical path technique. Schedule & Software Main Page

Chris Pimbock, the Impudent Project Manager, walked over to a vacant seat the crowded passenger boarding area at gate #63. Chris joined two sullen business travelers waiting to fly home on a Friday evening. They were staring out through the big plate-glass windows of the terminal at a mechanic standing atop an aluminum ladder working on the jet’s port engine.

The blue-suited professional sitting to Chris’ left muttered, “The gate attendant better wake up. Those dopes have to get another mechanic working on that engine pronto!  That’s a critical path task. Without working engines, we won’t go anywhere!”

The thoroughly wrinkled passenger across the aisle growled, “Nah, that captain and his crew all keep looking at their watches. I bet they are about to go off duty. Without a crew, we won’t go anywhere. Getting a new crew is what that gate attendant should work on instead of reading a magazine. That’s the critical path.”

Feigning ignorance, Chris Pimbock asked, “How do you know what’s on the project critical path?

With an exasperated sigh, the guy in the blue suit said, “Experience. Hey, I do this stuff for a living and I know a critical path task when I see one.” The other man nodded agreement.

Chris casually looked over the boarding area at gate #63 and the tarmac. The fight crew was still sitting in the corner chatting. A food truck sat on the tarmac with the driver reading a magazine. A fuel truck waited with the driver watching the mechanic. The gate attendant had left her station and gone to help at the next gate, #61, to get the passengers for that flight checked-in and on board.

The rumpled guy shouted at Chris, “Is that stupid gate attendant gonna get more mechanics? Wait, look the food truck just drove off. That gate attendant is an idiot; ignoring us and working at another gate! Now we’ll have to wait even longer for another food truck while she helps her buddy at the next gate.”

Chris said, “Ahh, give the woman some credit, she knows what she is doing.”project critical path

“That’s crazy. Look the fuel truck is leaving too!” the wrinkled PM snorted. “All she cares about are the passengers at gate #61!

Chris frowned and asked, “So the gate attendant should assign more mechanics to the critical path task and get another fuel truck. Is that critical too?”

The two PMs sneered at Chris. One muttered, “Duh.”

The other PM nodded sadly and said, “Sure. You’ve got to really watch the project critical path tasks like a hawk. And when you add more people you get the tasks done faster.”

Just then the first PM said, “Look,” and pointed out the window at the mechanic who was waving frantically at the gate attendant and holding up a broken wrench and mouthing the words, “Need a new wrench!”

The gate attendant was too busy at the other gate to look out the window. Failing to catch the attendant’s eye, the mechanic picked up his broken wrench and tried to work with it, shaking his head in frustration.

Chris said, “What happened?”

“Thanks to that moron at the gate, this attendant  will dela the flight even longer. The mechanic needs a new tool and she couldn’t see him because she has abandoned us and gone to gate #61. I’m gonna tell her what a dope she is!”

As the wrinkled PM rose to walk to the counter, Chris noted that the plane at gate #61 was leaving. He said, “I would give it a minute or two before you make a jerk of yourself.”

The wrinkled PM slumped back down and said. “That gate attendant has really botched this flight. We’re going to be here for hours.”

They settled back into their chairs and in a moment the gate attendant picked up a black microphone and cleared her throat.

The blue suit predicted, “Now, that dope is going to cancel the flight.”

The loud speakers in the waiting room hissed as a new food truck arrived and the attendant said, “Our new airplane will be pulling up to gate #61 momentarily. Please move to that gate now. We will board in 5 minutes, the plane has fuel, the food is on board and we’re ready to go.”

Chris said, “I guess that gate attendant did the calculations and decided that the sequence of tasks involved in fixing the plane, fueling it, provisioning the food and replacing the crew was longer than getting us a new plane that was ready to go. She used the duration data, not just guesses about what task was critical. She kept her eye on the right critical path the whole time. Most importantly she focused on the correct scope; getting us home tonight, not just fixing the plane.”

Project Critical Path Summary

To learn to identify and optimize the project critical path, consider taking one of our online, instructor-led courses. In these courses, you’ll get coaching from an expert instructor as you practice applying the “best practice” techniques to realistic project case studies. You can work at your own pace to fit your schedule.

 

What Is a Project

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

Are you wondering what is a project and what is not? Here is an example of a project:

The manager of the department you work in tells you the people are wasting time getting supplies from the supply room. He wants you to do a project to fix the problem.

Projects have a specific objective (goal). We want to achieve the goal so we have to do the project only once.  If you keep doing the same project over and over, obviously you’re not achieving the results the boss wanted.

What is a Project: Some Examples

The characteristics of all projects are the same. Their size doesn’t matter. All projects have a unique and specific objective. They have a beginning and end date. They often have a specific budget. The expectation is that we do them only once. Here are some examples of projects:

  • opening a new business
  • developing a computer program to process payroll
  • resurfacing a highway
  • opening a new healthcare clinic
  • What is a Projectbuilding an apartment complex.

What is a Project: The Steps

All of the efforts listed above are projects. All of them follow the same general steps:

  1. Project initiation – in this first step, a manager or executive comes up with the idea for the project. They give a project manager and other people an overview of the idea. The initiation process often includes obtaining approval from the organization to spend money on a project. When approval is given, we begin planning.
  2. Project planning – we need to communicate what the project is trying to produce. That’s called the scope and it’s defined by the manager or executive who initiated the project. Next the project manger develops the project plan. It includes a schedule, a budget and the people we need to work on delivering the scope. Larger projects have many stakeholders, the people who are affected by the project. So the plans for larger projects are more extensive. The project manager presents the project plan and schedule to the organization. When it’sapproved, we begin to execute the plan.
  3. Executing the project – most of the time and money on a project is spent during the executing phase. This is where we actually perform all the tasks specified in the project plan. The tasks are the deliverables that the team produces. The project executive or stakeholders review and accept the deliverables. They may also ask for changes. The project manager is monitoring everything that is happening.
  4. Monitoring and controlling – the project manager will monitor actual results and compare them to the plan. He or she will also identify differences (variances) between the two. When there are differences between the plan and the actual results, the project manager works to correct them.
  5. Closing – when the final deliverable has been produced and accepted, the project needs to be closed out. That involves holding a lessons learned meeting. It documents what we did and didn’t do well.  The intent is to have data that is useful on future projects and help avoid making the same mistakes. Archiving data from the project makes future projects easier and more successful.
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: 4PM.com, 3547 South Ivanhoe Street, Denver, CO, 80237, http://4pm.com. 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

Launch Meeting For A Project

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

The launch meeting has several purposes. They include the following:

  • Expectations for performance and behavior
  • Links between tasks and the overall objective (scope) of the project
  • How the project success will benefit the team members
  • Generating enthusiasm and commitment to the project.

But too often the launch meeting does none of these things. Here are some of the common causes:

  • The sponsor makes vague threats about the consequences of failure
  • The stakeholders are not supportive of the scope and discuss changes to it
  • Department managers discuss pulling their people off the project for higher priorities. Launch Meeting Main Page

To achieve the benefits and avoid the problems, the project sponsor and project manager need to carefully plan and control the project launch meeting. Very often there are issues or concerns that are affecting the team members’ and stakeholders’ attitudes about the project. The project sponsor and project manager should understand these concerns and have a plan for addressing them. The project launch meeting is not the time to “downplay” or try and minimize the concerns. Instead, the project sponsor and project manager should use the launch meeting to directly address people’s concerns about the impact of the project on their departments and their daily work.
Unfortunately, launch meetings often leave team members wondering how they can avoid being blamed if the project fails. They may be concerned about finger-pointing when things don’t go right.

Watch this video as a project sponsor and project manager conduct the worst launch meeting in the history of project management. I’ll point out some of the mistakes the project manager and sponsor make. Then you can listen to the project team members privately describe their reaction to the meeting. Finally, I will analyze what went wrong and suggest how to do it better.

 

Team Assignments – Video

Watch this video about “how to” and “how not to” make team assignments. We show you what the initial meeting with a team member should deliver. Next we’ll discuss an example of how not to make a team member assignment. Finally, we’ll talk about the right way to make team assignments.

Your First Meeting with a New Team Member

The goal of this example project is to improve the quality of the applicants that Human Resources refers to line managers for job interviews. The project manager asks one of the team members to stop by his cubicle to discuss the project.  He is a bit uncertain about how to start the project. He asks the team member to interview all 65 of the company’s first level supervisors about the quality of the job applicants Human Resources is sending them for job interviews. Leading Teams Main Page

Team Assignment: Round 1

The team member returns to the project manager’s cubicle a week later and says, “I finished the last of the 64 interviews this morning. One of the supervisors is in the hospital so I couldn’t interview her.”

The PM says, “Good work. Tell me about the results of the interviews.”

The team member replies, “The hiring supervisors are very unhappy with the quality of the applicants referred by the Human Resources department.  70% of them rate the applicants as poor or unsatisfactory in terms of meeting the job specifications. Only 10% rate the applicants as excellent. We certainly have a problem to solve here.”

The project manager responds, “That’s not what I wanted. I want to know specifically what is wrong with the applicants the HR department sends them to interview. Please go get me the information I want.”

The team member nods at the project manager, turns and walks out, thinking to himself, “If you wanted data about what was wrong with the applicants, you should’ve told me that.”

Team Assignment: Round 2

With a marked lack of enthusiasm, the team member proceeds to again interview the 65 hiring supervisors (the last one was home from the hospital). The supervisors are unhappy with the team member because they feel they’ve contributed enough time to the project. Several remark to him, “You really should decide what you need before you waste people’s time.” The team member says nothing but nods agreement.

Seven days later the team member returns to the project manager’s cubicle. The project manager sternly asks, “Did you get the assignment right this time?”

The team member drops a 1 inch thick report on the project manager’s desk and says, “You asked me to find out what was wrong with the applicants and I have done that. Here are all the flaws of the 76 applicants that the HR department has sent to hiring supervisors in the past year. There are 1,576 things wrong with those applicants.”

The PM rises to his feet, snapping, “This is useless! We can’t correct all the problems on this enormous list. I need to know the top 10 things that are wrong with the applicants. I can’t believe you didn’t understand that when we last talked. You should be able to figure these things out for yourself. But if you can’t, you are responsible for asking questions until you’re clear about your assignment.”

Team Member Assignment

Team Assignment: Round 3

Without saying a word, the team member walks out and begins another round of interviews with the same supervisors. The team member’s lack of enthusiasm is now even worse than that of the supervisors. Also, the team member’s attention to detail is far below his usual work standard. As a result, the data gathered is incomplete and full of errors.

Team Assignment: Who Is At Fault?

Without question, the project manager did a miserable job defining this team member’s assignment. The team member followed the PM’s instructions correctly. In each of the cycles through this stupidity, the team member did what the project manager told him to do. And that is the heart of the problem. The project manager was telling the team member what to do but he didn’t tell the team member the result he wanted the assignment to deliver. If the PM had said, “Identify 10 categories of flaws with the job applicants that Human Resources sends to our supervisors,” the team member would have understood what the PM wanted him to produce. He would have delivered the desired result the first time. But the project manager did not specify the deliverable he wanted. What he told the team member to do was insufficient.

Too often, project managers don’t think about exactly what they want the product of the team member’s assignment to be. It’s much easier to just give the team member a “To Do” list and hope they get the assignment right. If they don’t, the project manager blames the team member rather than himself. When you, as the project manager don’t give your team members a clear and measurable deliverable for their assignment, you make the team members much less effective than they could be. When people have to guess about what a “good job” is, their work effort will be less focused than it could be. Additionally, if members of your project management team are uncertain about your expectations, they will naturally protect themselves by padding their estimates of the work’s cost and duration. They expect your unclear expectations to change and they want to avoid the blame when things turn out badly.

Team Assignment: The Right Way

Consistently successful project managers always define clear performance expectations for team member assignments for every deliverable. If you want to be successful, you need to set a measurable performance expectation for every assignment you give your team members. As work progresses on the team members’ deliverables, you can compare what is being produced to the original, measurable assignment. This allows you to spot and resolve problems early so your projects finish on time and within budget. And it lets your team members feel proud about doing a good job on their assignments. That builds team morale.

Learn how to make clear team member assignments in our online project management basics courses. You’ll work privately with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish.

Get articles and videos like this every week

Project Team Assignments

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

There are two different techniques you can use when you are making project team assignments. The easiest way to assign work to your project team members is to give them activities to complete, like items on a “To Do” list. That technique doesn’t take much thinking and the assignment is usually a little vague. The more effective technique is to make the team members accountable for producing a specific deliverable. Each deliverable must have a measurable outcome. This technique takes a lot of thinking because you must specify exactly what you want the team member to produce and how you will measure it.  Deliverables are always better assignments than a list of To Do’s. That’s because the team member will understand exactly what you expect of them before they start work. People perform at a higher level when they are accountable for deliverables and that is the key to consistent project success.  Let’s discuss how to define and assign deliverables. Leading Teams Main Page

There are several components when you assign a deliverable to a team member. You need an estimate of the amount of work the deliverable will take. You also need to identify the risks in producing the deliverable. A team member often needs to receive work products from others to be able to produce their deliverable. All that information should be stated in a work package.  The work package is a one-page document that gives clear assignments to team members. It also lets team members participate in defining the approach to the task and estimating the amount of work it will take. But let’s get back to the key element, the performance expectation.

Project Team Assignments: Deliverables versus Activities

There is a clear distinction between project team assignments that are activities and those that are deliverables. Activities are “To Do’s” like “teach the payroll system training class.” Deliverables are end results like, “After the payroll class, 85% of the attendees can enter 30 pay changes per hour.” After receiving each of these assignments, a team member can teach a payroll class. But the content will be different with the deliverable assignment because the trainer is not just conducting a class. They have a measured result they are accountable for delivering.  Project managers who design team member assignments as deliverables have significant advantages over those who use activities. Before listing these advantages, let’s make sure you’re clear about the differences between team assignments with activities and those with deliverables. Effective Feedback

Project Team Assignments Example #1: Assignment to a Teenager

The Activity: “Clean up your room.”

The Deliverable: “Put all the empty Pepsi cans and candy wrappers in the garbage can.”

With the activity assignment, the parent have only told the teenager to perform an action. They have not defined the expected outcome. The teenager has to guess what the parent wants. There can be many interpretations of what the “Clean up your room” activity involves. So it is likely that the parent won’t get the end result they’re looking for. The key flaw in this (and any) activity assignment is that there is no clear performance expectation. There is no performance standard to measure the teenager’s actions against. There is only a vague idea of what a “clean room” looks like. As a result, the parent can’t gain the teenager’s commitment to the assignment. And they can’t reasonably deliver consequences for the teen’s good or bad performance. Team building

With the deliverable of “All the empty Pepsi cans and candy wrappers in the garbage can,” the teenager has the potential for better performance and commitment. The expectation is clear and it is possible to get the teen to commit to it. If there are still empty cans and candy wrappers on the floor after the teen says they’re done, they will have to agree that the standard wasn’t met. On the other hand, if they also put their textbooks and computer on the desk, the parent must agree that the teen exceeded the standard. In this example of a deliverable, any rewards and punishments have a better chance of being seen as fair because the standard was clear.

leadership & team assignments

Project Team Assignments Example #2: Assignment to a Team Member

The Activity: “Develop recommendations to reduce turnover.”

The Deliverable: “Get management committee’s approval of policy changes that will cut turnover by 10%.”

With the activity assignment of “Develop recommendations to reduce turnover.”, the project manager must continuously check the team member’s work to guide them. That’s because the team member cannot have a clear idea of what the PM wants. (It’s also possible the PM doesn’t know what the assignment should achieve.) The team member doesn’t know whether to develop 200 recommendations to eliminate all turnover or just a few to bring it down a little. This leads to a game of “Did I get the right answer?” each time the team member thinks they are done.  The team member does some work and brings their recommendations to the PM asking, “Is this what you wanted?” The answer to this question is usually “No.” Then the PM blames the team member, saying, “You didn’t understand the assignment.” So the team member goes back to the drawing board, frustrated and irritated.

These problems are solved with the deliverable assignment of “Get management committee’s approval of policy changes that will cut turnover by 10%.” The project team member knows what’s the PM expects them to deliver and doesn’t have to guess. The PM has a better opportunity to gain the team member’s commitment and positive or negative consequences will be clear and fair. Additionally, the team member can get a sense of satisfaction from meeting the expectation.

So why do PMs assign team members activities rather than deliverables? The answer is because it’s much easier and safer than assigning achievements.  There are two reasons for this. First, by assigning activities, the PM doesn’t have to think through the situation and commit to exactly what he/she wants. They have some wiggle room to change their mind on what they want. Second, it is difficult for the PM to make a mistake when assigning activities. Only the person doing the work can be wrong. Weak PMs always use activity assignments because it’s safe for them and always leaves them wiggle room.

Now let’s look at some more good and bad assignment examples. The bad ones are more entertaining so we’ll start with them.

Project Team Assignments Example #3: Counting the Wrong Thing

Here are a few examples of counting the wrong thing on a customer service improvement project. The project scope is defined as “Provide World Class Customer Service that Delights the Customer.”

  • A PM measures the engineers’ performance by the number of lines of code each one writes. The engineer with the highest total gets a lunch with the CEO.
  • A PM measures the trainers’ performance by the ratings that class attendees give each trainer. The trainer with the highest rating receives a certificate of appreciation.
  • A PM measures the performance of customer service reps by counting the number of interviews each person conducts with customer service managers. The team member with the most interviews gets publicly recognized at a status meeting.

What performance will the PM get from project team assignments like these? In the first example, the engineers will write a lot of lines of code. Some of it may benefit the customer service division but a lot will not. In the second example, the training class attendees will have a fun time and give the trainer a high rating. But they won’t learn much. In the third example, the team members will conduct a lot of interviews. But much of the information will be gathered in a hurried manner and may be useless.

The project managers in these examples counted the activities being performed and got the results they deserved. These activities produced high volumes of whatever the PM was counting, even if it contributed little value to the project. The PMs probably didn’t know what business value the project needed to deliver. So they created assignments that were activities they could identify without much thought.

Project Team Assignments Example #4: Counting Only Dates

Another form of counting the wrong thing occurs when the project due date or duration is the only measurable result. The due date usually comes from an executive. It doesn’t consider the amount of work required or the availability of the people to do it. Next the project manager picks the due date of each assignment to support the entire project’s due date. In this situation, the team members have no commitment to their assignments’ dates because they were forced upon them.  They often recognize that the dates are impossible even before work starts.

At each status meeting the PM asks, “Are you on track to hit your due dates? You committed to them.” Most team members give the PM an optimistic thumbs up. Then one day a truthful person says, “No, that date is impossible. There is no way I can hit it.” The PM gets angry and from them on, everyone is afraid to tell the truth about their assignment. So they report they are on target to meet their dates. They don’t mention that they’re counting on miracles to do so. When the due date draws near, the team members slap together whatever they can and turn it in. It’s poor quality work, but at least it’s on time. The organization then spends months and thousands of dollars to fix the failed project.

Project sponsors drive much of this “due date behavior” when all they focus on is the due dates of the entire project and the team assignments. I don’t mean to imply that the dates are not important; they are. But delivering junk by the due date does not make the project a success. Unfortunately, most project sponsors are used to to having only dates for tracking the project’s progress. Too many project managers don’t report anything else that is measurable. Everything else they report is vague, subjective statements. So it’s not surprising that sponsors like dates because they are objectively measurable and unambiguous.

What project managers need to do is to count the right things. They need to count the end result (the business value) the project produces, the date, the cost and the risk. These techniques take a more time but they yield enormous benefits. Let’s see how you do that.

Project Team Assignments: Assignment Deliverable Hierarchy

To be a successful project manager, you must work with the sponsor to define measured deliverables for the project scope. Then you define the major deliverables that lead to it. This includes the acceptance criteria the sponsor will use to measure the project’s success. Let’s use the customer service project example again. This time the scope definition the sponsor sets is “Complete 95% of customer phone calls within 3 minutes team assignmentswith less than 3% calling back about the same problem.” This is a clear measured outcome. Then you break it down into smaller achievements that support the scope.

As you break down the scope into its IT system deliverables, you come to the GUI (screen display) that an engineer has to develop for the customer service reps to use. That measured achievement could be “Customer service reps see 6 months of customer history within 4 seconds of entering the customer’s name or number.” Please note that this achievement is measured in the users’ business point of view. It is not measured in the IT system engineering department’s business point of view. This is much more supportive of the project’s scope than lines of code (like the PM used in the earlier example).

The trainer has a different achievement, too. Their assignment could be “80% of the class attendees can answer the top 20 customer questions in 120 seconds or less using the new GUI.” Again, what you are counting is more relevant to the project’s scope than whether the attendees enjoyed the class and the trainer.

The team members interviewing the customer service managers could have a measured business outcome like, “Managers reach consensus on the ten most important customer service problems.” This is much more supportive of the project’s scope than counting the number of interviews conducted.

That sounds pretty straightforward but it takes time, thought and planning to create this assignment deliverable hierarchy. You must think about what to count and measure. They must be relevant to achieving the project’s scope. Performance expectations must be clear to the team members before they start work. So you must define team members’ assignments in measureable terms. That encourages their commitment and makes estimating and tracking much more precise. It also lets you spot problems early, when you have a chance to fix them. It plays an important role in managing projects that deliver successful results. When you assign a project team member a deliverable, it is easier to clarify your expectations, gain their commitment and give them rewards that are based on performance. All the techniques in this article are part of our private,  training courses and certifications delivered over the Internet or as in-person seminars for organizations.

Get free articles and videos like this every week