Project management tools and techniques that work! A baker's dozen



Many project managers feel the deck is stacked against them and that they are playing a game in which a successful outcome is difficult to achieve. There are also some situations outside of the project manager’s control that contribute to this thought. Nonetheless, as the individual most responsible for achieving successful outcomes, the project manager needs to have a high degree of confidence in achieving these objectives.

This Congress session is designed to be interactive and presents the participants with some tools, techniques, and ideas that contribute to achieving successful outcomes. These tips and tools have been cultivated from a number of projects and organizations and represent solid “best practices” used to manage projects. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) includes many proven techniques and tools designed to facilitate the processes used to manage projects. The tips and tools presented here are designed to supplement those processes and are accompanied by a practical application or “war story,” to illustrate how to successfully use these concepts.


Every organization has its own set of methodologies, templates, and best practices, each designed to fit into the organizational flow and procedures. Some of these items aid the project manager, but many do not offer the practical tools and aids that project managers need. What are the “real” techniques and procedures performed by those who lead project teams and deliver results on a consistent basis?

The PMBOK® Guide is very good at outlining the “whats” and “whys” of project management and even does a good job of listing some effective tools and techniques for performing project tasks. What’s missing, however, is “how” the tools are used effectively in various project situations. How do real-life project managers perform these activities successfully? This paper will describe some tools (thirteen to be exact) that are designed to facilitate dealing with some of the challenges facing project teams and provides a context for their use.

# 1 - Getting a Commitment

“What’s the difference between a chicken and a pig with respect to a bacon-and-egg breakfast?”

  • The chicken is involved.
  • The pig is committed!

This simple little joke underscores the importance of having committed, and not merely involved, project stakeholders, which is especially true for the project team. There are many studies that address the importance of a “shared vision” among team members and how the appropriate number of skilled resources available at the right times being major factors contributing to project success. As R. Camper Bull points out, “A true team should understand not only their jobs, but is committed to and has a sense of accountability for the entire organization.” (Bull, 2008, p 5)

Carrying the analogy a bit further, a project manager needs to have pigs, not chickens, working on his or her project. As the leader of this team, the project manager should also have a plan about how to build this commitment, especially given the challenges of a mobile workforce, virtual teams, and shrinking resource availability.

Uncommitted team members can have a number of negative impacts on the project, ranging from uneven participation to “blamestorming,” to a bunker mentality among the members in which the team shields itself from outside criticism by isolating the team from other stakeholders and develops an “us” versus “them” outlook. Dealing with this problem requires that you embark on a program to build team member commitment and this process starts as soon as the team is formed. According to Vijay Verma, “Project managers must create an environment that facilitates real teamwork and fosters human synergy.” (Verma, 1995, p 36) There are many ways to do this, and there are lots of resources available for getting information about building an effective team. Here are some proven methods to help you start this process:

  • Create a set of ground rules for team behavior. Document the rules that govern the work environment and include such things as the decision-making process, how to conduct brainstorming sessions, meeting rules and behaviors, handling conflict, and so forth. Establish these rules with team members early on, while they are still in the forming stage. You will need to reinforce these rules when the team gets to the storming stage.
  • Use responsibility assignment matrices (RAM). RACI charts (PMI, 2009, p 221) are a good means to show the areas of the project that each team member is accountable for, responsible for, or involved in.
  • Create task and deliverable completion requirements. Make sure that each person knows what he or she needs to get done regarding these assignments.
  • Share ownership with individual team members. Once the team gets through the storming stage and is beginning the norming stage one, the project lead can start sharing some of the leadership responsibilities. Parts of the project can be “owned” by individual team members, making them more committed to results in that area. Naming a team member as a risk owner would be one example of this.

# 2 - Lessons Captured versus Lessons Learned

“Those who cannot remember the past are condemned to repeat it.”

George Santayana (Santayana, 1905)

