Work Breakdown Schedule

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

The work breakdown schedule (WBS) is the spine of your project plan. The most important function is to communicate clear performance expectations about the project. For executives, the work breakdown schedule communicates exactly what they’re going to get from the project. That is what the business results will be. The WBS entries, from the scope down to the smallest team member’s task, are measurable deliverables.  Each clearly communicates a performance expectation with numbers so it is measurable.  As an example, the scope of a customer service project might be, “Less than 5% of customers have to contact customer service a second time about the same problem.”  That number is a measurable deliverable, it’s an acceptance criterion. Specifically, the project is successful if fewer than 5% of the customers have to call back about the same problem.  When you communicate that expectation to the executives, they know what they’re going to get from the project. As importantly, they know what they’re not going to get. It clearly tells them that the result will not be perfection. They will still have about 5% of the customers calling back about the same problem.  Main Work Breakdown Structure Page

Work Breakdown Schedule: Trade-offs

The work breakdown schedule is a tool for project managers to control expectations. It communicates to executives that they cannot change the project’s scope without compensating adjustments, called trade-offs, to the project’s duration and/or cost. Dealing with those trade-offs is a key to managing the expectations of sponsors and other executives. Consistently successful project managers use those trade-offs during the initial planning phase to communicate expectations about the project’s scope, time, cost and risk. The scope and major deliverables must be defined in measurable terms so the trade-offs can be quantified. If the scope isn’t defined in this manner, the project will have overruns and dissatisfied sponsors and executives.

Here’s a conversation with “Less than 5% of customers call back about the same problem” as a measurable scope:

An executive says, ” Oh you can do better than that; make it 3%.”

The project manager smiles and says, “We modeled that earlier. Remember?We have a 75% chance of hitting your 3% but it will cost $150,000 more and take 18 months longer.  Do you want to authorize that trade-off?”

The executive replies, “Where did those numbers come from?”

The PM says, “From the computer model we built of the project.  Is this what you want?”

The sponsor’s face turns beet red and he sputters “Of course not, I want 3% for the same budget and finish date.”

The PM says, “That’s not possible, sir. We could improve to 4% for much less. Is that of interest? ”

The sponsor demands, “You will deliver 3% for the same budget and finish date, or you will be looking for a job.”

The PM shakes his head sadly and says, “No one could pull off that miracle. So you’d better fire me now.”

The sponsor storms out.

The project manager handled this correctly, refusing to commit to a result he could not deliver but offering two results which he could deliver.

Work Breakdown Schedule: Deliverables

The work breakdown schedule also shows the executives how the project team is going to deliver the result. The project manager and sponsor decompose the overall scope deliverable into 4 to 7 high-level deliverables. They also define each of those with measured acceptance criteria. Those deliverables are the best way to communicate how the project team will deliver the results defined by the scope. It also gives executives unambiguous checkpoints to measure the progress of the project after work begins. The project manager will also decompose the work breakdown schedule down to the level of individual assignmecomm21nts for the project team members.

Those lower level measured deliverables are the foundation for assigning work to the team members and tracking progress. You should define each task in the work breakdown schedule with a metric and link it to the scope through a network of deliverables. As stated above, you create that network by decomposing the scope into 4 – 7 high-level deliverables.  You continue to decompose the high-level deliverables into smaller deliverables, down to the level of deliverables that an individual will be accountable for producing. A work breakdown schedule developed this way gives the project sponsor, stakeholders and the project manager objectively defined checkpoints against which to measure progress. That is a powerful tool for keeping the project on track and for communicating to everyone that you, the project manager, know what’s going on. Using this technique, you can avoid the difficulties with defining and tracking team member assignments when the work breakdown schedule is merely a “to do” list.

Work Breakdown Schedule: Team Member Assignments and Estimates

