WBS Project Management

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

Reviewing the project’s work breakdown structure or WBS is the best way for an executive to predict the success of a new project. In this work breakdown structure review, it is relatively easy to answer five key project success questions:

  • Will the project team members clearly understand what the PM expects of them?
  • Will the project manager be able to identify problems early when they are small rather than after it is too late to fix them?
  • Will executives and the project sponsor be able to assess progress versus the plan?
  • Will the estimates of work, cost and duration be reasonably accurate?
  • Will the project manager be able to exercise tight control and spot problems early without micromanaging the team?

It is very efficient to assess the entire project planning process by reviewing the work breakdown structure before work starts. At that point, the PM can still make corrections and avoid dozens or hundreds of hours of wasted time. This is such an efficient insurance policy on new projects that we recommend all projects have a peer review of the WBS before they launch.   Main WBS Work Breakdown Structure Page

WBS Project Management: Pre-launch Review

Right before the project launch is a stressful time for project managers and project sponsors. There is tremendous pressure to start work. But a few hours of delay for a WBS review and corrections can save many days of wasted time and head off project failure. Because of the pressure-filled environment, we recommend that this pre-launch WBS review be a mandatory part of the project management protocol. The review takes place at the end of the project planning process.

No matter how big or small the project is, the project manager is always suffering from near-sightedness during the planning process. It’s very hard for the project manager who created the WBS to see its flaws as well as its strengths. Because errors in the work breakdown structure are so costly and so difficult to correct later on, it is advantageous to have another project manager (who was not involved in the planning) evaluate the WBS.

WBS Project Management: Peer Review Steps

  1. You begin the review of the work breakdown structure for another PM’s new project by looking at the structure of the WBS. Look to see if the entries are organized into subheadings for each of the major deliverables of the project. If so, ask a couple of questions of the project manager who developed this WBS. Did the project sponsor and major stakeholders of the project sign off on the project scope and the major deliverables? If the project manager says no, they must go back to the drawing board. Clearly they can’t launch a project that has not been approved by the sponsor and stakeholders.comm23
  2. If the PM answered “yes” to the project sign off, the next items to examine are the entries in the WBS. This includes the high-level deliverables and the scope. Are they deliverables that describe an end result and the acceptance criteria that the sponsor will use to judge the work?  Deliverables should be stated like, “Customer history database is 99% accurate,” or “Average response time on the network is less than three seconds” or “Quality control has signed off on the product prototypes.”

The PM should define each of those deliverables with the acceptance criteria that are either metrics or a yes/no. In other words, they are objectively measurable. If every entry in the work breakdown structure does not meet this measurability criterion, the project should not be launched. The reason this is so critical is that properly defined deliverables tell the team members what’s expected of them.  Measurable deliverables also let the sponsor and executives track progress unambiguously.

3. Next you examine the size or average duration of each of the deliverables the team will produce. What you’re looking for is micromanagement where the project manager has defined a very large number of WBS entries that have a duration of an a few hours or days. If you see that kind of excessive detail, you know several problems will occur. First, the project manager will not be able to keep the project plan current because there is far too much detail. Second, with that level of micro detail it is likely that every one of these entries will change over the course of the project. And the project manager will not be able to keep it up to date. A project plan that’s three weeks out of date is the same as having no plan at all. An average task size that is about a week’s worth of work is reasonable for most projects. Some tasks will not require that much time and others will require several weeks of time. But on the average, you are looking for about a seven-day duration for each of the WBS entries.

4. The next item to check is the adequacy of the deliverable definitions for making duration and work estimates. This is a subjective area but you want deliverables that are defined with enough precision that the team member and project manager can make an accurate estimate of the work involved. If there is inadequate precision, the project manager will develop work packages for the assignments with weak definitions.

