Here the project management Certification options for beginners, experienced pros and program managers
There are a wide range of project management certification options to propel your project manager career. They can lead you to the upper levels of project, program and portfolio management.
If you have some experience and have earned your first project management certification, it’s easier to get a job in project management. Your first certification could be in a specific industry or in a functional specialty. Those project management certification programs give you basic skills for small projects. Then you can build on them by adding advanced techniques in estimating, risk management, planning with executives, tracking and status reporting. The better programs also give you training and practice in making effective presentations, leading meetings and communicating clearly with stakeholders and your team members. The Project Management Institute (PMI) offers two certifications. The PMP (Project Management Professional) is for experienced PMs. Our PMP Exam Prep course prepares you to pass that exam. The CAPM (Certified Associate in Project Management) is for people who are new to project management.
4PM.com offers project management certifications in the following specialties: IT Project Management Certification In addition to basic and advanced project management tools and techniques, this program gives you the skills to use different systems development methodologies, like Agile and Waterfall, and how to elect the correct one for each project. They also teach you how to manage the users’ expectations and your team members’ performance.
Construction Project Management Certification In addition to the basic and advanced project management tools and skills, this program places special emphasis on accurate estimating, building customer/owner relationships and the intricacies of dealing with subcontractors on your project. You learn how to manage risks and change orders which are critical elements in construction project profitability.
Healthcare Project Management Certification In addition to the basic and advanced techniques and tools, this program gives you the tools to effectively deal with the unique organizational issues in the healthcare environment. You learn how to work with both the administrative departments and the medical staff of a healthcare institution. You will be able to build effective teams across those functional lines.
Business Project Management Certification In addition to the basic and advanced project management tools, this program teaches you how to integrate people from different functional areas into a high-performing project team. You learn how to build project plans and effective teams that include the efforts of information systems, marketing, sales and operations. Each of these areas has a unique perspective on projects.
Client/Consulting Project Management Certification This certification teaches you basic and advanced project management techniques as well as how to “sell” engagements to clients, manage their expectations and finish projects on time. Delivering those results earns a profit for your firm and creates a satisfied customer. You learn how to handle change orders profitably and develop a mutually beneficial relationship clients.
These certifications are valuable credibility-builders within your organization and help you stand out from the crowd when seeking a new project manager position.
Regardless of its size, you always have to sell the benefits of the risk management plan to the sponsor and stakeholders. But they’ll often be hostile. That’s because they aren’t convinced that spending money on risk management improves the odds of finishing on time and within budget. They may see risk management as a waste of time and money. Risk Management Main Page
You should never start your risk management presentation by boring your audience with the list of 63 negative risks that could adversely affect the project and 27 positive risks that could let you finish earlier and spend less money. You also shouldn’t present the results of your qualitative or quantitative risk analysis; no matter how proud you are of them. That type of presentation will only convince your audience that you have wasted both time and money.
Risk Management Plan Presentation: How To Do It
In the first 60 seconds of your presentation, you should acquaint your audience with one or two significant risks and the impact those risks could have on the project. Let’s take a simple project and see how you might start the presentation.
“Good afternoon. I’m here to talk with you about our supply room project. The goal is to reduce the number of complaints from our employees. Last year, we averaged 53 complaints per month. Our goal is to reduce it to less than 3 per month. The major deliverables that will lead to achieving that goal are:
First, that 95% of the time employees can find the supplies they need in less than 60 seconds.
And second, that fewer than 3 items each month are out of stock.
We see two problems that could make it difficult or impossible for us to deliver that goal. The first problem is that the people who stock the supply room will not use the new, more efficient design which we will produce during the course of the project. We need an incentive so they don’t return to their old habits and recreate the same mess we have today. To avoid that problem, we would like to add a performance criteria to their job descriptions and annual performance reviews. It will require people to maintain the supply room design by restocking supplies in the specified locations.
The second problem is that employees will not know where to look for the supplies they need. If that happens, the complaints about the new design may be higher than the current complaint rate. To avoid that problem, our design will place the most frequently needed supplies (those that account for 80% of the withdrawals) near the supply room entry. We will also print and distribute a supply room crib sheet and map to all employees. We will also have a large-scale copy of the crib sheet and map on the supply room door.
If you approve this risk management plan, I believe we can completely avoid both problems.”
Taking this simple and direct approach to presenting your risk management plan is almost always more successful than a presentation that drowns your audience in data or complex statistics. Instead of all the numbers, you discuss the problems, the consequences and your remedy. Plus you do it in just a few minutes.
If you want to enhance your presentation skills, consider our online Presentation and Negotiation Skills course. You work individually with your instructor at your pace. They’ll coach you with techniques for improving the content and media of your presentations as well as your speech and body language.
Project trade-offs are the best technique to use when you’re dealing with executives who want to make changes to the plan. Knowledgeable project executives understand the concept of balances or trade-offs when they want to add or delete something. They know that if they ask you to squeeze the duration by one month it will affect the scope, cost or risk. Those are the 4-corners of a project.
Unfortunately, some executives think they can shorten the duration of the project by a month without impacting the other three corners. In this project fantasyland, they believe they can increase the scope and the deliverables without affecting the duration (schedule), cost or risk. They think any changes they want to make to the project are “free.”
Project managers who allow project executives to live in this fantasy world are doomed to repeated project failures. Once you give the executive free changes to the project, he will keep requesting (or demanding) more changes.
Using the 4-Corners
Skilled project managers always talk to executives about trade-offs between the project’s 4-corners: scope, duration, cost and risk. They make the point that there are no “free lunch” changes. Every change to the project impacts the other corners and requires a trade-off. But tactically, the PMs never say “no” to a change. That never gets them anywhere. What they say is, “Yes, I can change the schedule to finish two weeks earlier. But that will increase the project cost by $14,000 to pay for overtime and hiring several consultants. Do you want to do that, sir? Do you want to trade off a two week earlier finish for a $14,000 increase in the budget?”
Project managers should talk trade-offs with executives during the initial planning and in the approval presentation. They should continue this discussion every week when change requests are submitted and as variances appear.
They also always have the data on the 4-corners and always carry an iPad or small PC so they can generate tradeoff data in a minute or two from their MS Project schedule. You need to quantify the scope, budget, rick and duration.
We teach this tradeoff technique in all our beginner and more advanced approach in our advanced classes. You can also read more on quantifying the 4-corners in our articles of risk management, scope definition, budgeting and scheduling.
Project scheduling is not about developing and printing a schedule and then hanging it on the wall. Good project managers use their dynamic schedules daily to model options, assess alternatives and forecast completion dates and costs. Here’s how a project manager who is a good scheduler operates:
A stakeholder stops the project manager at the entrance to the cafeteria and says. “Sorry but I have some bad news for you.”
While listening, the project manager flips open his portable PC and opens the project to which this stakeholder is lending people.
The PM asks, “Oh, what’s happened?” while scrolling to a list of the tasks to which this executive’s people are assigned.
The stakeholder replies, “I have to pull those three engineers off your project to work on something the Marketing VP dumped in my lap. I need them for 4 weeks.”
The PM scrolls down the list, finds the three engineers, changes their availability for the next 4 weeks to zero and clicks enter. On the screen Gantt chart a lot bars turn red and shift to the right (later finishes). The PM says, “As long as you’re talking to the Marketing VP about removing the three engineers from this projects, you can tell her that her tracking system will be 6 weeks latter than currently scheduled.”
“Oh no,” the stakeholder moans.
“That’s the consequence,” the PM replies. “I’ll tell engineering and accounting about the delays this causes on their deliverables. You may hear from them.”
The stakeholder says, “Wait awhile before you do that. Let me see if there is another way.”
The PM smiles.
Dynamic Project Scheduling Techniques
Successful project managers use dynamic project scheduling because it saves them significant amounts of time. It also lets them quickly model the impact of changes to resources, work or costs. Dynamic scheduling automatically recalculates the duration and budget for the project every time you make a change in the resources, hourly rates, hours of work and predecessor relationships.
Many commercial project scheduling software products allow for dynamic scheduling. Here are the critical elements required for the dynamic schedule to work.
Dynamic Project Scheduling Element #1: Predecessors
Your dynamic project schedule must not be based on fixed start and finish dates. It must be based on predecessor relationships between tasks. There are three primary kinds of predecessor relationships and the entire schedule must be built on these relationships.
First is the finish-to-start predecessor relationship between tasks A and B. That tells the software that task B can’t start until task A has finished.
Second is the start-to-start predecessor relationship between tasks A and B. That tells the software that tasks A and B can start at the same time.
Third is the finish-to-finish predecessor relationship between tasks A and B. That tells the software that tasks A and B must finish at the same time, even though they may not start at the same time.
Dynamic Project Scheduling Element #2: Work Durations
Your schedule must be based on work durations that are calculated from resource availability and work estimates. You enter the amount of work required for a task and the availability of the resource assigned to the task. Availability is how many hours a day each resource can work on their task. As an example, say there is 80 hours of work for a team member who works on the project half-time, or four hours a day. The dynamic project scheduling software calculates the task’s duration as 20 working days. That’s because the half-time team member can only complete four hours of work a day.
Dynamic Project Scheduling Element #3: Track Work & Duration
You use dynamic project scheduling with predecessor relationships and work estimates to track progress on the tasks in your project plan. As an example, you may specify a finish-to-finish predecessor relationship. That tells the project management software that you want to schedule two tasks and their resources so both tasks finish at the same time. When you specify all your predecessor relationships, your project plan becomes a network of tasks, linked by the predecessor relationships. The result is often called a PERT (Program Evaluation and Review Technique) chart. It displays your project plan and its network of tasks.
You link each task bar to the project network. That allows our dynamic project scheduling to control the sequencing of tasks based on the predecessor relationships and the amount of work in each task. It also gives you early warning on problems. When a task is completed late, the software shows the revised completion date(s) of that task’s successor tasks. You have an opportunity to correct a situation that can impact the entire project’s schedule.
You can learn how to use dynamic project scheduling in our online project management courses. You work one-to-one with your instructor at your pace and as your schedule allows.
Watch this video about “how to” and “how not to” make team assignments. We show you what the initial meeting with a team member should deliver. Next we’ll discuss an example of how not to make a team member assignment. Finally, we’ll talk about the right way to make team assignments.
Your First Meeting with a New Team Member
The goal of this example project is to improve the quality of the applicants that Human Resources refers to line managers for job interviews. The project manager asks one of the team members to stop by his cubicle to discuss the project. He is a bit uncertain about how to start the project. He asks the team member to interview all 65 of the company’s first level supervisors about the quality of the job applicants Human Resources is sending them for job interviews. Leading Teams Main Page
Team Assignment: Round 1
The team member returns to the project manager’s cubicle a week later and says, “I finished the last of the 64 interviews this morning. One of the supervisors is in the hospital so I couldn’t interview her.”
The PM says, “Good work. Tell me about the results of the interviews.”
The team member replies, “The hiring supervisors are very unhappy with the quality of the applicants referred by the Human Resources department. 70% of them rate the applicants as poor or unsatisfactory in terms of meeting the job specifications. Only 10% rate the applicants as excellent. We certainly have a problem to solve here.”
The project manager responds, “That’s not what I wanted. I want to know specifically what is wrong with the applicants the HR department sends them to interview. Please go get me the information I want.”
The team member nods at the project manager, turns and walks out, thinking to himself, “If you wanted data about what was wrong with the applicants, you should’ve told me that.”
Team Assignment: Round 2
With a marked lack of enthusiasm, the team member proceeds to again interview the 65 hiring supervisors (the last one was home from the hospital). The supervisors are unhappy with the team member because they feel they’ve contributed enough time to the project. Several remark to him, “You really should decide what you need before you waste people’s time.” The team member says nothing but nods agreement.
Seven days later the team member returns to the project manager’s cubicle. The project manager sternly asks, “Did you get the assignment right this time?”
The team member drops a 1 inch thick report on the project manager’s desk and says, “You asked me to find out what was wrong with the applicants and I have done that. Here are all the flaws of the 76 applicants that the HR department has sent to hiring supervisors in the past year. There are 1,576 things wrong with those applicants.”
The PM rises to his feet, snapping, “This is useless! We can’t correct all the problems on this enormous list. I need to know the top 10 things that are wrong with the applicants. I can’t believe you didn’t understand that when we last talked. You should be able to figure these things out for yourself. But if you can’t, you are responsible for asking questions until you’re clear about your assignment.”
Team Assignment: Round 3
Without saying a word, the team member walks out and begins another round of interviews with the same supervisors. The team member’s lack of enthusiasm is now even worse than that of the supervisors. Also, the team member’s attention to detail is far below his usual work standard. As a result, the data gathered is incomplete and full of errors.
Team Assignment: Who Is At Fault?
Without question, the project manager did a miserable job defining this team member’s assignment. The team member followed the PM’s instructions correctly. In each of the cycles through this stupidity, the team member did what the project manager told him to do. And that is the heart of the problem. The project manager was telling the team member what to do but he didn’t tell the team member the result he wanted the assignment to deliver. If the PM had said, “Identify 10 categories of flaws with the job applicants that Human Resources sends to our supervisors,” the team member would have understood what the PM wanted him to produce. He would have delivered the desired result the first time. But the project manager did not specify the deliverable he wanted. What he told the team member to do was insufficient.
Too often, project managers don’t think about exactly what they want the product of the team member’s assignment to be. It’s much easier to just give the team member a “To Do” list and hope they get the assignment right. If they don’t, the project manager blames the team member rather than himself. When you, as the project manager don’t give your team members a clear and measurable deliverable for their assignment, you make the team members much less effective than they could be. When people have to guess about what a “good job” is, their work effort will be less focused than it could be. Additionally, if members of your project management team are uncertain about your expectations, they will naturally protect themselves by padding their estimates of the work’s cost and duration. They expect your unclear expectations to change and they want to avoid the blame when things turn out badly.
Team Assignment: The Right Way
Consistently successful project managers always define clear performance expectations for team member assignments for every deliverable. If you want to be successful, you need to set a measurable performance expectation for every assignment you give your team members. As work progresses on the team members’ deliverables, you can compare what is being produced to the original, measurable assignment. This allows you to spot and resolve problems early so your projects finish on time and within budget. And it lets your team members feel proud about doing a good job on their assignments. That builds team morale.
Learn how to make clear team member assignments in our online project management basics courses. You’ll work privately with a expert project manager. You control the schedule and pace and have as many phone calls and live video conferences as you wish.
Estimating is tricky for project managers who have to balance conflicting pressures from the sponsor, stakeholders and their team:
The customer or user wants the project done quickly and cheaply.
You, as PM, want to finish on time and within budget.
For commitment, the team needs to participate in a process their perceive as fair and not feel like they are sure to fail because their estimate is impossible.
The estimating technique should yield accurate numbers and some assessment of the accuracy.
Decision makers need information of the certainty of the project finishing on time
That list of requirements is a tough one for any project estimating process. The only process that meets all those requirements is 3-point estimating, which formerly called PERT (Program Evaluation and Review Technique).
Briefly, 3-point estimating has three-steps. In each, the PM works closely with the people who will be doing the work. The first step is to discuss the deliverable the team member will be accountable for producing. This discussion includes the “good” risks that could cause this task to take less work and the “bad” risks that could cause it to take more work. Second, the PM notes these risks on the work package form that also contains the approach the team member will use. Third, the team member makes three estimates: an optimistic estimate, a pessimistic estimate and a best guess estimate. The PM applies the 3-point formulas (at the end of the article) to those three estimates to come up with the actual data that you will use in the project schedule.
Common Estimating & Risk Issues
Two mindsets often plague the estimating process:
Executives often believe that projects have no risks that affect duration or budget.
Team members think that padding their estimates will protect them from blame.
Both of these mindsets are false but they certainly get in the way of accurate estimating.
The 3-point estimating technique deals with both these mindsets. It gives PMs a data to communicate the risk of a work estimate. It also lets everyone stop pretending that task #135 is going to finish in precisely 15 days or that the project will absolutely finish by August 30. Three-point estimating is a straightforward process for developing estimates using just a little bit of statistics. It gives you a tool to address the issue that most projects are launched with less than a 35 % chance of finishing by their promised due date. Because no one talks about that issue, executives think the completion date is 100% guaranteed. It’s only missed when someone goofs off.
The best project managers have risk data for their sponsors. They can document why a project has a 65% chance of finishing by August 30, as an example. These PMs also explain what they can do to increase those odds to 75% or 90% and what it will cost. Those same PMs manage the assignments of their project team members with an understanding that there is risk on each assignment. They use 3-point estimating techniques to get data on the risks.
Three Point Estimating in Detail
The 3-point estimating process starts with a discussion with the team member about the risks inherent in their assignment. You discuss the bad risks that will make their assignment take more work and duration (time). You also discuss the good risks that will cause it to take less work and duration (time). Why should you do this step? Because you need an estimating process that addresses the team member’s legitimate concern that bad things will happen on their assignment and they’ll be blamed for not meeting the completion date. With agreement on the risks in the assignment and work package notes what you will do about them, you go on to the estimates work and duration.
As the name implies, 3-point estimating requires three estimates for each task. That sounds like it will take a lot of work but it takes a matter of minutes. You and the team member develop an optimistic estimate, a pessimistic estimate and a best guess estimate for each task. By developing those three estimates, we get estimates that are more accurate from team members and assess the assignment’s degree of risk and the range of durations.
Before we go on, we need to talk a little bit about risk. When you ask me how long it will take to read this article, I might estimate five minutes. Am I guaranteeing you that no matter what happens I’ll be able to read the whole thing in five minutes? No, what I mean is that 5 minutes is my best guess. That means there is a 50% chance it will take me less than five minutes and a 50% chance it will take me more than five minutes.
However, if you were my project manager asking me for a task estimate, I would be a little hesitant about giving you an estimate in which there was a 50% chance of an overrun. What I would rather give you is an estimate where I’m 90% confident that I can finish in that amount of time or less. As the project manager, you would probably regard that estimate as padded. As the team member, I feel more comfortable with a 90% estimate. Unfortunately, there is no consistency in the amount of padding your team members will use.
You want your team members to leave the estimating process knowing that you considered the fact that things can go wrong on a task assignment. That’s why you identified risks at the beginning of the discussion and documented what you could do about the risks. With that recognition of the risks, we move on to gathering data on the impact those risks could have on the assignment. Using the three estimates enables you to do that. It’s better than having a team member give you a single estimate and play the padding game about how certain that estimate is. The three estimates tell you the variability in the task.
Best Guess, Optimistic and Pessimistic Estimates
Now let’s start the estimating process. Your team member estimates that a task has a best guess estimate of 80 hours of work. That means that 50% of the time it will take more work and 50% of the time it will take less.
Next, the optimistic work estimate is less work than the best guess. The optimistic estimate is low enough that the team member thinks they can get the task done for less than the optimistic estimate only 20% of the time. The task will require more work than the optimistic estimate 80% of the time.
The pessimistic estimate is more work than the best guess. It is not a “disaster” estimate but we want an estimate that’s based on the bad risks that we identified happening. The pessimistic estimate is high enough that the team member thinks they can get the task done for less than the pessimistic estimate 80% of the time. The task will require more work than the pessimistic estimate 20% of the time.
Now let’s dip our toe into the statistics and look at two tasks, Alpha and Beta, and the calculated work estimates we would use at three different level of confidence (* see formulas below).
What we did was take the three estimates and use some simple formulas to calculate the task’s work estimates and calculate the mean and standard deviation. Using standard statistical tables (z-scores from a table of standardized normal deviates); we can take those means and standard deviations and use them to calculate levels of confidence of finishing within the estimate. In other words, for task Alpha we could say that we have a 50% chance of completing the task with less than 54 hours of work. For an 80% confidence level, we would calculate that 69 hours of work would be required. This is the data to use with a client or project sponsor to quantify the cost of higher levels of certainty about a completion date. In the previous example with Alpha, we have to buy an additional 15 hours of work to move from 50% confidence to 80% confidence of getting the task done within the work estimate. The beta is much less risky task than alpha. The mean work estimates are very close but the standard deviations are very different. To move from the 50% level of confidence that is 50 hours on task beta we would need to increase the work estimate to 51 hours. So for task beta higher levels of certainty a relatively inexpensive. Extending these calculations to the entire project is very easy with a spreadsheet such as the one we use in our classes. It gives project managers the ability to discuss the cost of higher levels of certainty. Sponsors always say they want to be 90% confident of finishing on time. When you present them with the cost of that level of certainty, it often is the case that lower levels of confidence would be acceptable.
Using 3-Point Estimates
All of the better project management software packages, such as Microsoft Project®, enable you to use 3-point (PERT) estimates and create a variety of reports that communicate the project’s risks. You can take estimates like those above and calculate the odds of finishing the entire project within various durations. That information is a solid basis for a discussion with the sponsor about the tradeoffs between cost, scope, duration, risk and staffing levels.
To learn these 3-point estimating techniques and the entire estimating process, consider our private, online courses where you work individually with your instructor. They are available by phone, video conference or e-mail whenever you have a question or need help on an assignment. We can also deliver a customized training program at your site for up to 25 people. Call us at 303-596-0000 and speak to an instructor.
*Three point estimating Formulas
Probability level = work= Mean + (z-score for probability)*SD
In the matrix project team, you borrow people from other departments, not from your own. Matrix project teams have always been popular with project managers. They are a way to get resources for your project without paying consulting fees or persuading people in your organization to give up some of their staff. That sounds like a fabulous bargain but managing a matrix team is not easy. There are a number of challenges. Leading Teams Main Page
Acquiring A Matrix Project Team
First, the project manager has no inherent authority to borrow people from other departments. So the project manager asks the sponsor to contact the lending department and use his/her power and authority to secure resources for their project team. That doesn’t always work because the sponsor, no matter how high-ranking in your part of the organization, may be ignored when he/she contacts another department to borrow resources. It’s understandable that the lending departments are not enthusiastic about acting like a resource pool for matrix project teams. They lose time from some of their valuable people and the project doesn’t compensate them for the loss. They often must have other employees work overtime to make up for the hours lost to a matrix project team. Those factors often result in lending managers loaning the person they can most easily afford to lose for a few months.
Second, the borrowed matrix team members can be recalled to their “home” departments whenever there is a need. From the perspective of the lending department manager, the work there will always take priority over work on someone else’s project. So the project manager who borrows matrix resources can lose them in an instant and face immediate project schedule problems.
The third problem with matrix team members is that they earn their raises and promotions in their home department, not on the project. The project manager may have some input into their performance review or may write a complimentary memo or note for their file at project completion, but that doesn’t count for much. Understandably, matrix project team members are often focused on their department’s interests, not on completing challenging project assignments.
Managing A Matrix Project Team
Even if the project manager overcomes the issues we’ve discussed above, they face the very real challenge of managing these borrowed people so they have some level of enthusiasm and commitment to the project goal.
Forget about all the platitudes and well-intended phrases you hear about matrix management. Every person on a matrix team does not carry the same weight or have the same influence. Matrix project teams are often composed of and led by people from a primary organization and supported by resources from “outside” the organization. Some examples include:
mixed government-contractor teams
Project Management Office-led teams supported by engineering, logistics, business office, etc.
primary contractor-led, subcontractor-contributing teams
teams led by “graybeards” and supported by less experienced members.
Total equality within a matrix project team is neither possible nor desirable. A hierarchy of authority is necessary on any project. But one of the PM’s most important “people duties” at the outset of a project is to make every member of the matrix team feel included and that their role is as important as any other. If the PM fails to establish that perception early and clearly, matrix project team members can quickly develop the attitude of project “outsiders.” They feel their contribution is secondary or unimportant to the project manager or even the project itself. They quickly develop the attitude that the project is not worthy of their best effort.
To address this challenge, you should have a project “kickoff” meeting as soon as all your resources have been identified. Although this meeting serves many purposes (e.g., to discuss roles and responsibilities, processes, requirements, etc.), one of its greatest benefits is to give the message that every team member’s contribution is critical to the project’s success. Not establishing an early atmosphere of inclusiveness and investment in achieving the project objective is a lost opportunity with potentially large consequences.
You can learn these team leadership skills in our project management basics courses. You’ll work individually with your instructor at your schedule and pace. Take a look at the course in your specialty.
A key part of a good consulting project plan is the work breakdown structure (WBS). We begin by defining the scope and major deliverables of the project with the client. This is when we start managing the client’s expectations about what the project will deliver. With agreement on the scope and high level deliverables, we decompose or breakdown each of those deliverables into smaller deliverables until we get to the level of an individual assignment that a consultant or client personnel will complete. As we work through the decomposition, we are specifying the end result we want from each assignment. We are not stating what we want the assigned person to do. As an example, we would not try to describe everything that a system contractor must do. Instead, we would specify that the subcontractor is to produce a GUI that the client’s payroll department staff can use to complete the weekly payroll in 5 working hours. That is a deliverable with the crystal-clear acceptance criteria. With every assignment in the consulting project WBS specified as a deliverable with acceptance criteria, we have clearly defined the work assignment for every team member, subcontractor and client personnel working on the project. The assignments or tasks in our WBS define exactly what a good job is for each assignment and how you and the client will measure it. WBS Work Breakdown Structure Main Page
Second, the work breakdown structure or WBS will show the methodology you use on the project to produce the required deliverables. If you and the client have decided to use an agile methodology, the WBS will include multiple iterations in the creation of each deliverable. It would include time for the client to assess the results and change the specifications after each iteration. On the other hand, if you use the classic waterfall project methodology, the WBS would include very detailed front end planning. You complete all the planning before you start work on the project.
Third, the consulting project WBS has to specify the testing and quality control procedures you will use at various checkpoints in the project. Some of the client checkpoints may be the testing of materials. Other checkpoints may be a government or regulatory agency’s comparison of what you have completed to the approved plans. Some testing tasks should include the number of transactions or samples you will test. That ensures you will estimate enough time for the complete testing procedure. That includes any external testing of the deliverables during development or prior to acceptance. They should appear in the WBS so the resulting schedule allows for adequate testing and quality control.
When your success as a project manager leads to larger assignments, you should learn and be ready to use these Large Project Planning Techniques. Planning larger projects requires different techniques than those that are successful fro small projects . When you started your career in project management, the projects were small and planning was relatively easy. So even poor techniques worked. Often the project sponsor was your immediate supervisor and you had frequent conversations about the project’s business result and deliverables. There was only one person to satisfy and the whole team worked for the same boss. All of you received your priorities from the same person. There were no conflicting goals or priorities. These factors contribute to the high success rate on small projects, even if the planning process is weak. Project Planning Main Page
When you move up in the project management ranks, however, planning large project gets more difficult and the consequences are more serious. Now you must know how to use Large Project Planning Techniques. If you try to use your old small project planning techniques on larger more complex projects, management will quickly send you back to the minor leagues.
Large Project Planning Techniques are Different
On larger projects, the sponsor may not be your immediate supervisor. You may be doing the project for an executive with whom you haven’t worked before. In addition, there may be other executives involved whose career success depends on your project. These stakeholders will have goals that differ from the sponsor and the other executives. In fact, your project planning effort may even take place in the midst of turf wars between functional areas or divisions of the company. People may try to use the project and its deliverables as part of their political battle. Worst of all, there may be strong pressure to begin planning and even start work without the decisions about scope and deliverables locked down. That approach is easier for the executives than trying to reach agreement on priorities. It also allows them to get the project started without making any commitments about exactly what they want it to deliver.
However, the project team is the biggest difference between large projects and the small ones you’ve been managing. On small projects, all or most of the team worked for the same boss. On larger projects, you will be borrowing people from other functional departments. Their priorities and your priorities are often starkly different. Additionally, many functional departments loaning people to your project team are really putting an observer on your team to “represent” their department’s interests. These borrowed resources can be a real management challenge. Their managers often pull them off your project whenever they need them for something in their home department. All of those threats may be new to you. Learning how to handle them is required for your continued project management success.
Large Project Planning Technique #1 – Define the Scope and Deliverables
There is a strict rule on larger projects that most PMs learn by suffering the consequences of ignoring it. That is “Never skip defining the scope and major deliverables.” That’s true even if the sponsor or stakeholders spout these phrases:
“We’ll plan as we go”
“Let’s make an exception on this project and start work without a plan”
“You know what you’re doing. We trust you to do it right.”
Ignore all that stuff! You are committing professional suicide if you proceed with setting a completion date and/or budget without objective measures of success. Those measures are the agreed upon acceptance criteria in the project scope. All those greasy executive promises will go up in smoke if you don’t deliver what they want. Remember, without a scope they’ve sign off on, it will be impossible to give them what they want because you don’t know what they.
Large Project Planning Technique #2 – Define the Acceptance Criteria
Next you must secure the sponsor’s and major stakeholders’ written approval of a measurable scope with acceptance criteria. The acceptance criteria define success for the project as a whole and all the major deliverables. Here’s an example. You can’t just start work on the “World-class Customer Service” project. That doesn’t define success criteria for the project. The sponsor and executives must approve (in writing) the success/acceptance criteria for the project scope. What you want is an acceptance criterion like, “Resolve 90% of customers’ issues on their first phone call.” That is objectively measurable. It also tells you what end result is good enough.
How do you get the executives to tell you the acceptance criteria? You have to ask them questions about the end result the project should produce. Often executives have not talked about that end result. In this example, they are reacting to the need to do something about the customer service problem. Therefore, you need to ask leading questions about what they want to see from the project. You don’t want to discuss how to get there. You want to ask questions like, “Six months after this project is done, how will our customers’ experience be different?” If you have some of the data you might say, “Now our customers have to wait on hold for 30 seconds and 60% of them have to call back a second time about the same problem. How will that be different six months after this project is over?” This last question is a particularly good one because when the executives answer it, they will answer with data. If they say that 30 seconds is too long on hold, asked them what the hold time should be.
That Large Project Planning Technique is the way you get objectively measurable acceptance criteria. Once you get those acceptance criteria, they become the foundation for your planning and change control. The executives can certainly change those criteria whenever they wish. However, changes to higher results like “resolving 98% of the customers’ issues on their first phone call” will increase both the cost and duration of the project. This method of defining the scope will be your life preserver as you navigate the tricky political currents of larger projects. This measurable scope definition will also allow you to avoid change control battles. If you can’t clearly identify what is and what is not a change to the original scope of the project, you will have new features added every week without any increases in the project’s budget or duration. Moreover, you’ll be blamed when the project is late and over budget.
That’s why a Large Project Planning best practice is to have objectively measurable acceptance criteria for the scope, the project’s major deliverables and every task you will assign to a team member. Then everybody knows what to expect. Accomplishing this is exceedingly difficult. Executives have to commit to exactly what they want. Moreover, you need to stick to your guns on the definition of these deliverables. When they insist that you start work before they define the scope, you give reasonable answers like, “How can I possibly start work when I don’t know what you want from the project? That would be like you sending me to the grocery store with money bit not telling me what you want me to bring back.” You might also say, “If this customer service project is important to the company, we really need to define what we mean by good customer service. Otherwise we’re going to waste a lot of money and time and probably produce nothing of value for the organization.” You can move on only when you have objectively measurable acceptance criteria for the scope of the project.
Large Project Planning Technique #3 – Define the High-level Deliverables
Next you must subdivide the objectively measurable scope into 4 to 7 high-level deliverables. These deliverables will lead you from where you are now to the end result, the project scope. This is also a critical step. From the first moment on the project, you will be under pressure to commit to a completion date and budget. As you work on defining the scope and high-level deliverables, you must refuse to make any kind of commitment or even discuss the cost and completion date. Instead, you should say, “I can’t possibly tell you how long it will take or how much it will cost until I know precisely and exactly what you want. Then I can estimate how much work it will take to produce it. Next, I will need to know what resources I have to do that work. When I have that information I can give you a reasonable commitment on completion date and budget.” When you have a network or hierarchy of deliverables with defined acceptance criteria, you can move onto the next step.
Large Project Planning Technique #4 – Develop Two Sets of Commitments
First, you need commitments from department and division heads about the team members who will work on your project and how much of their time the project will “own.” The second set of commitments is from the team members themselves. They must estimate how much work is required to produce the deliverables you assigned to them. Only after you have these two sets of commitments can you create a project schedule and calculate the budget based on the hourly rates of your project team members.
Large Project Planning Technique #4 – Develop a Change Management Process
The final Large Project Planning Technique is to enforce the principle that all changes to the project deliverables, schedule or budget, have a cost. There are no “free” changes. Every change has a trade-off. It isn’t possible to cut the project duration without any consequence to the project deliverables, schedule or costs. For example, the trade-off for finishing a week early might be an increase in the budget of $5,000 to pay for the required overtime.
Large Project Planning Techniques are Unique
These Large Project Planning Techniques are certainly different from techniques for managing small projects. However, when you leave the warm cozy world of managing small projects in your home department, you need to follow a very specific sequence of steps to handle the challenges of larger projects. You need to operate like a consultant who is managing a project for a client. You must adopt a different way of dealing with the sponsor and stakeholders. You have to become comfortable with “pushing back” and insisting on doing projects the correct way. You also need to avoid giving the executives any commitments about the project cost and duration before you complete the planning steps correctly. You can’t allow executives to get away with a vague project scope just because it’s politically easier for them. It will lead to project failure and they will blame you.
Here is how to plan a Risk Strategy for your project. You have gone through the risk identification process and you have done qualitative analysis of those risks. You may have also done quantitative analysis on a few major risks. Now you have your data on the probability of each risk occurring and the magnitude of the impact (on duration and/or cost) if it does happen. Risk Management Main Page
Let’s look at some examples. Say that each project has two risks:
Risk A is that turnover among the project engineers will exceed 15% year.
Risk B is that serious flooding during the spring will require the project team to relocate.
If you’re planning your Risk Strategy based on qualitative data, you have asked your team to subjectively evaluate the probability and magnitude of each risk. It will be in the form of:
Risk #A has a high probability of occurring and a high impact on the project if it does occur.
Risk #B has a low probability of occurring and a medium impact on the project if it does occur.
If you’re quantifying the probability and impact, you will have gathered data from historical records or experiments and will be able to summarize it like this:
Risk #A has a 14% probability of occurring and a $20,000 impact if it does The expected value of the risk is $2,800 (.14 x $20,000).
Risk #B has a 5% probability of occurring and a $1,000 impact if it does. The expected value of the risk is $50 (.05 x $1,000).
The quantitative risk analysis in your Risk Strategy is more usable than the qualitative analysis. It also costs a great deal more to develop. The numbers are particularly useful because they allow you to calculate the expected value of the risk. That expected value, which you get by multiplying the probability times the magnitude of the impact, puts a ceiling on what you can spend to completely avoid the risk. You don’t have this information when you limit yourself to qualitative analysis. But you need to plan your Risk Strategy regardless of the limitations of your information. Small Project Risk Management
Risk Strategy: What Risk(s) to Focus On
Risk Management: Risk Response Plan
You, the sponsor and stakeholders might decide to focus your Risk Strategy on risk #A – engineer turnover. You would accept risk #B – relocation due to flooding – because its probability and magnitude are small, based on both the qualitative and quantitative data. That means you will not plan any specific risk mitigation, avoidance or transfer to avoid the risk’s effect. You won’t spend any money trying to avoid or mitigate the risk. However, your Risk Strategy will include a contingency plan for this accepted risk. That plan will detail how to respond to the flooding risk if it occurs. The contingency plan might focus on identifying two available office locations that are nearby.
Then you would focus your attention on the more significant risk. Because risk #A – engineer turnover – is a negative risk you can use three Risk Strategies, individually or in combination.
Avoid the risk. This Risk Strategy requires you to alter the project plan to completely eliminate the source of risks. In this example, you might purchase the deliverable “off-the-shelf” so you don’t have to develop it yourself. So engineer turnover would not harm the project.
Transfer the risk. This Risk Strategy is similar to buying insurance for the risk. If you were concerned about a tornado, you might buy tornado insurance. For the engineer turnover risk, you might contract with an engineering consulting firm to provide the hours of engineer work you require.
Mitigate the risk. This Risk Strategy requires you to reduce the probability of the risk occurring and/or the magnitude of the risk if it does occur. These mitigation actions usually require you to spend money and the limitation is the expected value of the risk you calculated above. One mitigation might be to raise the salaries of your engineers to reduce the probability of their being hired by another firm. You might also hire two additional engineers which would lower the impact of turnover because you would have the extra staff immediately available. You often can’t completely eliminate the risk with mitigation. You merely reduce the probability and/or the magnitude of its impact. You have a remaining part of the risk that you have to accept and for which you would develop a contingency plan.
Risk Strategy: Involve the Team
Remember that the expected value of that risk of turnover among the project engineers is $2,800. That means you can’t spend more than that amount, even if you eliminate the risk entirely. That is the spending ceiling on the risk response. You would gather the risk management team together and ask for ideas that would reduce the project engineer turnover to 15% or less.
One team member might suggest that all the engineers working on the project receive a $200 bonus if they stay until the project is completed. With 14 engineers, there would be sufficient money to pay that bonus amount but then you would need to completely eliminate turnover above 15%. A number of members of the team might raise an objection. They say that engineers who are offered a substantial pay increase by another firm would not stay on the project for as little as $200. They also suggest that if other members of the project team didn’t receive a similar bonus it might create even larger morale problems. You would for other ideas for holding down turnover. A team member could suggest hiring additional engineers for the project team. This would give you the capacity to absorb turnover above 15%.
A few minutes of Risk Strategy, even on a small project, delivers a good return in proportion to the cost.
Risk Strategy: A 3-Tier Response Approach
Project managers often skip the Risk Strategy process because the sponsor wants them to start quickly without wasting time on “useless paperwork” like risk management. This dooms you to non-stop fire fighting for the life of the project. We use a 3-tier Risk Strategy approach for projects of different scale and importance. On even a small project, you can do a simple risk assessment, investing as little as an hour and possibly saving days of lost time. That’s why we recommend using a 3 tiered Risk Strategy so you can match them to the scale and significance of the project. Here are definitions of the tiers:
Tier 1 – A project done within a department or small company where the PM and team all report to the project sponsor.
Tier 2 – A cross-functional project which affects multiple departments in the same organization.
Tier 3 – A strategic initiative or consulting engagement that includes both technical expertise and project management services for an outside client or customer.
Risk Strategy: Risk Management Template
Here are 5 risk management steps that lead to your Risk Strategy planning:
Identify the risks that threaten delivering the scope on time
Qualitatively assess the probability of the risk occurring
Qualitatively assess the magnitude of the impact if the risk occurs
Select the most significant risks
Plan how to avoid them or minimize the damage if we can’t avoid them.
In risk identification, you are simply harvesting as many risks as you can without making judgments about their significance. When you have the list of risks, you’re ready to begin qualitative risk analysis. That’s where you focus on evaluating the significance of each risk using relatively quick and inexpensive techniques. Specifically, you are assessing the likelihood a risk will occur and the impact (cost and time) if it does occur. You use these assessments to prioritize our risks in terms of their significance.
Risk Strategy: Three Situations
Tier 1 – In-department Project Risk Situation
The PM and two team members spend 30 minutes on risk identification with a limit of 7 risks in two risk categories that threaten project success.
The PM and two team members spend 30 minutes on qualitative/subjective risk analysis. This is the only support for the risk response plan because the project’s scale does not support the cost or time for quantitative analysis. The two members of the team and the project sponsor will subjectively set the impact and likelihood values for risk and impact analysis.
The PM and sponsor will agree on the risk response plan in 30 minutes.
Let’s look in on how the process would work. For an in-department project, risk identification and qualitative analysis is all we’ll do before planning our risk responses.
The PM and the two team members take a short lunch and talk about the risk events that could cause them to fail to deliver the project scope. Then they discuss events that would affect finishing the project on time. They return with a list of 7 risks to consider. Six are negative risk events. The last is a positive risk event that would let them finish a week early.
After they’ve completed the risk identification, the PM and the two members of the team go to the PM’s cubicle. The PM smiles at them and says, “We’re 1/3 done. Now let’s spend about 30 minutes analyzing the risks we identified.
Here’s a form we’ll use to get everyone’s assessment of the risks we face on the project. We want to describe each risk in terms of two separate dimensions; 1.) the probability or likelihood of the risk event occurring and 2.) the impact it will have on the project if it occurs. We’ll use a simple scale with three choices for probability and for impact:
low – meaning very unlikely to occur or a small impact
high – meaning very likely to occur or a large impact and
medium – between those two extremes.”
Following the risk assessment, the project manager charts the results, asks the boss to join them, and displays the simple grid for the group.
The PM says, “We all seem to agree that while we have several risks, only one risk has both a high probability and a high magnitude and that’s the risk of customers not using the new procedure.”
The boss says, “I thought this risk stuff was going to be a waste of time, but I’m already thinking of things we can do to educate the customers about the new procedures. That is one problem I would not want to hear about at the end of the project.”
Following the boss’ comments, the group begins to assemble a strategy. First, they discuss possibilities for changing the project plan in a way that allows them to completely avoid this risk. But it doesn’t take long before they realize there’s no way to avoid the customers having to learn the new trouble ticket procedures. They also briefly discuss being able to transfer this risk to another party and “buy insurance” to avoid the consequences. The boss brings that discussion to an end by telling them no training firm would undertake responsibility without charging them tens of thousands of dollars.
With limited strategies for avoiding and transferring the risk, the group focuses on mitigation. One mitigation that everyone likes is distributing professionally designed instruction manuals for the customer. That includes a laminated one page crib sheet to help them easily follow the new procedure. The boss agrees that wouldn’t cost very much and welcomes the idea of adding that mitigation to the project plan. They spend a few more minutes discussing other options including writing profiles of customers who did well with the new procedure and including it in the company magazine. No one likes that idea so they stick with the customer instruction manual mitigation idea. That brings their risk response planning to an end.
Tier 2 – Cross-functional Project Risk Situation
The risk management plan calls for using qualitative risk assessment as a screening tool for quantitative analysis.
The PM anticipates that they will analyze 12 or more risks in an intensive quantitative analysis.
Three committees will perform qualitative analysis. Each one is focusing on a particular category of risk within the categories supplied by the organization.
The sponsor will decide which risks go to quantitative analysis.
The cross-functional project manager distributes the qualitative risk assessment form to each of the three risk committees to use in assessing the project’s risks. The team members are quite familiar with estimating probabilities and magnitudes so the project manager uses a 1-10 scale for the estimates. The first page of one committee’s form looks like this:
Then the project manager gives the committee leaders their instructions, “Each person will make an independent judgment about the probability of each risk event occurring and the impact on the project if it does. We’ll use a 1 to 10 scale for each assessment. So if a risk event is very likely to occur you should give it a 9 or even a 10. For a risk event that is very unlikely, give it a score of 1 or 2. We will do the same thing on the impact. When you come to that decision, forget the probability of the risk event occurring. Simply assess how big an impact it will have if it occurs. If its impact will bury the project and do us irreparable harm, you should score it a 10. If a risk event has minimal impact on the project, give it a 1 or 2.”
One of the team members says, “Aren’t we going to discuss each risk first?”
The project manager answers, “No. I think it’s best if each person gives their assessment without being influenced by the others. Remember that we have people whose immediate superior is on the same committee. If people reveal their opinions before we each score the risks, the manager’s opinion may count for too much. Let’s have everyone make a judgment without knowing what the managers think. We may get better information with independent judgments and avoid some of the politics. For that same reason, we’ll keep the ballots anonymous; you’ll notice there is no place to fill in a name.”
A few days later, the project manager gathers the completed forms from the committees and tabulates the data into a spreadsheet designed for this purpose. The result is a table of data values and a graph for each of the committees.
The cross-functional project manager takes the committees’ data and recommendations to the risk management committee which is made up of the sponsor and an executive vice president. The project manager selects one or two risks from each committee’s qualitative analysis and recommends quantitative analysis.
Three of the risks have probabilities and impacts above eight so the committee decides that all three warrant quantitative analysis. They are particularly concerned about the risk of customers not using the new trouble ticket procedure. They ask the project manager exactly what they will get from this quantitative analysis.
The project manager says, “We will start with an influence diagram that we developed during risk identification. Then we’ll gather some opinions from industry experts and build a decision network to analyze where we can have our biggest influence in avoiding that risk.” On this larger and more significant tier #2, cross-functional project, the decision-making about risk response strategies can be much more extensive. It can also involve substantially larger costs than the tier #1, in-department project.
A committee of executives will make final risk decisions based on detail work developed by risk committees focusing on special categories of risks.
The size of the project budget and its strategic significance for the client warrant elaborate quantitative analysis, which has been included in the risk-management plan.
The budget for quantitative risk analysis includes funds to pay experts’ fees and for research and data gathering. Presenting Your Risk Plan
The project manager presents the qualitative risk analysis information to the client’s management. Because these executives are familiar with making decisions based on data, the PM consultant includes qualitative measures of probability and impact and as well as data precision value. One of the executives asks, “What is the significance of that data precision score? Didn’t our people do a good job in the risk assessment?”
The consulting project manager answers, “No, that’s not the case at all. That data precision score is reflective of the accuracy and validity of the data we have about each of the risks. It reflects our understanding of the risk, the amount of information we have available about it and the reliability and integrity of that data. The score is based on my firm’s collective experience with projects of this type. As you can see, there are a number of risks about which we know a great deal. As an example, the quality of the data we have about the third risk on the list is quite good. We have very reliable data from the company’s own quality control and quality assurance processes and I have given that risk a data precision score of 80 to reflect the quality of that data. On the other hand, the risk we are most concerned about is that the customers will not utilize the new trouble ticket procedure. I’ve given that a low data precision score because your organization has very little information. What we have is about other segments and is of questionable reliability. We are concerned about the risk because of its high probability and high magnitude. But frankly, the absence of good data is equally important. For that reason, I’m going to suggest we do a Monte Carlo simulation so we can more accurately assess the impact of that risk on the project’s overall duration and budget.”
The client executives accept the consulting PM’s recommendations and the list of prioritized risks. They authorize the project team to move on to quantitative risk analysis. For this very large strategic initiative level project, the quantitative analysis process can easily take months and include substantial and expensive data-gathering efforts. They will provide a better assessment of customer behavior and how it could be changed. From that data-gathering phase, the decision-makers will have sophisticated simulation information which would trigger the brainstorming process of the Risk Strategy.