If you do the work breakdown schedule correctly, every team member can look at it and know what a good job on their assignment is before they start work. The work breakdown schedule will also tell them how you will evaluate their deliverable when they finish producing it. Because your expectations are clear, a good work breakdown schedule is an excellent tool for developing accurate estimates with the project team members. That’s because they have less need to pad their estimates since the assignment is very clear. Team members pad their estimates because they are accustomed to receiving vague project assignments that change frequently. The usual process of making changes to their vague assignments doesn’t allow the team member to accurately estimate the required work and duration. So the team member prudently protects themselves by inflating the estimates they provide the project manager.

When the project manager develops a work breakdown schedule with measured deliverables, the problem of padding estimates largely goes away. That is particularly true if the project manager uses work packages and makes an agreement with the team members that when their assignment changes, the PM will reexamine their time and duration estimates. That sounds very simple but operating that way gives team members lots of confidence in the commitment process so the project manager gets better estimates from the team members.  Additionally,the work breakdown schedule is the tool the project manager uses to identify the skill set of the people they should assign to each of the entries in the WBS. Work Packages main page

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

Work Breakdown Structure Size

People have questions about the best size for the project work breakdown structure (WBS). The answer depends on the capabilities of the project team and the complexity of the project. That’s because those two issues affect the size of the assignments for the project team members.  The WBS for a very inexperienced project team will lean toward relatively small assignments (2-5 days) and results in a larger work breakdown structure. The other extreme is a project team of experienced professionals who are expert in their tasks. To avoid micromanaging these experts, you would make relatively large assignments (7-21 days) and, thus, have a much smaller work breakdown structure. Main WBS Work Breakdown Structure Page

WBS Work Breakdown Structure

WBS Size Factor #1: Team Member Experience

In most projects, you’ll have a mix of your team members’ experience levels. So you will be designing assignments that range from a day or two for a rookie team member to several weeks for an experienced team member. You’ll also change the size of the assignments based on each team member’s performance. For example, let’s say a person whom you initially assessed as a rookie does very well and consistently produces high-quality deliverables on time. As a result of their performance, you may expand the size of their assignments to give them more freedom and decision-making latitude. You will spend less time evaluating their work because with bigger assignments they are producing deliverables less frequently.  Many people working on project teams value the expansion of their decision-making freedom with larger assignments. That is a great performance reward.

If you’re following project management best practices, you’re going to be getting status reports from each of your team members on a weekly basis. The size of their assignment doesn’t matter here.  When you give someone a large assignment, they’re still reporting on it every week. So you aren’t “in the dark” about the status of their assignment for weeks at a time.

WBS Size Factor #2: Project Deliverables

The WBS size doesn’t affect the production of project deliverables. You may choose to alter an assignment if the project stakeholders are particularly interested in inspecting one or more of an assignment’s deliverables. However, there are some very important things to avoid in terms of outside influences on the size of your work breakdown structure.

Some project sponsors are wrongly convinced that a big work breakdown structure will give them tight control over the project. This is incorrect on many levels. First, an enormous work breakdown structure takes many hours to update every week. It’s harder to get your team members to give you good status data when they have to report on 10 or 12 micro-tasks. It also takes you longer to enter data and update the schedule with actuals. The typical consequence of a monster-sized work breakdown structure is that the project manager can’t keep up and eventually the schedule is not updated every week. That is the same as not having a schedule.

The other consequence of a very large and very detailed work breakdown structure is it makes your project team members feel they are being micromanaged. They think you and the sponsor don’t trust them to make decisions and are constantly looking over their shoulders. If you’ve ever been micromanaged by someone who knows less about your task than you do, you realize how destructive micromanagement is. You wind up with a project team that takes no responsibility for the results they produce. They simply follow the micro-details in the work breakdown structure. You need to explain this to a project sponsor who wants a very detailed work breakdown structure because the negative consequences are serious.

More information on our lean project methodology

PMP® Certification Training

How to Qualify for the PMP® Exam

The PMP certification requires that you:

  • Document 4-5 years of PM experience with references
  • Show you have passed a  project management course
  • Pass a 4-hour multiple choice exam.

