It's all about ME (managing expectations)!

Abstract

Everything you do, or don’t do, sets an expectation for future behavior. In today’s project environment, it is critical that stakeholder expectations be consistently and frequently managed, to insure a successful outcome. Working with stakeholders to define what a successful outcome is step one of the process. Establishing the rules governing successful and unsuccessful outcomes, and managing to those rules, give the project manager and team the guidelines required to set and manage stakeholder expectations.

In many project contexts, success is defined by meeting the Triple constraint – On Time, On Budget, Within Specifications. This paper will look beyond these objectives and focus on the idea of the project manager’s job really being one of “Expectation Manager” and a “Creator of Options”. We will also present some communication tools, A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) processes and techniques that will facilitate this concept.

Introduction

I imagine that you all do projects in your organization…. and they are all successful with happy customers and joyous end users. In your projects, requirements are well-defined before any planning and remain stable throughout the life cycle, and customers and management alike are extremely pleased with the new product, service or result that your project created. Team members are always working together in harmony and producing the finest deliverables and product and process quality are the highest they could be. Risk is proactively managed consistently throughout the project lifecycle.

Or …, you might be one of those organizations who occasionally experience difficulty in getting the project success criteria established up front and often deliver to less than satisfied customers.

Project Success/Failure

How do you, or others in your organization, define project success? Or project failure for that matter? Is it really just the Iron Triangle 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 it possible to be over budget, late and with reduced scope, but still deliver to a delighted customer? In that particular case, is the project a success? 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. It is their vision of the project, and that of the project team, that often creates the disconnect between what each views as the final product of the project. This gap in vision creates the interpretation of project success and failure among the stakeholders.

Too often, success is poorly defined, or worse yet, defined differently for different stakeholders. How can we possible achieve a successful outcome if we have no idea of what a successful outcome looks like? The only way we can achieve success in this manner is hit or miss or by stumbling upon it by accident. This certainly doesn’t sound like a PMBOK^® Guide process to me (Perform Quality Control, Scope Verification, Close contracts, Stumble on Success Criteria…).

Have you ever played cards with a child? Did you ever win? Me, neither, as the rules for winning are never defined in advance and are constantly being changed to meet the needs of your opponent. I have known project managers who feel the same way about their projects. Fuzzy or inconsistent definition of success is a sure way to failure. Sun Tzu advises never to enter a battle that you can’t win, and that advice applies here.

It is a lot of work to define 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?

One thing I am very clear about and that is the difference between Winning and Whining! It is way too easy to complain about fickle stakeholders, changing requirements and unmotivated team members. It is quite another thing to take charge of the situation and bring about solutions. Project Managers need to confront (problem-solve) any issues or situations that occur on their projects and deal with them. There will be plenty of times where the project manager will inherit a bad situation or problem. It won’t go away on its own – you need to confront the situation, take control and be accountable for the results.

Defining Project Success and Failure

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 constraint is a good start, but remember that we use the iron triangle 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.

A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) has a number of processes that 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.

Many projects get off track due to a failure to utilize these tools to help 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 as soon as possible and take action to deal with it.

It is no secret that having to deal with project issues and problems, as well as all the situations that occur as a result of introducing change into the organization, make project managers feel like outcasts in their own companies. Many project managers feel less than a valuable resource, and it is not uncommon to select project managers on the basis of whose turn it is, or who is busy, or who was late for the meeting. Hardly, following the PMBOK^® Guide recommendations!

With many of my clients, I play a “Word Association” game. You know the game – I say a word or phrase and your write down the first word or phrase that comes into your mind. The phrase that I give them is “Project Manager”. When asked to share their association, many use terms like “leader” or “communicator”, or “organizer”. These all sound wonderful, until inevitably someone comes out with “scapegoat”, “lightning rod”, or “dartboard”. My favorite is “plumber” (work the analogy through!). Needless to say, with these thoughts associated with the job, it is no small wonder that project managers have a dim view of their role!

It is my contention that project managers need a new mindset, a positive view of what their role and responsibility is on a project. This idea is more about proactively dealing with stakeholders and becoming a trusted partner in the project.