5. Finally, you need to examine the WBS to determine whether the project manager will be able to exercise tight control and spot problems early without micromanaging the team. Here you have to look a bit beyond the WBS and determine the requirements for the status report and the frequency of the project manager’s reports. The most important requirement is that the team members provide the PM with an estimate to completion each week. That is the key to project managers being able to identify problems early, when there is time to fix them.

When you are evaluating a work breakdown structure for another project manager, it’s always best to look at it from the perspective of all the different audiences who will use that work breakdown structure: the sponsor, stakeholders, vendors and team members. That analysis will give the PM helpful, well-rounded feedback.

Books by Dick Billows on WBS

Create WBS

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

The WBS or work breakdown structure is not a “to do” list that you can assemble on the first day of a project. It’s a hierarchy of tasks that results from breaking down the sponsor’s major  project deliverables (the scope) into supporting deliverables the team has to produce.

Each of the deliverables in the WBS is a measurable business result, like “Customer hold time reduced to 20 seconds on average.”  It is not an activity like “Lower hold time.” That is ambiguous. How would a project team know when they were done? How would they know if they achieved the goal?

Creating the WBS with team members is always worth the time it takes. It’s a great opportunity to develop the team members’ commitment to the project deliverables and give them a sense of ownership. Unfortunately, on many projects, the team members don’t see their tasks until after the project manager has listed everything they must complete. So the team members don’t understand how their individual deliverables connect to the overall scope. And they don’t have a sense of ownership of their individual tasks and the project as a whole. Don’t make that mistake. Here’s how to create a WBS the right way.      Main WBS Work Breakdown Structure Page

Create WBS: Begin With A Measurable Scope

The starting point for working with your team is after the project sponsor has approved the project’s scope and 4 to 7 major deliverables.  You should develop the work breakdown structure by working top-down from the scope. Do not assemble a list of the things people want in the project. That “to do” list approach yields projects that cost more and take longer than they should. That’s another mistake to avoid.

You and your team members should decompose the project scope by breaking it down into 4 to 7 high-level deliverables. Each major deliverable is an entry in the WBS and is stated as a metric. That means it is measurable and has an acceptance criteria. You break each of the major deliverables into its component parts. They are the elements required to produce that deliverable. You work down each level of deliverables, subdividing them into smaller deliverables. You stop when you get down to the level of individual team member assignments. That’s how you develop the work breakdown structure top-down.

Create WBS: Brainstorming With the Team

When your team members participate in defining the deliverables with acceptance criteria they understand how the entire network of deliverables fits together. And they are committed to the project’s success because they participated in the process. Let’s dig deeper into the process of brainstorming with the team to break down a deliverable into its component parts. Let’s say you’re decomposing a measurable deliverable like, “Employees can retrieve items from the supply inventory in less than 180 seconds 90% of the time.” You and the team might identify the following supporting deliverables:

  • install new supply room map that lets 90% of the people locate the shelf with their item in less than 60 seconds
  • reorganize shelves so people can find their specific item in less than 45 seconds
  • automate the supply “signed out” process so people can record the item(s) they took in less than 1 minute and 15 seconds.

There may be many ways to go about achieving the high-level deliverable of reducing the time required to retrieve supplies. During the conversation with your team, you would allow people to suggest different ways of achieving that end result. But it’s a best practice to achieve consensus on the approach to each of the deliverables.

Create WBS: Archived or Expert Information

Another way to develop the work breakdown structure is to use work breakdown structures archived from previous projects.  You may not be able to use the prior project’s entire work breakdown structure.  But very often you and your team can find a section of a WBS that’s close enough to what you’re doing in the present project that you can copy the deliverables.

On larger projects that are more complex, you may bring in experts on certain kinds of deliverables like computer programs, remodeling of workspace and so on. You would use their expertise to help you and the team develop the deliverables for your project.

Create WBS: Sequencing and Assigning Resources

The sequence of tasks in the WBS  is controlled by predecessors. Predecessors  identify the relationship between tasks. They tell the team what tasks are linked to other tasks. For example, Task A must be completed before Task B can begin. Or Tasks C and D must begin at the same time.