The PMP® (Project Management Professional) is awarded by the Project Management Institute (PMI) and is an internationally recognized credential in project management. It is a door-opener when you hunt for a new job anywhere in the world. It’s also a very good credibility builder within your organization. 

The PMP certification exam is a 4 hour, 200 question multiple-choice exam. The test is exceedingly difficult and PMI reports that approximately half the people who take it worldwide fail. Taking a formal PMP exam preparation course where you learn all the best practices in project management is the best way to pass the exam and is useful for your career.

How Do I Pass The PMP Exam?

The challenge in the PMP exam comes in two areas. First, you need to forget how you manage projects in the real world and learn to answer the questions according to PMI’s way of doing things.  Second, you must understand all the best practices in project management and when to use them. You can’t pass the exam just by memorizing that information. You need to know when to apply a certain technique based on the situation you are given. A very large proportion of the questions on the exam are situational questions.  They are lengthy questions that detail the situation of a project.  That situation is defined by one or more of the following:

  • what sort of organization you’re working in
  • what kind of project you’re working on
  • what sort of project team you have
  • what project process or output you have just completed
  • many other variables

After reading the situation, you must choose from four multiple choice answers.  Each of those answers may be correct to some degree.  So you have to decide which is the most correct answer in the particular context of the question. This is enormously challenging because you have a very large body of knowledge you have to learn. Then you have to be able to decide what to do in a very complicated set of situations.

Multi-media Learning

You need to select the correct learning methodology for you to master all of the information you need to pass the PMP exam. You need to learn about the various contexts, including organizational types and the impact each organization type has on the challenges a project manager faces. That context includes the best techniques to use in the project situation, the environment  in which it is taking place, and where the project managers and stakeholders are in the project management process.  You can’t learn the correct interplay between those elements just by memorizing.

The best way to learn all this information and how to apply it in situations is our PMP Exam Prep course. You’ll have study materials that actually give you scenarios of project  managers executing various projects. As you read these scenarios, you see the logic the project manager uses to pick the appropriate technique. You’ll also read about the explanations the project manager gives to project sponsors and stakeholders about the risk management or estimating techniques the PM decided to use. By learning how project managers operate in these different situations, you will learn to interpret a situation and pick the right techniques when you answer a question on the exam.

Our PMP prep course gives you a multimedia learning experience. You aren’t just reading and rereading the same dictionary over. Instead you are learning the material in a multimedia sequence:

  • first you read about a process and its inputs and outputs
  •  then you watch a video lecture about the correct way  to execute that process
  •  you have an opportunity to talk with your instructor (via video conference) about the process and its techniques
  •  then you watch a video of a project manager actually doing the particular process with the sponsor and project team.

That this multimedia learning helps you gain the knowledge much more effectively. It is also a much more pleasant learning experience. You also add to your personal tool set and understanding of which techniques to use and when. That is invaluable for succeeding and advancing your project manager career.

Our PMP exam prep gives you the best passing guarantee available.  Your instructor will  continue to work with you  if you fail the exam after completing your course in its entirety. We also give you  the maximum flexibility in scheduling the course because you’re not tied to a rigid schedule set by the instructor. You set your own schedule and your instructor adapts to it.  You may wish to take advantage of our free instructor assessment which will help you decide if the PMP training and certification are right for you.

PMP® Certification Training Summary

The PMP exam is exceedingly difficult to pass. The experience and education requirements are enforced with random audits of candidates’ applications. The combination of those requirements and passing the 4 hour exam is what makes the PMP credential so valuable as a job-hunting tool. It’s also the reason that many organizations use the PMP credential as a screening tool when they are recruiting for project managers. People without the PMP are simply not considered for those positions.

Work Packages for Clear Assignments & Estimates

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

A key success factor for project managers is making crystal-clear assignments to their project team members. This ensures the team members understand what’s expected before they start work.