It is for this reason that many project teams conduct a final lessons learned session at the conclusion of a project. Lots of things can happen on a real project, some are planned and some occur quite unexpectedly. There are lessons to be captured in whatever happens on a project, and it is the wise project team that captures all the incremental process improvements that can be identified and used to update any related management plan.

But the real question is; “Are the lessons really learned?” Before you answer, consider the following situation:

You are in your home, and you walk out the back door into your yard. There is a rake on the ground, tines pointing up, that you don’t see. You step on the end of the rake, and the handle swings up and hits you in the head. It hurts.

How many times would that have to happen to you before you decided to move the rake? Hopefully, the answer is once!

Now, take the same situation and substitute the phrase “your organization” for “you” in the above scenario. How many times would your organization have to step on the rake before it decided to fix the problem? Would it be more than once? Ten times? One hundred times?

How many times has the same error occurred on more than one project in your organization? How many times has the defective process occurred in the past? Was it ever actually captured in a lessons learned database? And yet, in spite of any efforts for continuous improvement, the error occurred once again. So, the question is: Was the lesson really learned or was it merely recorded as our methodology said it should be recorded?

Most of the problems in this area stem from the methods and processes organizations use to store project information. Many organizations rely on individuals to be the repository for project management best practices. These organizations’ idea of knowledge sharing is “Mary did a project like that a year ago. Ask Mary what the top five risks were on her project.” The problem with the “Hey, Mary” database is that often Mary is not available, no longer with the organization, or worse yet, Mary was a consultant and she’s now using that information for the betterment of another organization. Even organizations that do have knowledge repositories for this collective project information often don’t make it easy or convenient to share it. I have often encountered individuals in an organization who did not know about the repository, where it was located, or how to access it. Having useful information that no one can use is the ultimate in ineffectiveness!

To combat this behavior, you need to establish some standard practices for capturing and storing valuable project information. Here are a few ideas:

  • Become the model for dealing with which processes work and which don’t. Store the information in an accessible, central location to share among team members, and make sure that all team members know where that information is stored and how to access it.
  • Analyze the information. Look for the most frequent sources of project problems and develop a way to handle these problems.
  • Change processes that don’t work or add value. Know when it’s time to do something different (move the rake).
  • Make lessons learned an agenda item for each status meeting. Ask the team, “What did we learn this week that will make us smarter next week?” Don’t wait until after the project is over to get better.
  • Create categories for common problems. Then, look at which categories cause the most serious problems; these areas represent areas for improvements and process re-designs.

#3 - Focus Days

How many times have you witnessed the following scenario? You’re in the later stages of a project when the net effect of all the task slippage takes its cumulative effect and causes the project to fall behind schedule. Suddenly, the project manager slips on a superhero costume and yells, “All Hands on Deck! Drop everything else and focus on meeting our project obligations.” Everything else comes to a screeching halt, because everyone involved in the project drops everything and focuses their full efforts on getting the project completed. The project team works hard for long hours, often on weekends, and through a Herculean effort, manages to bring the project in on time. The project manager is then recognized as the individual who drove the project through to successful completion and receives all the accolades befitting a superhero. No one seems to recognize that the monumental effort required to complete the project was the result of earlier poor planning and execution, and that the project manager was reacting to problems that he or she may have, in fact, caused. Like the firemen in Ray Bradbury’s Fahrenheit 451 (Bradbury, 1953), they are creating the fires that others will have to put out.

Perhaps there is a lesson in all this beside the obvious one that focuses on planning and risk management. Let’s examine why the “hero” managed to bring the delinquent project to a successful conclusion: all team members were allowed to stop working on other tasks and focused all their efforts on bringing the late project in on time. It was the focused effort of the team that allowed the project manager to meet his schedule! How can we use this idea in everyday practice? My advice is to create pre-planned “focus days” in the project schedule. Focus days are days in the schedule in which the team focuses on only one activity or deliverable. It’s like the “all hands on deck” presented earlier, without any of the stress of an impending project end date. This will take careful scheduling, but the benefits of improved communication, higher quality, and the team’s sense of accomplishment cannot be ignored.

#4 - Crawford Slip Adaptation