Next you assign resources to each task in the WBS. The resources can be people, materials, or contractors. You get input from the team members on the amount of resources required for each task. Their input is invaluable if they have experience with the specific or similar tasks. When you calculate the duration of every task in the WBS you have completed your project schedule. After the project sponsor approves the schedule, you save that approved version as the baseline. As work begins, you keep track of the progress the team makes on each task compared to the baseline. That is the basis for your weekly status reporting.

Create WBS: Best Practices

The WBS is central to the entire process of planning, scheduling and tracking a project. The best practices for developing a work breakdown structure involve these steps:

  1. After the project sponsor defines the scope (overall objective), the project manager and team members begin creating the WBS. They decompose (break down) the scope into 4 to 7 major deliverables that are measurable.
  2. The project manager and team members break down each of the major deliverables into smaller deliverables. Each one is stated as an acceptance criteria metric.
  3. The project manager and team members sequence the deliverable tasks and assign resources to them.
  4. The project manager obtains the sponsor’s approval of the WBS plan and schedule before beginning work.

Project Presentation & Approval

 Project Presentation & Approval Process

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

The project presentation& approval process varies from organization to organization. In some, it is a rational data-driven process of strategic and tactical planning. In others, it is a highly charged political game where project managers keep their backs to the wall to avoid a dagger from behind. Whatever the environment, there are two classic fantasies that executive sponsors play whenever the phrase “project presentation & approval” is mentioned. There is also a game project managers play to cope with the sponsors’ demands. Project Phases Main Page

Project Presentation: Executive Fantasy Land

Project sponsors and high-level stakeholders think that if their organization has good project managers, the project approval process will go like this:

The project manager strides confidently to the front of the Board Room. The long table before them is filled with corporate big shots. The PM makes one rock solid commitment after another. There is no whining about contingencies or risks. The PM listens politely to a question about budget and the completion date and then says, “We WILL complete the project for $3,123,876.56 and the last of our 1,347 tasks will end on March 9th, 2016 at 3:42 PM.”

As the executives applaud, the PM holds up a hand for silence and says, “That’s Eastern Standard Time,” and flashes a shy smile as the executives go wild with excitement and awe.

Executive sponsors who live in this fantasyland think that projects have no risk. Budgets and completion dates can be set in stone and any failure to hit them means that someone goofed off and didn’t do their duty to the organization.

In this project approval fantasyland, a project is a machine. The executives push buttons and twirl some dials and the project machine spits out any result they want within whatever duration and budget they set. Sponsors merely give project managers the budgets and completion dates and they all come true with a little hard work. If an executive wants a project result early, it is just a matter of tweeking the “due date dial.”

This project approval fantasy triggers a lot of destructive executive behavior:

  • They force change after change on a project and then feel personally betrayed when it is late or over budget.
  • They treat a project manager as a fool and a liar when the PM won’t give them a finish date commitment during the first planning meeting.
  • They sneer at requests for budget and duration extensions, considering them a sign of weakness and sloth.

Project Presentation: Used Car Lot

In other organizations, the roles and actions surrounding the project presentation resemble a sleazy used car lot. The executives are the innocent customers and the PM is a slick shyster in flashy clothes. Here the approval process goes like this:

The executives stroll onto the used car lot, looking for simple but effective transportation. No high-powered hot rods, no fancy wheel covers or custom interiors. Just a basic car to carry the executives where they want to go. The PM slithers out from under a rock and wraps an arm around all the executives. “I’ve got just the thing for sports like you,” the PM says in an oily voice.

“We are not ‘sports’,” the executives say. “We just want a basic car; something simple and cheap.”

“That’s what I was saying,” the PM says with a snicker. “Let me show you this beauty. I’ve been saving it for just the right customer.” The PM leads the executives toward a far corner of the lot.

