Project Management Tools and Techniques That Work!
by Ernest Baker, PMP
Many project managers feel as if the deck is stacked against them, and that they are playing a game where a successful outcome is difficult to achieve. And there are some situations outside of the PM’s control that contribute to this thought. However, 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 session is designed to be an interactive one presenting 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. The 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.
Introduction
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 aid the project manager, but many do not offer the practical tools and aids that working 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 “what’s” and “why’s” of project management, and even does a good job listing some effective tools and techniques for performing project tasks. What’s missing is “how” the tools are used effectively in various project situations. How do real-life project managers perform these activities successfully? This paper will entail a segment of some tools (thirteen to be exact) that are designed to facilitate dealing with some of the challenges facing project teams, and provide a context for their use.
# 1 – Getting 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. This is especially true for the project team, and there are many studies that address the importance of a “shared vision” among team members and about how the appropriate number of skilled resources available at the right times being a major factor 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, and not chickens, on his or her project. As the leader of this team, the project manager also better 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 amongst the members where the team shields itself from outside criticism by isolating the team from other stakeholders and develops an “Us” vs. “Them” outlook. Dealing with this problem requires that you embark on a program to build team member commitment, and that 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, etc. Establish these rules with the team early, while they are still in the Forming stage. You will need to enforce 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, responsible for or involved in..
-
Create task and deliverable completion requirements. Make sure that each person knows what it means to be done regarding these assignments.
-
Share ownership with individual team members. Once the team gets through the Storming stage, and is beginning the Norming 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 vs. Lessons Learned
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 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 decide to move the rake? Hopefully, the answer is one time!
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 decides to fix the problem? Would it be more than 1? 10? 100?
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 Lesson 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 5 risks were on her project.” The problem with the “Hey, Mary” database is that often Mary is not available, or 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 those 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, or 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 of handling these problems.
-
Change processes that don’t work, or add no value. Know when it’s time to do something different (move the rake).
-
Make Lesson Learned an agenda item for each status meeting. Ask the team “What did we learn this week that makes 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 this 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 be 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 as everyone involved in the project drops everything and focuses their full effort on getting the project completed. The project team works hard for long hours, often involving weekend work, and through a Herculean effort, manages to bring the project in on time. The PM 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 poor planning and execution earlier, 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 besides the obvious one focused 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 effort 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 to create pre-planned “Focus Days” in the project schedule. Focus days are days in the schedule where you focus the team work 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. It will take careful scheduling, but the benefits of improved communication, higher quality and the team 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) It is intended to be a way to gather ideas from a large group, and break them out for subsequent analysis or offline review. It has other idea generation applications as well. 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 – we want to create as large a list as possible. Dr. Linus Pauling has said “The way to get good ideas is start with lots of ideas, and throw the bad ones away.” (Thinkexist.com, 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 hone it down to the significant few upon 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, the idea. 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 where an index card, sticky note or other slip of paper is written upon, 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’s the process:
1. Hand out Index cards, or slips of paper, one per team member. Sit 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 – 20 seconds, tell the participants to stop writing and pass their card/paper to next person clockwise.
4. Give each person a few seconds to look at the card or paper passed to them. Then, ask each person to add 1 or 2 new items to ones listed.
5. Keep the process of passing the slips, and adding to them, going for no more than a total of 3 minutes.
This tool has a lot of benefits:
1. It’s a team process. Team members need activities like this 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 the other team members. No matter how crazy an idea appears at first blush, there is no telling what effect that idea may have on another team member who may look at options now 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 upon.
Obviously, the results of this process are just step 1 of brainstorming. The second step would be to look at the ideas generated and reduce them to the significant few that will acted upon.
#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 in which 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 at the start is a good idea! 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 to meeting the project objectives, the success criteria for the project. Winning is about meeting those objectives, and project managers are those appointed to win, to achieve those successful outcomes. And I think we would all agree that establishing what a successful outcome is a valuable step towards actually achieving these objectives.
How do you, or others in your organization, define project success? Or project failure for that matter? Is it really just the criteria On time, On budget, Within Specifications? Are those the only criteria 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 delighted customer? Is that the project a failure? How important are Stakeholder expectations to your view of project success?
It has been my experience that many projects deemed a failure were nothing more than a failure to set and manage the criteria upon 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 involved in a project the more this bad situation can be exacerbated. It has been said that a camel is a horse designed by committee, and I have seen my fair share of project teams deliver a camel to 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 of play printed inside the box cover! Why don’t we adopt the same principle and establish these rules for success before we play?
How do we define success and failure on a project? Any definition that does not include customer acceptance and satisfaction would not be an adequate one in my mind. The triple (or sextuple) constraint model is a good start, but remember that we use this 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 a 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 large 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 2 tools that organizations use 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 measure in a definitive way 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 October 1, 2011, then we’ll know unequivocally if we succeeded on our time objective on that date. The same goes for cost objectives. If our budget was not to exceed $1million, then we’ll be able to see how we did on that objective when the project finishes. It’s the quality objective that I often find the thorniest one to define and part of the reason there is that 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, that I achieved the success criteria. I don’t want to debate that. Be wary of imprecise or fuzzy measures of success since there will be no way to measure them, unless you define precisely what the fuzzy term means.
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 1 minute at least 90% of the time.” The right side of that equation I can measure 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, so realize that the MEDS means more than the obvious. At the time I was asked, MEDS was short for Manage Expectations/Defend Scope, but I’ve lately taken to change the idea to Manage Expectations/Define and Defend Scope (MEDDS).
Project Scope Management is one of the areas where projects typically go off the rail. 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, or specification, or scope creep, many projects suffer from a failure to manage the scope of the project. And 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’re trying 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 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. 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 they sign. This is a good thing, as this process can help alleviate any misconceptions as to what is in or out of scope.
2. Be explicit about scope exclusions. Planning a project is like ordering off the a 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 will get everything listed, and 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:
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.
Where problems occur, however, is when one or more sides are out of balance. For example, we may have poorly-defined processes, processes that produce errors or undesirable outcomes. Rather than fix the broken process, often we 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 where Agile and Lean dominate any discussion of business processes, it is imperative that project teams use the level 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 3 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 porridge (why is there always porridge in fairy tales?), the chairs and the beds. Papa Bear’s stuff is “Too hot!” or “Too hard!”, while Mama Bear’s is “Too cold!” or “Too Soft!”. But Baby Bear’s stuff is always “Just right!” Not too little or too much, but “just right”. And that’s the secret to figuring out how much project management a project needs. Not too much, and 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 on 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 if this information is shared.
#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 to address 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 sometime. I use the phrase “Let’s Pretend” to initiate any discussion involving the future. 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 to 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, since you’re not really saying the problem exists, but forcing a look at it anyway. Plus, 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, in 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. Options and choices take time because of this fact.
When asked for an answer to any question regarding the project, the conditional response, “It Depends”, is, in my mind, 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, and that is a good thing. By asking the “On what?” question, the stakeholder has opened the door to a discussion on 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 tradeoffs necessary in any type of baseline change. It depends allows one to sketch out the various scenarios that may occur should we implement a change in the project plan, and the agreed upon success criteria.
#11 – Product on a Page
It has been said that a camel is a horse designed by 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 wishes of the customer?
A technique I use is 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 for the project. In the marketing piece, they focus on 4 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 perspective)
4. A visual. The visual could be a mock-up of the web site, 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 to make sure that the team 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 perspective, adds it vision and understanding, 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 achieve consistent high quality over time?:
Technique 1 – Set the quality standards unachievably high. Then, whatever we end up with will be higher quality than if we set the bar low.
Technique 2 – Set the bar to minimum standard. When the standard is reached, raise the standard to a higher level. Continuously raise the bar each time the standard is met.
Technique 1 sounds good 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. The 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 changing events in our project, but many times fail to correct the faulty or inefficient processes that lead us there. Part of Act is looking at what works and 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, Page1).
A simple tool I like to use is a technique called Plus/Delta (+/?) (Verzuh, 2009, p. 130). Plus represents all the things we have been doing well as a team, and need to more of. Delta represents all the things that are not working and we need to do differently the next time. I often recommend that teams do Plus/Deltas 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 your manage stakeholder expectations from concept through delivery.”
What’s your reaction to the above quote? Would 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, then 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. This translates to defining and defending scope, identifying, analyzing, planning responses and monitoring and controlling risks, proactively planning and delivering Quality, etc. 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 basis of their estimates, as part 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 set is that timely submissions is not important – it’s OK 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 that we would call “soft skills”. Negotiation techniques, influencing skills, active listening, conflict management, etc., would be the areas where increased fluency would 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, etc.) are up to date and that you continually improve them through use.
3. Project Management is a recipe, not a guarantee. Since 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.
Summary
This paper focused 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 or analogy, or some pithy statement to help remember the concept. Finally, hints and recommendations were given on tools and processes that will help with creating the right mindset or correct the problems identified. These tools or tips were listed along with suggestions for their use.
References
Baker, Ernest (2004, October) Communication/Negotiation Techniques That Work! PMI Global Congress 2004, North America, Anaheim, CA.
Baker, Ernest (2006, October) It’s All About ME (Managing Expectations)! PMI Global Congress 2006, North America, Seattle, WA.
Baker, Ernest (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 http://www.brainyquote.com/quotes/quotes/a/alberteins133991.html
Bull, R. Camper (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, Vol. 26, No. 3
Cook, Curtis R. (2005) Just Enough Project Management. New York, NY: McGraw-Hill
Mycoted, (June 2007) Crawford Slip Writing [Electronic Version] Retrieved on July 8, 2010 from http://www.mycoted.com/Crawford_Slip_Writing
Project Management Institute. (2008) A guide to the project management body of knowledge (PMBOK® Guide) (Fourth Edition). Newtown Square, PA: Project Management Institute.
Santayana, George (1905) The Life of Reason, Volume 1, Reason in Common Sense. New York, NY: Dover Publications, Inc.
ThinkExist.com Quotations (2010). Dr. Linus Pauling quotes. Retireved on 8 July 2010 from http://thinkexist.com/quotation/the_way_to_get_good_ideas_is_to_get_lots_of_ideas/181151.html
Verzuh, Eric (2009) Team Leadership. Seattle, WA: The Versatile Company
Filed under: Architecture, Design Tagged: Articles, Business, Cool, George Santayana, HBR, Lead, Leaders, Leadership, management, MBA, Metrics, PL, Project and Program Management, Project management, Project Management Institute, Project manager, Ref, Success, Team, TL
Written by Visitor Blogs on August 30th, 2010 with no comments.
Read more articles on HBR and Leaders and Project management and Project manager and PL and TL and MBA and Metrics and Success and Lead and Project Management Institute and Project and Program Management and management and Articles and otherSoftware and Business and cool and Leadership and George Santayana and Ref and Architecture and Team and Design.