In the 1920s, Dr. C.C. Crawford, a professor of education at the University of Southern California, invented a method of brainstorming that involved collecting slips of paper from a group of people focused on solving a problem or exploring an option (Mycoted, June 26, 2007). This was intended to be a way to gather ideas from a large group and set them aside for subsequent analysis or offline review but it also has other idea generation applications. Some variants of the technique allow team members to modify or add to the ideas of others by passing the slips around and commenting directly on the slip.

Brainstorming, by nature, is a two-step process. The first step is to generate as many ideas as possible without evaluating them. This step is inherently an additive one, because we want to create as large a list as possible. Dr. Linus Pauling said, “The way to get good ideas is start with lots of ideas, and throw the bad ones away.” (, 2010, p 1) Once we have lots of ideas, we can proceed to step 2 where we take the rather large list of items identified in step 1 and pare it down to the significant few on which we will act.

The trap that many people fall into is in trying to do both steps at once. They try to evaluate the idea at the point of creation, often killing an idea before anyone has a chance to evaluate or improve on it. What’s needed is a process that allows the team to perform brainstorming in a focused, step-by-step manner.

I use an adaptation of the Crawford slip method in which an index card, sticky note, or other slip of paper is written on and then passed to another team member. Typically, I use it in brainstorming situations where I’m trying to get lots of ideas in a very short period of time. Briefly, here are the steps in the process:

  1. Hand out index cards or slips of paper, one per team member. Arrange the team in a circle for this exercise.
  2. Give each person between 10 and 20 seconds to write down 1 or 2 ideas relating to the topic that you’re brainstorming. Keep time with a stopwatch.
  3. At the end of 10 to 20 seconds, tell the participants to stop writing and to pass their cards/papers to the next person, in a clockwise direction.
  4. Give each person a few seconds to look at the card or paper passed to him or her; then, ask each person to add 1 or 2 new items to the ones listed.
  5. Keep the process of passing the slips and adding to them, and continue for no longer than 3 minutes.

This process has the following benefits:

  1. It’s a team process. Team members need activities like these to get and keep them engaged in the project. People who perform the project work should help plan it.
  2. It’s very democratic. Every team is made up of vocal and non-vocal members. The vocal members dominate most team meetings, which often causes the non-vocal members to withdraw even further. This process, which uses slips of paper instead of shouting out ideas, gives everyone a voice to be reckoned with.
  3. You can leverage the output of other team members. No matter how crazy an idea appears at first look, there is no telling what effect that idea may have on another team member who may now look at options in a different light. Many team members will “hitch-hike” on another team member’s thoughts and carry them a little further to see where they go.
  4. It’s a process. In a very short period of time, you get predictable and repeatable outcomes. Again, the object is to get lots of ideas, and then, later on, focus on the few that will acted on.

Obviously, the results of this process are just step one of brainstorming. The second step would be to look at the ideas generated and reduce them to the significant few that will be implemented.

#5 - Success Criteria: What Winning Looks Like!

Imagine you were about to start a marathon race. The finish line is 26.2 miles away, but you’re unsure of the direction. You’re afraid to start the race because you could be running in the entirely wrong direction, and would have to backtrack to get back on course. All at once it hits you! Knowing where the finish line is in the beginning of the race is a good idea, because it increases the likelihood that you’ll reach the finish.

The above story can be applied to projects as well. In a project, the finish line can be compared with meeting the project objectives, which are the success criteria for the project. Winning is about meeting those objectives, and project managers are those appointed to win and achieve those successful outcomes. I think we can all agree that establishing what makes a successful outcome is a valuable step toward actually achieving these objectives.

How do you or others in your organization define project success or project failure? Is it really just the criteria: on time, on budget, and within specifications? Are those the only criteria used for determining whether you have successfully delivered the product, service, or result that your project was chartered to produce? Have you ever delivered within the constraints of schedule, budget, scope, and quality and still failed to meet customer expectations? Is that project a success? Is it possible to be over budget, late, and with reduced scope but still deliver to a satisfied customer? Is that project a failure? How important are stakeholder expectations to your view of project success?