As importantly, clear assignments lead to accurate estimates for their tasks. This ensures the overall project estimates are accurate. It’s important for team members to be committed to those estimates and have some “skin in the game” in terms of hitting their work and duration numbers.  You get all these benefits by using a work package for each assignment.

Work Packages Store Data for Future Projects

Project managers need a vehicle to capture and store historical data on each project. So when you or other project managers have similar tasks on new projects, you can look at the actual assignments in the work packages from completed projects. You can use some of that data for the current project’s tasks. You should be able to retrieve the estimated hours versus the hours actually used and apply that information to the analogous estimates on your project. The use of the project work package addresses several success factors.

The project work package is a simple tool that improves the clarity of project assignments. At the same time, it increases the level of team member commitment to their estimates. In a very real sense, the work package is the contract between you, the project manager, and the project team member. In it, you make clear exactly what you expect of the team member on each task. The work package details the metric you will use to measure the assignment as well as the approach the team member should take to complete it. It also details the input deliverable(s) the team member needs to start their work. Additionally, it specifies the output deliverable(s) which are the things other team members need from this assignment before they can start their work. The work package also allows you and the team member to discuss risks and how to handle them. It is a very important part of the estimating process.

Learn How to Use Project Work Packages

You need to work with your team members to introduce the project work package. Be careful that it’s not viewed as “just another form to fill out.” You want to talk with them about it as a contract or agreement that the two of you will use on the project. It does the following:

  • defines an assignment
  • states their availability to work on the assignment
  • includes their estimate of work and duration.

You should point out that it offers them protection against changes to their assignments that don’t include adjustments to the work and duration estimates. You may honestly explain that the work package is a device to reduce the padding of estimates. That’s because it offers the team member protection against unfair changes to the scope of their work assignment. If the scope of their assignment changes, the two of you can can discuss a change to their work package.

It will take one or two projects for the team members to become accustomed to using work packages but the benefits are substantial. They are helpful on the current and future projects.  The project manager can review completed work packages to use as the basis for estimates on future projects.

[ctct form=”28721″]

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 Failure

project failure

project failure
Dick Billows, PMP

Why Projects Fail

Some organizations have project failure rates at 70% or above. In others, they are always late on promises made to customers. In still other cases, they can’t deliver new products and services that allow them to successfully compete.  Enterprise Project Management Hub

Most Organizations Have a 70% Project Failure Rat

Project success = produce planned deliverables, within budget and on time (including approved changes)

Using this definition of success, we find that most organizations have 70% project failure rates.  That project failure rate wastes so much money and human resources that even a small increase in the success rate is worth a lot. But the solution is not easy. Poor performance causes high project failure.  The poor performance is at three levels in the organization: executives, project managers and team members.  To cut the rate of failure, project managers must coach both the executives (subtly) and their team members (directly) about their roles and expected performance.  And implementation of a project process in the organization is vital to reducing the project failure rate to under 20%.

How To Avoid Project Failure: Executive’s Role

Executives set clear measurable(numeric) objectives for projects. They ensure all projects they allow to proceed yield business value and they allocate resources based on that value. Most executives fail at their project role and this contributes to project failure.  Here is an example of how they usually operate.

An executive calls two subordinate managers into a meeting and says, “We have a mess in customer service and we have to fix it. This has to be priority #1.  Drop everything else and clean up the mess. Install new systems and procedures and whatever else we need for World Class Customer Service!  In fact, we’ll call it that – the WCCS Project.”

One of the managers says, “Didn’t we do that last year?  I mean the acronym we used was different but this project sounds familiar.”

The other manager says, “You’re right.  In fact we’ve done this 3 times since I’ve been here.”

The executive snaps back, “Yes, and each earlier attempt failed.  Let’s do it right this time.”

The two managers exchange pained looks as the executive goes on, “Now, I have two other ideas for projects to cut costs and improve service. So here is what I want…”

The first manager interrupts with a groan, “You always have great ideas, boss, but our plates are full.  Our first-line supervisors are already spending half their time on projects and their real jobs are suffering.  The engineering and technical staffs are all working 70 hour weeks.  Something has to give.”

