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.”
“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.
Project estimators know how to play the commitment game. The sponsor wants commitments from the PM very early in the project. The process is often political and involves much more than numbers. The Project estimators play the estimating game properly and don’t get caught committing to numbers that have a low probability of success.
Let’s look at some of the games surrounding project estimates and then discuss what the Project Estimator should do. 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 costs and duration with a commitment from the PM to hit those numbers.When asked for those project estimates by an executive during the initiation process, a project manager may answer with any of the following Project Estimator Tactics:
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.
We’ll be done in 5 months or so and the cost will come in at about $110,000, but that’s just a rough guess!
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.
When do you want us to finish and what’s the budget?
Answer #1 – It’s truthful but enrages executives.
Answer #2 – Executives quickly forget “rough guess” and are happy.
Answer #3 – It’s the whole truth but it’s useless for executives.
Answer #4 – It’s very ingratiating but 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 is caught in a narrow vise when asked to provide estimates, particularly when the scope of the project is vague and the availability of resources is largely unknown. Project Estimator Tactics are a must. That’s how we make this situation a little better for everyone with a four-step estimating process that we announce during the initiation process. We explain the estimates executives will receive in each of four stages in the project lifecycle.
The Four Stage Project Estimates Process with Project Estimator Tactics
Initiating: Project level analogous estimates based on similar projects.
Early in planning: Project level and major deliverable analogous estimates.
Final project planning: Bottom up estimates from the team members.
Weekly status reporting: Rolling estimates weekly until completion.
Let’s look at a four stage estimating process that we 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 and I want you to develop a consistent template, pronto. This is a high priority for me and you’ll get everyone’s cooperation. Listen, I have to run to a meeting right now but come back at 3:00. I want to know when you and your team can get it done.”
So the PM thinks through prior experiences with similar projects and accesses the archives for similar project estimates. At 3:00 the project manager is ready and says, “During the project I will give you 4 different estimates. The accuracy will get better and better as we know more and more. 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 that done in 18 to 35 working days.”
The executive gives the PM a poisonous look and says, “Okay, come back when you can give me a better estimate.”
The PM says, “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.”
The PM smiles, “I would still need a sponsor’s signature on the scope and deliverables.”
The executive nods glumly, “OK lets get to it tomorrow at 8:00 am.”
After the following day’s 8:00 o’clock session, the executive frowns at the PM and asks, “Now, how long will the project take?”
The PM looks over the notes on a yellow pad and says, “At this point, I can give you a better project-level estimate. We’re still working top-down based on similar projects, but I can give you a somewhat tighter estimate and also apply some ratios to that so I can give you project estimates on 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 on the following phase estimates:
Branch office managers sign off on requirements: 4-7 days
Development test – Test group can complete the template < 60 minutes: 5-8 days
Training- User can complete template in 45 minutes: 4-5 days
Roll-out and enforcement – 95% compliance: 10-15 days.”
The executive scowls again and asks, “When will I get better numbers?”
The PM answers, “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 we’ve been using. Bottom-up is more accurate because I’ll be using estimates from the people who will be doing the work and aggregating them into the overall numbers.”
A few days later, the PM returns to the executive’s office and says, “Here’s the bottom-up estimate I mentioned. With the work breakdown structure done 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.”
The PM nods and says, “The fourth type of estimate I’ll be giving you is a rolling weekly estimate. As we progress further into the process, the uncertainty will decrease and I’ll regularly give you new estimates. We call these rolling estimates. As an example, once the requirements are approved the uncertainty in the development work will go down a lot and that estimate will get much tighter.”
Are These Project Estimates and Project Estimator Tactics Statistical Hocus Pocus?
The simple four-step process we’ve gone through illustrated how a project manager gave project estimates and changed estimating techniques as the uncertainty about the project declined. In the example, the PM used analogous estimates based on information about previous projects. Next working top-down, the PM estimated by major deliverable using ratios from previous projects. However, this information could have come from an organizational project databank, from commercial estimating methodologies or from 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 work breakdown structure and duration/work estimating techniques at the level of individual assignments. Then the numbers got a lot better because the PM could use a bottom-up approach and aggregate the estimates of project team members to develop the overall project estimate. In this bottom-up approach, the PM based the estimate on the team member’s own estimates for their individual assignments. The fourth estimate type was the rolling estimates, also based on a bottom up approach, with the team members making regular weekly re-estimates of their work/duration. As we complete tasks, the uncertainty decreases each week and the estimates become more accurate.
The one consistent thread through each of the steps was that our PM had the benefit of a clear and unambiguous scope definition and equally measurable outcomes for each of the deliverables and assignments in the project. Estimating is difficult enough without the burden of a vague project scope or mushy team member assignments.
A major step to consistent project success and vastly improved project estimates comes from a modest investment in archiving data from previous projects. This whole estimating process becomes more effective when the organization stops playing those fantasy games with project estimates and adopts a consistent methodology for developing the kind of “better and more accurate” estimates we’ve been discussing.
To learn more about these estimating techniques consider our advanced project management courses over the Internet as well as our in-person seminars for organizations.
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
building 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:
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.
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.
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.
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.
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.
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.
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 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.
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.
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 with 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.
The correct steps for successfully leading teams are challenging and so they’re often missed. Highly motivated, problem-solving teams are a key reason for every project success. These teams are committed to the goal and to completing their assignments on time and within budget. The proven techniques you’ll learn here include:
selecting the right team members
crafting the right-size assignment for each person
accurately estimating hours of work and duration
gaining team member commitment
receiving status reports
giving constructive feedback.
Leading Teams: Techniques for Three Sizes of Projects:
The techniques are different for each project, depending on the size and scope. Here are the project size definitions:
Tier 1: Small – they’re done within one department Tier 2: Cross-functional – they affect multiple departments and cross organizational boundaries Tier 3: Strategic – they’re organization-wide programs (or projects for clients) with strategic impact.
Leading Teams Technique #1: Selecting Team Members
In the selection process, you’re trying to get the best people for your project team. But you’re also gathering information about their work habits and personality so you can craft the right assignment for them. Tier 1: Small projects: You are usually familiar with the potential team members’ work performance and quality standards when you all work in the same department. You need to ask the boss for the people you want on your team during the project planning phase. That’s when the boss is focused on the project and can give you hints about the correct assignment for each of them. Tier 2: Cross-functional projects: When you have to borrow your team members from other departments or organizations, it is more difficult to make sure you get productive team members. If possible, you should interview potential team members to assess their work ethic, problem solving style and quality standards. Tier 3: Strategic projects: On large projects for your organization or your clients, you may not be able to select the team members. If personal interviews are possible, you can gather information about potential team members’ experience and work standards. You will use that information to design the right assignments for each person. If interviews aren’t possible, you will have to make an on-the-spot judgement about the right assignment for each team member. Leading Remote Project Teams
Leading Teams Technique #2: Designing Appropriate Assignments
You must design the assignments so they fit the capabilities and personality type of each team member. You want to give larger/longer assignments to people who have solid technical experience and are skilled problem solvers. This will give them a challenge. You should give shorter assignments to people who are experienced and/or less capable. This will let you easily track their progress and help them when it’s necessary. Tier 1: Small projects: You usually have flexibility about the duration of assignments. For trainee-level team members or less capable people, you want assignments that are 1 to 3 days long. For the average team member, 5-day assignments are usually the right size. For experienced professionals, you should design assignments that are 2 weeks or longer to give them a challenge and independence. Tier 2: Cross-functional projects: With people borrowed from other departments, it is often acceptable to talk with their boss about the right size assignment and the level of challenge you should give them. If that’s not possible, then you will adjust the complexity and length of the assignment as they work on the task and you learn their capabilities. Tier 3: Strategic projects: On larger projects with people who are accountable for major deliverables, you need to engage them in the design of their assignments. You must avoid micromanagement of these experienced people who are very capable. On the other hand, you should give “rookies” assignments that are within their capabilities in terms of time and complexity. Team Micromanagement
Leading Teams Technique #3: Work Packages
You must clearly describe, in measurable terms, the deliverable(s) the team member should produce. And you must document their availability, as approved by their boss. Tier 1: Small projects: This level of documentation is often skipped on small projects with three or four team members working on project within a department. But having a simple work pack for each team member avoids confusion about your expectations for their deliverable. Tier 2: Cross-functional projects & Tier 3: Strategic projects: For larger projects, you should document a work package for each assignment. It will make the assignment clear and document the deliverable you expect the borrowed person to produce. The work package also provides a standard format and information base for estimating the hours of work for the tasks and identifying their risks. It is best to document the work estimate and give a copy to borrowed team member’s superior. Team Building Techniques
Leading Teams Technique #4: Estimating Task Work and Duration
A project management best practice is to estimate the required hours of work so you can measure progress during the assignment. Team Types All projects: Regardless of the size of the project, you should engage the team members in the process of estimating the amount of work their assignment will take. The work package is the basis for the estimating effort. You are estimating the amount of work (50 hours, for example), not the duration (Oct. 21 through Nov. 7, for example). You should always estimate the amount of work, such as 50 hours. You never estimate just the duration, such as Oct. 21 through Nov. 7. The amount of work required for the task provides you with the ability to more accurately track progress and spot problems. Their availability to do the work (halftime, 2 days a week, for example) is also documented. Team Building
You should also discuss the assignment’s potential risks with the team member and what can be done about them. This helps you avoid, eliminate or mitigate those risks. Finally, the work package should list the required deliverable, the approach to take and the inputs the team member requires to finish their task. Team Building video
Leading Teams Technique #5: Status Reporting
Team members should report status on their tasks every week. This allows you to find problems early so you have an opportunity to fix them before the task or project is late or over budget.
All Projects: Data can come to you by phone, e-mails, a form, template or on “sticky notes.” The important thing is that each week you get the hours of work competed (as of that date) and the estimated hours required to complete the task. No narrative is necessary. You should make status reporting easy so people will do it. It is a best practice to then give all team members updated status data on the entire project. Effective Feedback
Leading Teams Technique #6: Giving Feedback
All projects: You must give feedback to team members on a timely basis. People want to be praised for a job well done. Remember that public praise is the most effective. People also need to be told when their performance does not meet your expectations. This should be done in private and include what they can do to improve. You must deliver feedback in a way that encourages people to tell you about problems early, when you and the team can define a solution or a “work around.” Constructive Feedback
It is extremely ineffective for you to get angry with team members who report bad news. This action (or reaction) dooms you to find out about problems when it’s too late to fix them. Dysfunctional Project Team video
Leading Teams Summary
Use these proven techniques to successfully lead project teams:
select the right team member for each task
assign the right size task for their capabilities
create a work package to define their deliverable
involve the team member in estimating the amount of work required and the duration of their task
You can learn these techniques and enhance your skills for leading teams in our online project management courses. You begin whenever you wish and control the schedule and pace. You work privately with an expert project manager and have as many phone calls and live video conferences as you wish. Take a look at the courses in your specialty.
You need to build project plans by using a lot of science and a touch of art. The art comes in deciding which processes, tools and techniques are best for each new project. The lazy way is to use the same Project Plan steps on every project. But that approach buries small projects with paperwork, meetings and processes that don’t contribute to the odds of its success. On the flip side, it often leaves large strategic initiatives with insufficient project management and overly simplified techniques. You have to use the right techniques and processes for your Project Plans to improve the project’s end results. In this article, I suggest the right steps for building a plan for projects of various sizes. Project Plan Template Main Page
Your first step in Project Plans is always to define the project scope. That is the basis for the scope statement, the work breakdown structure (WBS) and the estimates of cost and duration. The amount of project planning you do relates to the size, risk and complexity of the project. But all project management plans should include a scope statement and a work breakdown structure (WBS). On smaller projects, your project management plan can skip the risk and quality management pieces.
Let’s look at specific Project Plans recommendations for projects of different sizes.
Project Plans for Different Sized Projects
Tier #1 Small Projects: Done within one department for the manager who is your boss. The team members also report to that boss.
Tier #2 Medium Projects: Affect multiple departments and each department contributes deliverables. The final product benefits customers/clients or an internal user.
Tier #3 Strategic Projects: Organization-wide projects or initiatives. They affect a larger number of stakeholders and have long-term effects.
Project Plan Step #1: Identify Stakeholders
Tier #1 Small Projects: This step is not necessary on an in-department project where the manager is the primary stakeholder. Tier #2 Medium Projects: Process to identify stakeholders across the organization. Prevents surprises when you must add late arriving requirements. These cost more at that point than if they were identified during initial planning. Tier #3 Strategic Projects: Process of surveys and interviews to identify internal and external stakeholders affected by the project. You must consider their requirements. Project Management Plan
Project Plan Step #2: Project Business Case
Tier #1 Small Projects: This step is not necessary because you don’t need formal project approval. Tier #2 Medium Projects: Organizations with sound project management processes require a business case. This justifies a project’s priority versus other projects in the portfolio. Tier #3 Strategic Projects: The amount of financial and human resources requires detailed justification. That is based on the strategic impact and benefit of the project.
Project Plan Step # 3: Project Charter
Tier #1 Small Projects: A 1-page broad brush plan is enough. Small Project Planning Techniques Tier #2 Medium Projects: The project charter addresses the project business justification, acceptance criteria, and rough estimates of the human and financial resource requirements. Tier #3 Strategic Projects: The size of the investment in these projects usually requires extensive documentation. It includes the risks, benefits and impacts on other strategic initiatives and the entire organization.
Project Plan Step #4: Gather Project Requirements
Tier #1 Small Projects: Usually limited to a meeting with the boss where you define the project’s Measure of Success (MOS). Tier #2 Medium Projects: You survey stakeholders for their requirements. After considering each requirement, it is either included or explicitly excluded from the project. Tier #3 Strategic Projects: An extensive process of identifying and analyzing requirements gathered from the stakeholders. You also assess stakeholders in terms of their interests in the project and their ability to influence the project’s success (positively or negatively).
Project Plan Step #5: Project Scope Statement
Tier #1 Small Projects: A short statement of the project’s result and acceptance criteria. Tier #2 Medium Projects: A more detailed scope statement that covers the major deliverables, assumptions and limits. Tier #3 Strategic Projects: A full scope baseline developed. It includes explorations of different ways of delivering the project scope. Project Plan Approval
Project Plan Step #6: Stakeholder Management & Communications Plan
Tier #1 Small Projects: Not necessary with the limited stakeholder group. Tier #2 Medium Projects: Communications plan developed. It takes includes the information requirements of the stakeholders. Tier #3 Strategic Projects: Plan developed for meeting stakeholders’ communication needs. It requires actively managing and resolving all the stakeholders’ issues. Fast Track Project Planning
Project Plan Step #7: Project Change Control
Tier #1 Small Projects: Project sponsor approval is the only requirement. Tier #2 Medium Projects: Use existing organizational process for change control (if it exists). Alternatively, develop a project-specific change control procedure. It must include analysis and documentation standards and identification of specific individuals authorized to approve changes of a specific size. Tier #3 Strategic Projects: Change control and configuration management are often combined for handling changes to project baselines as well as changes to the specifications of the deliverables.
Project Plan Step #8: Project Schedule
Tier #1 Small Projects: Schedule based on work estimates made by the team members. Tier #2 Medium Projects: Schedule based on work estimates plus work packages for each assignment. Tier #3 Strategic Projects: Work-based schedules, work packages with estimates and a work breakdown structure (WBS) dictionary.
Project Plan Step #9: Project Procurement
Tier #1 Small Projects: Usually handled by the purchasing department. Tier #2 Medium Projects:Request for Quotations (RFQs) on smaller purchases. Competitive bids on larger purchases. Tier #3 Strategic Projects: Full competitive bid process. Large Project Planning Techniques
Project Plan Step #10: Project Quality Management
Tier #1 Small Projects: Not necessary. Tier #2 Medium Projects: Quality control effort to measure deliverables against their quality metrics and specifications. Tier #3 Strategic Projects: Quality control plus active quality assurance. The latter is a continuous improvement effort for the processes that produce deliverables.
Project Plan Step #11: Human Resource Management
Tier #1 Small Projects: Not necessary. Tier #2 Medium Projects: Simple resource acquisition plan with limited training provided to team members. Tier #3 Strategic Projects: Human resource staffing, acquisition and team development plans are fully detailed. They are tied to gaps in a “requirements versus capabilities” analysis.
Project Plan Step #12: Risk Analysis
Tier #1 Small Projects: 1-2 hours total. Tier #2 Medium Projects:Qualitative risk analysis with a risk response plan for 5 – 10 key risks. Tier #3 Strategic Projects: Qualitative and quantitative risk analysis with a risk response plan for several dozen risks.
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.
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.
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.