On the way, one of the executives spots a simple economy model and says, “Wait, that’s what we want!”

The PM sneers, “Everyone will laugh at you if you drive that wreck. It’s outdated, antiquated and uses ’80s technology. You’ll be laughing-stocks and it will break down a lot.”

Scared at making a mistake, they follow the PM to a dark corner of the car lot. The PM pulls an enormous drop cloth off a vehicle, saying, “Here’s what you want!”

The executives peer into the gloom and see an enormous vehicle that will carry too many people. The interior is plush leather, there are 3 stereo systems, 12 speakers, a TV and a wet bar.

The executives protest, “This is too much, too big, too expensive. We want the little car back there!”

The PM starts to talk, waving complex charts and graphs and saying, “This is the latest technology, the best economy and the. . .”

The PM’s pitch mesmerizes and hypnotizes the executives. A few minutes later, they drive off in the big expensive monster.

This project approval approach also triggers a lot of destructive executive behavior:

  • Sponsors review project plans with a fine-toothed comb, searching for unwanted and unneeded features, options and fixtures.
  • They think every number a project manager presents is a lie. Cutting their duration and cost estimates is just getting rid of all the padding.
  • Project managers hide tasks in their projects to give their friends an easy time at work. They believe 33% of all the project tasks fall into this category and they can eliminate them with no consequences.

Project Presentation: The Eager Puppy Dog

Too many PMs play the eager puppy dog in project approval presentations to stay out of trouble. The approval discussion goes like this:

The sponsor says, “I think this budget looks just a tad fat. You can get it done for 20% less, can’t you?”

The PM nods like an eager puppy and hurries off to slash the budget by 20%. The easiest way to do that is to reduce the work and time in each task by 20%. The PM is able to return with the lower budget and, as a bonus, a shorter duration. This convinces the sponsor that the PM is not a slick shyster and that the project will run like a well-oiled machine.

When the project approval session ends, both the sponsor and the PM have learned a lesson. The sponsor has learned that the PM’s plans have a lot of fat built in. So next time the cut will be 30%, not just 20%. The lesson the PM has learned is that next time he’ll pad the plan by 25%. Then arbitrary changes won’t cripple the effort before it even starts.

Project Presentation: Rebel Without a Clue

Still other project managers prepare to go into project presentation approval meetings ready for battle. Holding a clenched fist into the air, these rebel PMs tell the team members, “I will fight for our plan! Those nitwits in suits will not change one bit of the brilliant plan we have put together.”

The rebel then heads for the meeting room for the planning session with his boss, his boss’s boss and the executive whose signature is on his paycheck. The discussion goes like this:

The executive asks, “What will it take to finish a month earlier? We have two other competitive initiatives and I would like all three to hit the market at the same time.”

The PM says, “Finishing earlier is impossible! There is no way we can finish any earlier than June 30th. Even that date will require so much overtime that the team members’ family lives will be horribly disrupted. There’s no way. We can’t do it!”

The controller says, “I’d like to see a little less use of consultants and lower fees. Don’t we have internal people who could do some of this work? Maybe they can work with the consultants.”

The rebel PM answers, “Impossible, we need their expertise and I have negotiated their fees down to a fraction of what they charge other companies.”

These executives huddle for moment as the PM waits behind the podium.

Then the most senior executive says, “We approve the project with a completion date of April 30th and a budget that is $25,000 less than your plan. We’re also more than willing to find another PM if you can’t hit those targets.”

The rebel explains the executives’ treachery to the team members and no one learns any project presentation lessons.

Summary

The key to successful project approval meetings is for PMs to be ready with options and alternatives for finishing earlier, spending less money and using alternative resources. Good project managers are happy to change the plan to fit the executives’ requirements if the scope, budget and duration are feasible.

More on Decision Making Data