The executive frowns and says, “I know what’s going on down there and there’s plenty of time to squeeze in a few more projects.  Your people just have to work smarter not harder!”

Instead of giving the project managers a clear unambiguous objective, the executive gave them mission statement mush of World Class Customer Service. There was no assessment of the project’s business value. Additionally, he refused to tackle the politically difficult task of setting project priorities for allocating the limited human resources. Project Rescue

How To Avoid Project Failure: Project Manager’s Role

Project managers conceive, manage and control projects. They use best practice techniques to ensure the projects deliver their planned outcomes efficiently. Many project managers also fail in their role and contribute to project failure. Here is an example of how they operate.

A newly promoted project manager enters the cubicle of an experienced project manager and says, “I’m really nervous about my new project.  The way my director was talking this morning, the world may end if this project fails.  My boss said this is priority number one!  I’m gonna tell my family not to expect me to leave work on time for the next six months.  I’m worried that I’ll be in real trouble if I don’t bring it in on time and within budget.”

The experienced project manager laughs and says, “You’ll laugh too after you’ve heard that speech about 50 times.  On the first day they all talk loud and long about how important the project is.  But when you ask them to spend an hour or two planning this critically important project, they’re too busy.  When you ask them to make sure the project team members from other departments actually show up to work on your projects, they’re too busy for that too.”

The rookie relaxes and says, “Okay, you’ve been there and I haven’t.  I’ll take your advice. Can you tell me how the company wants project plans and schedules put together?”

The experienced project manager chuckles again and says, “We have no standard methodology.  Every project manager in the company just wings it.  You can’t possibly put together a plan when executives make you start work before they decide what they want.  When you try to define the scope or even ask what the project is supposed to produce, you usually get a long speech about how we need to react quickly and stay flexible.  The best thing to do is write down what they want you to do first and do it.  Then go back and ask them what they want you and the team to do next.  They want to micromanage everybody anyway. There’s no sense creating a lot of plans and schedules – they’re always a joke.”

The rookie gasps and says, “You’ve got to be kidding.  This is a successful organization.  How can we be successful without project plans and schedules?”

The experienced project manager smiles and replies, “I’ll help you with that. I’ve got a bunch of old project plans and some really big work breakdown structures you can use to copy and paste.  If anyone asks, you’ll have a really big plan and a highly detailed work breakdown structure that no one will ever look at anyway. But you won’t be responsible for project failure.”

Instead of the project managers pushing for the use of best practices, they act like order-takers at a drive thru restaurant. They give little thought or energy to planning or how to avoid problems before they occur.

How To Avoid Project Failure: Project Team Members’ Role

Team members make accurate estimates of the work and time. They report status accurately so problems are identified early. Many team members fail in this role and contribute to project failure.  Here’s an example of  how they operate.

Two technical professionals with heavy project workloads meet at a table in the company cafeteria.  The first technical professional, who is new to the company, grumbles, “They gave me three new project assignments this morning. I was afraid to say anything but there is no way I can get them all done by the due dates. It is more work than three people could do.”

The second technical professional laughs, “They’re always starting new projects and if you try to do all of them on time, you’ll kill yourself for nothing. Just pad the estimates by 50 or 60% so the project manager can’t blame you for the project failure. There are so many half-done projects floating around that no one remembers them all.  My rule is that if no one has talked about a project in the past month, I don’t do any work on it.”

The first professional replies, “But when we start these projects, the boss says I am committed to the estimates and completion dates. That’s exactly what he did on some projects two weeks ago.”

The second professional laughs again, “Oh yes, you’re committed.  Has the boss asked you about any of those older projects recently?”

“Well no.”

“Then they’re dead ducks.  Work on the projects people are screaming about.”

“But I’ve put dozens of hours into some of those old projects,” complains the first technical professional.  “Does the organization want me to just throw that time away?”