Managing Expectations

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 Stakeholders. (PMI, 2004, p 235) According to the PMBOK^® Guide “actively managing stakeholders increases the likelihood that the project will not veer of track due to unresolved stakeholder issues, enhances the ability of persons to operate synergistically, and limits disruptions during the project.” (PMI, 2004, p 235)

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. The job of 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. And, as the PMBOK^® Guide suggests, 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!

With this thought in mind, I ask that project managers change their title to “Manager of Expectations”. Let’s face it, how often are we asked “What are you doing making a project out of this?” as if a project were the last thing on earth required. PMs tend to view their jobs as something less than desirable, and part of that has to do with how they view their role on a project. By changing the outlook to one of expectations management, all reporting, conflict management and negotiating can be viewed in a positive and proactive light.

Of course there is another context that “It’s all about ME” can be taken, and that is that a project manager can focus on what they do control in a project. PMs often mention that they lack the decision-making power or authority on their projects. They focus on what they CANNOT do, instead of looking at what they CAN DO to achieve the project objectives. By taking the phrase literally, project managers can bring the focus back to their actions, and give them the mindset required to get things done.

Change the role and job description to “Expectations Manager” and see how that changes your attitude, self image and effectiveness. Approach each issue, constraint, and complaint as an opportunity to SET and MANAGE Expectations!

Setting Expectations

Everything you do, or don’t do, creates an expectation. Every action you perform on a project will create an expectation of similar actions in the future. You might require that team members document their assumptions as part of the planning process. Reinforcing this idea at every team meeting will make it far easier to develop the consistent and ongoing risk management attitude 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?

To illustrate what are the extreme-case scenarios regarding scope management, imagine that a customer has requested additional scope on a project whose baselines have already been set. The client asks, “Can I add this additional (Feature/Function)?” Let’s examine the potential answers:

Yes (Unconditional) – By unconditionally saying “Yes” to all requests for change (and without employing change control), you are creating the expectation that there is no such thing as change control, and at any time in the project, one can make changes to the requirements. And the cost and schedule impacts of these changes will be absorbed by the project team. We’ll do it on our time and on our dime. And it will happen over and over, with no end in site. This situation creates what I call the Road to Hell (RTH), and is difficult to correct once the expectation is set.

No (Unconditional) – By unconditionally saying “No” to all requests for change, you will not have a scope creep issue. Another thing you probably won’t have is a job, since many stakeholders look at project managers who always say “No” get portrayed as “difficult to work with” or “Not Team players”. I once worked with an individual that we nicknamed “Dr. No” because of his penchant for the word. In my vernacular, saying “No” all the time could be a Career-Limiting Maneuver (CLM).

It Depends – This conditional response is, in my mind, the only one that makes sense in a project environment. 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 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?” questions, 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.

The above dialog leads to my next portion of the project manager mindset, namely that the project manager needs to be generating alternatives for the stakeholders so they can make informed choices. Instead of viewing the PM role as the “Yes” or “No” person, look at the job as the “Creator of options”. Work with stakeholders to help set expectations by generating some alternatives and working towards developing the desired choice.

PM Tools for setting/managing expectations

A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) suggests many project communication tools that are valuable in helping create and manage stakeholder expectations:

Project Charter – this document provides the authorization for the project and gives the project manager with the authority to begin the planning process for the project. Quite a few other pieces of important information may also be listed in the charter, things like business need and business case for the project, stakeholder influences, assumptions and constraints.

Project Scope Statement – the PMBOK^® Guide lists 2 versions of this progressively elaborated document, but the information contained in this document is the definition of the project. Information contained here represents a “common understanding of project scope among the stakeholders”. (PMI, 2004, p 110) Here, such things as the project objectives, product acceptance criteria, and configuration management requirements are documented.

Responsibility Assignment Matrix (RAM) – this chart, often called a RACI chart due to the letters used in the grid, is used to show the connections between the project team members and the project deliverables (or work required). Project Team members, at the first team meeting, all have the same burning question on their mind – “What am I doing here?” A RAM is a good way to set (and manage) team member expectations.

Project Communications Management Plan – this plan documents who needs to know what, when do they need to know it, and how do you plan to get it to them during the project. A list of stakeholders, and their information requirements, as well as the communication media and methods, is defined in this plan. An added bonus that many project managers find with developing a good Project Communications Management Plan – it can often be re-used on future projects!