It has been my experience that many projects deemed failures were nothing more than failures to set and manage the criteria on which project success is viewed in the eyes of the stakeholders. The project team and the key client stakeholders might have differing views of what constitutes a successful outcome, and a gap exists between what the customer is looking for and what the project produces. The more stakeholder groups are involved in a project, the more likely this bad situation will be exacerbated. It has been said that a camel is a horse designed by a committee, and I have seen my fair share of project teams who deliver a camel to a client requesting a horse.

It takes a lot of work to define the success criteria for a project, but the effort is more than worth it in terms of meeting stakeholder expectations. Even the simplest board game comes with the rules printed on the inside of the box cover! Why don’t we adopt the same principle and establish these rules for success before we play?

How do we define the success and failure of a project? In my mind, any definition that does not include customer acceptance and satisfaction is not adequate. The triple (or sextuple) constraint model is a good place to start, but remember that we use this model to frame the constraints that shape the needs and expectations of the project stakeholders. We need to come up a common set of success criteria (called project objectives) for the project. Many projects get off track due to a failure to define the reasons to initiate a project and what a successful outcome looks like. In a 1994 KPMG study, it was revealed that one quarter of the troubled projects surveyed became problematic during the initial planning stages (Cole, 1995). For this, and many other reasons, it is imperative that a project manager confront any situation influencing success as soon as possible and take action to deal with it.

It is no secret that the project sponsor, as well as the project manager and team, have a great responsibility to establish the success criteria for the project and the sooner, the better. The PMBOK® Guide has a number of processes that can assist in this regard. The project charter and project scope statement are two tools used by organizations to help define such things as project justification, business case, product acceptance criteria, and project objectives. Getting agreement (signatures) on these documents goes a long way in getting commitment from the key stakeholders as to what success looks like for the project.

Of course, part of the challenge of setting up the success criteria is stating them in an unequivocal fashion. To be at all effective, these success criteria must be stated in a way that allows the project team to definitively measure whether or not they achieved their goal. Too often, immeasurable words or phrases work their way into statements of what a successful outcome looks like, and the project team and stakeholders are often left arguing about whether a particular objective was achieved. Here are a few tips to remember when creating measurable success criteria:

  1. The secret to measuring is numbers. If the agreed upon deadline is 1 October 2011, then we’ll know, unequivocally, if we succeeded on our time objective on that date. The same holds true for cost objectives. If our budget was not to exceed $1 million, then we’ll be able to see how we did on that objective when the project is over. It’s the quality objective that I often find the thorniest one to define, partly because quality objectives are often expressed using imprecise, or “fuzzy” terms.
  2. You can’t measure “fuzzy.” Quality terms like “robust,” “scalable,” or “user-friendly” are open to interpretation. At the end of my project, I want to know that I won and that I achieved the success criteria. I don’t want to debate that. Be wary of imprecise or fuzzy measures of success, because there will be no way to measure them unless you precisely define “fuzzy.”
  3. Set up equivalences. A good way to bring the discussion of translating the fuzzy terms into measurable ones is to set up what I call “equivalences.” The syntax for an equivalence is:

    Fuzzy Term = Measurable Term

    For example, we might say that “user-friendly = users correctly submit a request in under one minute, at least 90% of the time.” I can measure the right side of that equation as part of my testing.

  4. Get agreement on the measures. This is part of the stakeholder management process, and I would want to do this early on, so that everyone is focused on building the correct (and acceptable) end product.
  5. Create acceptance criteria. I would want to set up the acceptance of the final deliverable before I actually need it (or even build it), so I don’t encounter a problem in gaining acceptance later.

#6 - Stay on Your MEDDS!

I was asked if I could recommend one thing that I thought would best help a project manager become more effective. Without much thought, I responded that project managers should stay on their MEDS. I have a preference for using acronyms (and aphorisms) to bring an idea into sharper focus, and realize that MEDS means more than the obvious. At the time I was asked, MEDS was short for “manage expectations/defend scope,” but I recently changed the idea to “manage expectations/define and defend scope” (MEDDS).