Learn how to use our proven project approval process and create trade-offs between scope, budget and duration in our online courses with your personal instructor. We can also design a customized seminar for your organization and deliver it online or at your site.

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, 125 cold springs dr, georgetown, TX, 78633, 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

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 especially senior managers) 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.”

Project Planning: A Waste of Time?

Why do many managers and executives have the attitude that project planning is a waste of time?  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 or define what they consider to be a fix.
  • 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 Reason #1

The most common reason why they have never seen a project properly planned is that the organization doesn’t exercise control or require justification for starting a new project. There is no reason to plan if people can start a project any time they want. The organization also doesn’t require a return on investment (payback) from a 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.

Project Planning: A Waste of Time Reason #2

A second and very common reason for these “waste of time” attitudes is that many executives have never sponsored, run or even worked on a properly planned project. As a result, they don’t know 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 project manager 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.

Project Planning: What Is Top-Down Planning?

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 planning a project from the top down. 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 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.

A well-planned project uses the top-down project planning technique. Top-down project planning starts with a project scope that is defined in measurable terms. 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. Next you break the criteria down into deliverables for each assignment. 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 they must deliver 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. In this situation, 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.

Project Planning: Top-Down Benefits

When you use top-down project planning, you make as many of the decisions as possible during the planning process which is before you ever start work. When the team does start work, they focus on executing the plan, 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. In top-down project planning you start with a clear definition of the project’s scope. Then you can break it down into high-level deliverables. You continue to break these down into sub-deliverables until you get to the level of tasks you assign to the team members.

Project Planning Summary

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.  Working from the top down, 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. The key to top-down project planning is having a clear scope definition that you can break down into high-level deliverables and sub-deliverables. Then you have the basis for a work breakdown structure (WBS) that minimizes the amount of work required to successfully deliver the project’s scope.

Consider our online project management courses to learn how to use all the tools and techniques for top-down project management planning. You’ll work privately with Dick Billows, PMP, 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 Dick as you wish. Take a look at the courses in your specialty.

Get free articles and videos like this every week

Project Plan – Answer Tough Questions

Every project manager must get Project Plan Approval before they begin work. That includes getting the “go-ahead” for the plan, schedule and budget for a new project. Even if you have been working closely with the sponsor and stakeholders, there is still the need to persuasively present the information you have developed. Too many project managers approach these meetings as “data dumps.” They think all they have to do is recite the scope, budget and schedule highlights and the executives will automatically give their approval.

A better approach is to anticipate the questions the decision-makers will ask you about your data. There are two questions that have been asked in every project approval meeting since the dawn of time.

Project Plan Questions: Time and Cost

First, the executives want to know how the project can finish earlier. Second, they want to know how the projects’ cost can be reduced. You, as the project manager, must have answers to these questions in the form of alternative ways of doing the project. If you don’t, the executives will make arbitrary changes to the budget and schedule. Then tproject plan approvalhey’ll tell you to find ways to make it happen.

Project Plan Answers: Trade-offs

You must be prepared to answer these questions with “trade-off options” so your project has a chance of success. The trade-offs will give  the executives information about how the project can finish earlier and deliver the scope for less cost. Specifically, you need to have modeled options for finishing 10% and 20% earlier and delivering the scope for 10% and 20% less than the budget you submitted for their approval. You need to have these alternatives ready to present in the project approval meeting. If you don’t provide the data, the executives are likely to arbitrarily decide that you can finish the project 20% earlier without additional people or budget.

If you aren’t prepared to respond to the inevitable questions about finishing earlier and spending less money, you will leave the project approval meeting with a project that is doomed to fail.

Here is a video about how to answer difficult questions from executives.

How to Answer Executives' Questions

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

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, 125 cold springs dr, georgetown, TX, 78633, 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.

 

Procurement Management Planning

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

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

Lecture Video

Project Manager in Action Video

Project Charter Development

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

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

Lecture Video

Project Manager in Action Video

Work Breakdown Structure Tasks

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