Project Risk Management Plan – another eminently re-usable project control document, this plan documents the project team’s approach and processes to identifying, analyzing, planning responses, monitoring and controlling project risk. It represents the “ground rules” or standard operating procedures (SOP) for dealing with risk on the project.

Project Quality Management Plan – this document lists all the quality planning, quality assurance and quality control processes that the team will use to make sure that the project’s product, service or results conforms to the organization’s quality policy. Again, the potential for re-use is very high, if the plan is initially well-constructed and improved with use.

Change Control and process to perform it consistently – the PMBOK^® Guide lists this process as a subsystem of the overall Configuration Management System, and is used to define how changes to project deliverables and documentation are handled. Inherent in the creation of this system is the rules for implementation (governance?) of the system. In other words, if no one uses the system, why bother documenting it!

Team Norms (SOPs) – I have always found it easier to enforce processes and procedures once they have been defined rather than create new procedures on the spot. This concept is particularly important in a team environment. Explicitly stating such procedures as how to conduct team meetings, how to report status, and how to deal with differences of opinion, can go a long way in setting the proper expectation for team behavior.

Managing Project Sponsors

The PMBOK^® Guide defines a sponsor as “The person or group that provides the financial resources, in cash or in kind, for the project”. (PMI, 2004, p 376) Needless to say, this individual, or group, represents a stakeholder whose expectations need to be carefully managed. Even in those situations where the sponsor is a customer paying for the project, it is important for the project manager and sponsor to be on the same page continuously throughout the project.

Yet, I hear from many project managers that they never have much interaction with their sponsor, due either to political issues or time constraints. This puts the PM at a disadvantage when it comes to managing expectations, and dealing with situations before they become problems. Project Managers need to manage up, as well as down, and out to other managers, to be effective.

A good way to begin the sponsor management process is to have an initial face-to-face meeting with the sponsor. During this meeting, there are several things that you want to come to some agreement on:

• Project Manager Roles and Responsibilities
• Limits for PM authority, if any
• Project Sponsor Roles and Responsibilities
• Communication preferences – what and how to communicate with one another
• Communication frequency – how often and when to communicate
• Risk Utility position – Is your sponsor risk seeking, risk neutral or risk averse?
• Sponsor tolerance for variance reporting

One of the questions that I know a fellow project manager asks his sponsor is, “When do you WANT to hear the bad news?” Although this is a difficult question to ask (and I wouldn’t make it my FIRST comment to my project sponsor), it is necessary to clearly establish the parameters surrounding a crisis situation on a project. I have been around enough senior managers to know that they one thing they like least is surprises! And worse yet, finding out about it from someone other than you!

Ideas that help manage expectations

Let’s Pretend

Let’s Pretend is a tool that was taught to me by management consultant Al Turrisi of Turrisi & Associates. Let’s Pretend takes the conversation way into the future, to the point of some issue or confrontation, and tries to develop a solution today, in case the issue or confrontation were to appear. Most projects have their usual points of contention or issues that show up in mid-projects. Many of them make the Top n Risk or Issues list. Let’s Pretend forces the situation to the future, at the point in time where the risk or issue is realized, and asks the team to develop a response today. In practice, it sounds like this:

It Depends

We’ve already explored how this tool can be effective in beginning the discussion of how to effectively introduce the idea of change control to stakeholders. It can also be a useful tool in managing team member expectations as well.

Know the chainsaw

Project Management texts will often use the analogy of a juggler to illustrate how a project manager juggles the 3 sides (Cost, Time, Scope/Quality) of the triple constraint. I don’t juggle, but I’ve been told that the juggler needs only to focus on the ball in flight to keep going. I once saw a juggler who juggled an apple, a bowling ball, and an operating chainsaw! I have to think that this juggler focused on one object more than the other two!

Taking the analogy back to the triple constraint, isn’t one of them more like the chainsaw than the other two for your current project? Are both you and your customer and your project team in agreement as whether budget, schedule, or quality is the “chainsaw” for your project? Wouldn’t this analogy help them in determining this and help you balance the trade-offs?

Avoid surprises by using CRAP!