Project scope management is one of the areas in which projects typically get derailed. As project managers, we spend a great deal of time dealing with scope issues, and many of the stakeholder concerns revolve around requirements management. Whether it was a poor job of requirements gathering, specification, or scope creep, many projects suffer from a failure to manage the scope of the project. Scope management is an all or nothing proposition—you’re either managing scope, or you’re not! Scope management begins with the project objectives, moves through the definition and WBS processes, and culminates once the product is accepted. All the while, we try to manage and control the scope as we move through the project.

What you see in the above scope management process is a lot of expectation setting and expectation management. The phrase “Stay on Your MEDDS!” attempts to deal with both managing expectations and dealing with scope. If you are going to take the time to define the scope, then it makes sense to apply an equal amount of effort defending it. By “defending” scope, I mean ensuring that all scope changes go through the scope change control procedure as outlined in the scope management plan. Many project issues go away when good scope management is applied.

There are several tools that project teams can use to help manage scope, and here are a few tips:

  1. Get signatures on requirements documents and scope statements. People view signatures as a deeper level of commitment than just a simple agreement and will often ask questions before signing a document. This is a good thing, because this process can help alleviate any misconceptions about what is in or out of scope.
  2. Be explicit about scope exclusions. Planning a project is like ordering off the à-la-carte menu, where you pay for everything you order, but customers think they’re getting a dinner, complete with all the fixings. To avoid the “I thought this was included in the project…” syndrome, be explicit about those scope items that you know will not be in the completed product.
  3. Share the WBS with your customer. Explain the purpose of the WBS and insist that they get everything listed but won’t get anything not listed. It’s not important whether they understand all the components. What is important is that they realize that there are a lot of them, and if they ask for something not listed, it represents additional scope.
  4. Run all scope change requests through change control, no matter how small. This way, you set the expectation that this is the way we modify the scope baseline.

#7 - Fix the Right Problem

Things work well when there is a healthy balance between the following (Exhibit 1):

Healthy Balance

Exhibit 1: Healthy Balance

There are well-defined processes in place, the tools and technology support the processes, and the people have been trained in the process and the technology. Many organizations have experienced some improvements in project results simply by establishing standard processes and tool usage.

Problems occur, however, when one or more sides are out of balance. For example, we may have poorly-defined processes or processes that produce errors or undesirable outcomes. Rather than fix the broken process, we often invest in a new technology or toolset, one that ends up producing the errors faster! Another example occurs when we have established processes, but the tool doesn’t support the process, so the people become the glue between the technology and the process. Of course, there are multiple variations and combinations of these examples, but the lesson here should be clear: Fix the right problem!

Find out which side of the triangle is broken, and develop a solution that addresses that side. If the process isn’t working, fix the process. If the tool doesn’t work, stop using the tool! And if the problem is focused on the people side, deal with it as a personal or team issue. Don’t try to create a “fool-proof” process; people will find a way around it. Treat people-problems as behavioral problems, and take steps to modify the behavior.

#8 - Baby Bear Project Management

In his book, “Just Enough Project Management,” Curtis Cook states “Many organizations have embraced project management but have adopted the ‘700-page-book approach’ with dozens of process steps and associated inputs, outputs, and tools and techniques. Yet the statistics cited by major research firms tell us that fewer than 50 percent of our projects achieve their objectives.”(Cook, 2005, Page x) These days, when the agile and lean methodologies dominate any discussion of business processes, it is imperative that project teams use the levels of process and control required, and no more. We can no longer afford to overlay the cost of an excessive process and methodology to a project. Customers are looking for ways to cut project costs, and project management is one place where they look first. We must tailor the amount of process to the project at hand, using just the right amount of project management.