The Work Breakdown Structure (WBS) tasks are the basis for the project manager’s assignments to the team members. They are used to estimate costs and the schedule (duration). It is also the framework for reporting the project’s status to the sponsor. The WBS is central to everything a project manager does and plays a major role in determining the project’s success. You build this network of tasks by breaking down the project scope and major deliverables. The Work Breakdown Structure (WBS) contains everything that the team must produce to deliver the project scope.  Main WBS Work Breakdown Structure Page

Work Breakdown Structure Tasks – Questions

People always have questions about how to build the Work Breakdown Structure (WBS). They often ask how big the WBS should be and how many tasks it should have. There is no magic number of tasks in a project. The number in your work breakdown structure depends on the capability of your team members. You need to consider a number of factors.

  • What is the correct duration for the assignments I’m going to make to my team?
  • How frequently do I want to receive status data and estimates to complete from my project team and vendors?
  • How often do I want to update the project schedule with current data?
  • How risky are the tasks in this project?

Work Breakdown Structure Tasks and Team Capabilities

As you can see from this list, you design the tasks in the Work Breakdown Structure to fit your management style and the capabilities of the project team members. In this article, we’ll consider the team member’s capabilities. If you have a project team made up of experienced professionals who have performed their tasks dozens of times, your work breakdown structure will have a small number of large tasks. The tasks will have longer durations because these experienced professionals can handle assignment durations of 7 to 21 days. you should give experienced professionals larger, more challenging assignments and the independence and decision-making freedom that go with it.

WBS Work Breakdown Structure

However, not every team is composed of project superstars. You’re going to have some people on your team who have some experience with projects and know their jobs but for whom a two-week assignment would be discouraging and maybe even intimidating. So for these people you’ll design task assignments that are about 5 to 7 day’s worth of work.  You’re still giving them responsibility for an important deliverable but you’ve broken it up into smaller pieces. That lets you track their work more frequently.  Frequent deliverables are a major factor in the accuracy of your status reports.  That’s because even before a deliverable is finished and accepted, your team members report how much work they’ve completed and how much work remains to be done.

Finally, you may have a team with new hires or people who have little experience with your company. Or they may have limited expertise in the technology of their task or no experience working on projects. With these people, you want to break the assignments into small pieces where they have a deliverable to produce every day or two. You would have a large work breakdown structure containing smaller tasks with short durations. That kind of Work Breakdown Structure works best with inexperienced people because you will be expecting several deliverables from them every week. This gives you the opportunity for frequent feedback on their work and coaching to improve their performance. With these newer team members, it is a valuable motivational technique to increase the size of their assignments as they demonstrate their ability to produce deliverables on time and within budget.

Designing your Work Breakdown Structure with these team member considerations also allocates your time properly. You don’t want or need to spend a much time reviewing the work of one of your experienced project superstars. That kind of micromanagement will irritate them and interfere with their feelings of independence and professionalism. That’s why you give them the biggest assignments with the longest duration. The people who need the most review of their deliverables will have the smaller assignments and shorter duration. That’s where you’ll spend most of your time.

Work Breakdown Structure Task Risks

The last consideration in the Work Breakdown Structure is the risk of each individual task. They can affect the risk of the project as a whole. If one or two of the high-level deliverables have a high risk of duration or cost overrun, you’ll break down those major deliverables into smaller pieces. Some examples are deliverables that have a high risk of changes in technology or the technology is uncertain and cost overruns are likely. When you break down those major deliverables into smaller pieces, you’ll get reports on them every day or two. That prevents big problems from surprising you when it’s too late to fix them.

You can learn how to create the Work Breakdown Structure in our online project management courses. We offer online project management courses in business, IT, construction, healthcare, and consulting. At the beginning of your course, you and your instructor will have a phone or video conference to design your program and what you want to learn. We make certain that your case studies, project plans, schedules and presentations fit your specialty. You can study whenever it fits your schedule and work at your own pace.

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