I can thank a client of mine for this little mnemonic device! I was visiting this contact at my client’s site, and he kept bemoaning the fact that the level of project management maturity at his organization was “mud-sucking level 1”. He kept repeating that what he wanted were “Consistent, Repeatable And Predictable” processes. Being an IT guy, and always dealing in acronyms, I was intrigued by his constant reference to these type of processes. In the end, I promised to help him develop more CRAP than he could imagine!

The choice of acronym notwithstanding, isn’t the beauty of following processes is that you get consistent, repeatable and predictable results? Isn’t that our goal in following PMBOK^® Guide processes? So, the next time someone says that all this project management stuff is just a bunch of crap, you can wholeheartedly respond “Absolutely!”

I get the feeling….

I use this tool to confront without being confrontational. As you know, confrontation (or problem-solving) is the recommended manner in which resolve conflict. It is also the best way to get concerns out in the open, without making it sound like an indictment of the other party. Basically, you preface your concern with the phrase “I get the feeling …” You’re not accusing anyone –they’re your feelings!

Project Managers - they “DO” something!

When faced with an obstacle, many individuals will simply stop making progress until the obstacle is removed for them. What differentiates good project managers from this group is the ability to find a way around, or if necessary through, the obstacle to get the job done. That’s what good PMs do – focus on the end game and drive towards it.

Unfortunately, this attitude (ability?) often makes the PM less than popular. Projects themselves introduce elements of change, and many are resistant to change. The head of that project, the individual driving the change, is often seen as irritating. If one was looking to become the most popular in their organization, I would not recommend project management as strategy. But again, the job of project management is not to become popular or well-liked. The job is to get things done!

Train others how to interact with you

I firmly believe that people will treat you in the manner that you allow them. When you encounter those situations where you are treated the way you prefer, then you need to reinforce that behavior. Similarly, if someone acts in manner that you feel is inappropriate, then you need to correct that behavior. As they say, “Fool me once, shame on you. Fool me twice, shame on me!”

With this thought in mind, I think that it our job to train others how to act with us. Set expectations, set ground rules, and reinforce them consistently. This may not completely eliminate bad behavior, but it sure will reduce it. Look at each instance of bad behavior as an opportunity to take corrective action. Remember, if others misbehave, and we allow it, it is our fault, not theirs. They’re only doing what we’ve trained them to do.

Where you sit is where you stand

Andrew Schlam (PMP), an associate of mine uses this term to illustrate how people’s opinions are determined by their role at the time. Have you ever noticed that a person’s position on a particular topic is often governed by the impact that topic has upon their specific situation? For example, have you ever noticed that many of the negative stakeholders on your project are found in the area most impacted by your project? People do things for their reasons, not yours.

In another application of this idea, have you ever noticed a change in attitude towards workers once a new manager has been promoted? The attitude of the new manager has changed – he or she is now viewing things from a different chair. Understanding this idea will help when it comes to understanding stakeholder’s stance on a particular issue or concern. Try to explore the root cause of their stance, and see what you can do to manage that expectation.

Walk towards the pain!

A friend of mine, Steve Potter (PMP), coined this phrase to illustrate the idea that where’s there’s smoke, there’s fire. It goes along with the concept of confrontation as a way to solve problems, but gives a neat visual and catch-phrase that you effectively use with your team.

Stay on your MEDS!

When giving a presentation once, I was asked if I could recommend ONE thing that I thought would best help a project manager become more effective. This phrase is what I came up with. By now, you have discovered my preference for acronyms (and aphorisms), and realize that the MEDS means more than the obvious. At the time, MEDS was short for Manage Expectations Defend Scope, but I’ve lately taken to change the idea to Define and Defend Scope (MEDDS?).

I find that a great area of expectation management surrounds project and product scope. As project managers, we spend a great deal of time dealing with scope issues, and many of the stakeholder concerns revolve around scope. This phrase attempts to deal with both managing expectations and dealing with scope. Defining scope is self-explanatory, but by “defending” scope, I mean that all scope changes go thought the scope change control procedure outlined in the Scope Management Plan. Many project issues go away when good scope management is applied.

Summary

This paper focused on the idea of the project manager’s job really being one of “Expectation Management”. Like Risk Management, Expectation Management is Project Management, and special care should be taken by the project manager in managing the expectations of all stakeholders on a project.

Expectation Management is job #1 for a Project Manager

(It’s all about ME!)