To give a visual analogy to this idea, I use the story of Goldilocks and the Three Bears. If you remember the story, Goldilocks enters the house of the Papa, Mama, and Baby Bear. She tries various things in the house, from eating the porridge (why is there always porridge in fairy tales?), sitting in the chairs, and lying on the beds. Papa Bear’s stuff is “too hot!” or “too hard!” whereas Mama Bear’s is “too cold!” or “too soft!” But Baby Bear’s stuff is always “just right!” Not too little, not too much, but “just right.” And, this is the secret to figuring out how much project management a project needs. Not too much, certainly not too little—just the right amount will work great!

But how does one determine what “just right” is? Once again, we return to lessons learned and information from past projects. Information about how much time was spent on project management activities in past projects will give a clear indication of how much time was devoted to these activities. Having project management as a level 2 WBS deliverable is a good way to go about capturing this information. The lessons learned process can evaluate if the time spent on project management activities was spent well. Again, it is beneficial to the organization to share this information.

#9 - Let’s Pretend

Have you ever found it difficult to bring up a discussion of risk early on in the project definition phase? Many project managers find it a challenge addressing a future problem when the major players are excited about the upcoming project and the benefits such an undertaking will deliver. Anyone bringing up problems is viewed as a negative person, or “not a team player.” Yet, the risk is still out there and will have to be addressed at some point. I use the phrase “let’s pretend” to initiate any discussion involving the future and it sounds something like this:

“In the past, when I’ve done a project like this, this (issue or problem) occurred. Let’s pretend it happens on this project. How would you propose we deal with it when it happens?”

“Let’s pretend” allows one to take the conversation into the future, to the point where some issue or confrontation is real, and forces others to address the problem that has happened (Baker, 2004, p 6). The phrase forces the situation into the future, at the point in time where the risk or issue is realized, and asks the team to think about a response today. In practice, it’s an easy tool to use, because you’re not really saying the problem exists, but forcing a look at it anyway. In addition, it sounds non-threatening, so you can use it to jump-start the conversation about risks and risk management.

But the best part of the tool is its invisibility. No one ever sees this tool for what it really is—a tool for setting and managing expectations about what will occur in the future; as such, it can be used in a variety of situations. We’ve already seen how it can be applied to discussion of risk management, but it can also be applied in setting customer expectations around requirements and scope management, setting team behavior and ground rules, and creating roles and responsibilities for the project team/sponsor. The dominant principle behind the tool’s use is that we want to address a potential problem before it occurs, and “let’s pretend” allows us to do just that.

#10 - It Depends

Now that the triple constraint has been enhanced to the sextuple constraint in the PMBOK® Guide (fourth edition), it is important for the project team to understand the interrelationships among the various project objectives. As the PMBOK® Guide states: “The relationship among these factors is such that if any one factor changes, at least one other factor is likely to be affected.” (PMI, 2008, p 7) Due to these relationships and interdependencies, every discussion and decision made on the project requires an examination of the multiple impacts any choice would cause. Because of this, options and choices take time.

When asked for an answer to any question regarding the project, the conditional response, “it depends,” is, in my opinion, the only one that makes sense. All the parts of a project plan are interconnected—changes to one part will flow into all the others. (Why do you think it’s called perform integrated change control?) Of course, giving this response leads to the inevitable “on what?” follow up, which is a good thing. By asking the “on what?” question, the stakeholder has opened the door to a discussion about the potential impacts of a change—all good things for a project manager and stakeholder to discuss. I use this phrase to begin the discussion of the tradeoffs necessary in any type of baseline change. The “It Depends” answer allows one to talk out the various scenarios that may occur should we be requested to make a change to the project plan, and the agreed upon project success criteria.

#11 - Product on a Page

It has been said that a camel is a horse designed by a committee. Does that sound like your last project? Do you often have problems getting the team and the customer to agree on the final product, service, or result? How can we make sure that the project team is in alignment with the customer’s wishes?