Shaking his head, the second technical professional replies, “I think we waste about a third of our time on projects we never finish. And we have high project failure rates on the ones we do complete. That’s why you shouldn’t get excited about flushing another one that’s headed down the drain.”

Instead of making accurate estimates of the amount of work and time required, project team members focus on avoiding blame.

How To Avoid Project Failure Summary

Organizations that consistently succeed with projects perform well at every level in the project management process:

  • They control the initiation of projects; planning, approving and monitoring projects based on the business value those projects produce.
  • They manage the pool of project resources just as they manage their capital budgets; allocating people’s time and money to projects based on the project’s payback.
  • They follow a consistent methodology for all projects; holding people accountable for measurable achievements.

To learn a complete methodology for project success in our private online training.

[ctct form=”28721″]

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.

[ctct form=”28721″]

Emergency Projects

Dick Billows, PMP

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

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

What if people/property are in danger!

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

Marketing/Operational Emergency 

Another type of emergency is affects the organization’s:

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

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

Recovery Project Scope

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

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

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

Crisis Planning

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

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

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

Project Portfolios: Managing Multiple Projects

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

As projects multiply in an organization, the number of people on more that one project increases and project performance declines because:

  1. Projects compete for scarce resources
  2. Anyone can start a project on a whim
  3. The organization starts more project than it can finish so it wastes significant work hours on canceled projects
  4. No business value criteria exist for new projects
  5. No priorities exist for using resources 
  6. No consistent tracking of progress exists.

Portfolio Management Process

Organizations can solve these problem by making someone accountable for managing the portfolio of projects. That individual will start the project portfolio process by:

  1. Defining a Project Protocol. This tells everyone how to originate, plan, schedule, budget, track and close out a project. The heart of the protocol is that work estimates are made for each task in the approved projects.  This enables the organization to track actual progress.  The protocol doesn’t need to be more than one page long. Project managers will be trained in this simple methodology for doing all projects.
  2. Securing executive approval of a process for Initiating Projects.  The portfolio manager assesses each new project by comparing the business value the project will produce to the time and money it will consume.  The executive committee considers the portfolio manager’s recommendations and approves certain of the projects. It’s best if the organization sets a project initiation standard so people know what criteria their projects must meet.
  3. Setting priorities using the project initiation data on approved projects. The management committee reviews the portfolio manager’s slotting of projects into priority tiers.  It is our experience that 7 tiers of projects works best. And no tier should utilize more than 15% of the organization’s resources that are available for projects.  The organization also needs to reserve 15-20% of the resources for emergencies.
  4. Scheduling projects by priority tier.  Projects in the first tier get their resources first and can start work immediately.  Lower ranking projects have to wait for their resources. Projects in the bottom priority tiers may not start this year.
  5. Tracking progress weekly.  The portfolio manager and the people assisting him can compare actual progress to the plan and take corrective action. They can also report to the management committee on problem projects.
      1.  

Training for Portfolio Managers

The portfolio manager role is difficult. He or she must allocate resources across all the projects in the  portfolio they manage. They must deal with executive sponsors and stakeholders frequently. They must try to enforce effective organization-wide processes for managing multiple projects and programs. And that is a significant challenge.  Here is the training we provide for portfolio managers:

Managing multiple projects

The technical skills of portfolio management, setting priorities and allocating resources are straight-forward and rather simple. What’s not simple is handling the politics of managing multiple stakeholders with conflicting interests and priorities. Many newly promoted program and portfolio managers think all they need to succeed is the power of the CEO behind them. However, they soon find out that the senior executive, while backing the idea of doing projects the right way, will not overrule the executives that the program or portfolio manager deals with every day.

Far from using their power to force compliance with the program or portfolio manager’s proposals and processes, the CEO will want them to “work it out” with the executive stakeholders. Thus, managing multiple projects takes program and portfolio managers into the world of political maneuvering, horse-trading and deal-making. They must join in the political deal-making and coalition-building or the executives will quickly ignore them. They will consider the program and portfolio managers irrelevant to the issues and challenges these executives face.