I use a technique called “product on a page.” In this technique, the project team tries to develop a one-page marketing piece for the final product of the project during the early design period. In the marketing piece, the team focuses on four things:

  1. A tag line for the product. For example, for a job aid, the tag line might be “Everything you need on a single reference card!”
  2. The features of the product
  3. The benefits of using the product (from a customer’s perspective)
  4. A visual. The visual could be a mock-up of the website or a picture of a homeowner happy in his new house.

The benefit of having the team go through this exercise early in the project is to make sure it is focused on producing a deliverable that the customer will accept and use and clear up any misconceptions about what is or is not a requirement. The team looks at the product from the customer’s perspective, adds vision and understanding to it, and presents it back to the customer for approval before anything is built. It’s a good way to ensure alignment on the product scope.

#12 - Continuous Improvement

Which technique looks like a more reliable way to achieving consistent high quality over time?

Technique 1 – Set the quality standards unrealistically high. Then, whatever we end up with will be of higher quality than if we set the bar low.

Technique 2 – Set the bar to a minimum standard. When the standard is reached, raise the standard to a higher level. Continually raise the bar each time the standard is met.

Technique 1 sounds appropriate for a one-off product but to get increasingly higher levels of overall quality, technique 2 is the way to go. The Japanese call this “kaizen,” their word for the continuous improvement process. Walter Shewart and W. Edwards Deming gave us the model for this when they introduced the concept of plan-do-check-act (PDCA). Perform a gap analysis to uncover the need for a new product, service, or result; then, develop the plan, execute it, check for variances, and act on any variance or process improvement. This model has been used since the 1950s.

It has been my experience that we’re very good at the do and check part. Planning has gotten better, although there is still evidence of the Nike school of project management disciples (“Just Do It!”). It’s the act part that needs improvement. We take corrective and preventive actions based upon the changing events in our project, but many times fail to correct the faulty or inefficient processes that lead us there. Part of the act part looks at what works, doing more of it, and stop doing what doesn’t work. Fix the broken processes or at least stop using them! Albert Einstein defined insanity as “Doing the same thing over and over again, and expecting different results” (BrainyQuote, 2010 July, p 1).

A simple tool I like to use is a technique called plus/delta (+/Δ) (Verzuh, 2009, p 130), where plus represents all the things we have been doing well as a team, and need to do more of. Delta represents all the things that are not working and that we need to do differently next time. I often recommend that teams do the plus/delta technique every week to make sure that they are continually improving as a team.

#13 - It’s ALL About ME!

You increase the likelihood of customer acceptance and delight at the end of your project if you manage stakeholder expectations from concept through delivery.

What’s your reaction to the above quote? Do you agree?

Did you observe that not once were the phrases “on time,” “on budget,” or “within specifications” used? The operative phrase used was “manage stakeholder expectations,” which interestingly, was significant enough to be included as a PMBOK® Guide process - 10.4 – Manage Stakeholder Expectations. According to the PMBOK® Guide, “actively managing stakeholder expectations decreases the risk that the project will fail to meet its goals and objectives due to unresolved stakeholder issues and limits disruptions during the project.” (PMI, 2008, p 262)

Using this quote as our guide, we can see that the primary responsibility of a project manager is to manage stakeholder expectations, and a more apt job title might be “expectations manager.” If that’s the case, then a phrase that every project manager can use as a guideline would be:

“It’s All About ME!”

Of course, in this context, “me” is short for managing expectations (Baker, 2006). The job of the project manager, then, is to set and manage stakeholder expectations throughout the project, which translates into defining and defending scope, identifying, analyzing, planning responses, monitoring and controlling risks, proactively planning, and delivering quality. Managing communications with the stakeholders would also be a key part of this process. Everything we do should be from the point of view of expectation management; in short, expectations management is project management!

Everything you do, or don’t do, creates an expectation for future behavior. You might require that team members document their assumptions or state the bases of their estimates, as parts of the planning process. Reinforcing this idea at every team meeting will make it far easier to develop the consistent and ongoing behavior of the team. In a similar manner, actions that you do not perform will also create an expectation, as sure as if you did something! For example, if you allow team members to be late submitting status reports, the expectation is set that timely submissions are not important and that it’s okay to submit reports late.

The clearest example of this concept is evidenced by the presence of “scope creep.” If additional requirements are sneaking their way into your list of deliverables and are not dealt with using integrated change control, then the expectation that is set is that there is no change control! Either you practice scope management, or you don’t. What expectation do you want to set for your stakeholders?

The tools typically used to set and manage expectations are those we call “soft skills.” Negotiation techniques, influencing skills, active listening, and conflict management are the areas in which increased fluency can help in this matter. Here are some thoughts that might help frame your point-of-view on this topic.

  1. Take a large index card, write the letters SAME on the card, and post it by your desk. Use the card as a visual to remind you that your job is to “set and manage expectations!”
  2. Project management is not about having everything planned but about having a plan for everything. Make sure that your management plans (scope, schedule, risk) are up to date and that you continually improve them by using them.
  3. Project management is a recipe, not a guarantee. Because the end of the project occurs in the future, and the future is uncertain, you cannot guarantee what will happen. But you can take steps to increase the likelihood of desired future outcomes, and that is what project management is all about.
  4. Model the behavior that you want your team to use. Set the expectation that we will be following our team norms and best practices and make sure that you demonstrate that behavior.


This paper focuses on some ideas, tools, and techniques designed to help working project managers cope with the various challenges presented to them while managing a project. Many of the ideas were presented with a story, analogy, or some pithy statement to help remember the concept. Finally, hints and recommendations were given about tools and processes that will help create the right mindset or correct the problems identified. These tools or tips were listed, along with suggestions for their use.

Baker, E. (2004, October). Communication/Negotiation Techniques That Work! PMI Global Congress 2004, North America, Anaheim, CA.

Baker, E. (2006, October). It’s All About ME (Managing Expectations)! PMI Global Congress 2006, North America, Seattle, WA.

Baker, E. (2007, October). You’ve Got WAY Too Many Issues! PMI Global Congress 2007, North America, Atlanta, GA.

BrainyQuote (2010, July). Albert Einstein Quotes [Electronic Version]. Retrieved on 20 July 2010 from

Bull, R. C. (2008, October). Project Leadership: The Next Step in Project Management On the Way to Becoming a Master Project Manager™. PMI Global Congress 2008, North America, Denver, CO.

Cole, A. (1995). Runaway projects: cause and effects. Software World (UK), 26(3), p. 3-5.

Cook, C. R. (2005). Just enough project management. New York, NY: McGraw-Hill.

Mycoted, (June 2007). Crawford Slip Writing [Electronic Version] Retrieved on 8 July 2010 from

Project Management Institute (PMI). (2008). A guide to the project management body of knowledge (PMBOK® Guide)—Fourth edition. Newtown Square, PA: Author.

Santayana, G. (1905). The life of reason, Volume 1, Reason in common sense. New York, NY: Dover Publications, Inc. Quotations (2010). Dr. Linus Pauling quotes. Retrieved on 8 July 2010 from

Verzuh, E. (2009). Team leadership. Seattle, WA: The Versatile Company.

© 2010, Ernest Baker, PMP
Originally published as a part of 2010 PMI Global Congress Proceedings – Washington, DC



Related Content

  • PM Network

    Life Hacks member content open

    Project practitioners from all over the world answer the question: How do you apply project management skills in everyday life?

  • PM Network

    Strategic Deficits member content open

    By Ali, Ambreen CIOs know what's needed to deliver value. But those expectations don't jibe with the reality of organizations' strategic capabilities.

  • PM Network

    Leading the Data Charge member content open

    Once a novelty, chief data officers (CDOs) are now the new normal.

  • PM Network

    Shazlee Rosli member content open

    PM Network interviews Shazlee Rosli, Project Management Office (PMO) Strategic Planning Manager, COO office, Hong Leong Bank Berhad.

  • PM Network

    Vent session member content open

    Whether it's last-minute change requests or oblivious stakeholders, recurring problems can push project managers to the edge. We asked practitioners: What's your biggest project pet peeve?