Managing Stakeholder Expectations for Project Success

A Knowledge Integration Framework and Value Focused Approach

Ori Schibi

• Publisher: J. Ross Publishing
• Year: 2013
• Print ISBN: 9781604270860
• eBook ISBN: 9781604277456
• Edition: 1
• Topic: Business
• Subtopic: Project Management
• Index: Business

Managing Stakeholder Expectations for Project Success provides a practical approach to managing those things that matter most for project success—stakeholder expectations, communication, risk, change, and quality—so that scope, schedule, and cost end up on target and the project's intended benefits for the organization are realized. This unique desk reference shows how to utilize the best practices, concepts, and methodologies found in PMI's PMBOK Guide, along with a few concepts from APMG's PRINCE2, and leverage them in the context of organizational challenges and project realities. It features new methods for successful project management that focus on understanding and managing stakeholders' needs and expectations, communication, time management, and organizational politics and culture. The book's content and design also make it a valuable resource for PMP certification.

1

---

The (Sad) Reality of Project Management

---

This chapter does not deal with any one specific aspect of projects; rather, it provides ideas and solutions for the associated challenges that surround them. Chapter 1 can be viewed as a gateway to the rest of the book, providing context through a discussion of the current state of project management. It articulates many of the challenges that we deal with and points out some of the main flaws in our current way of delivering projects.

THE REALITY IN QUOTES

We begin by introducing a series of quotations or statements commonly uttered by various stakeholders about their projects. These statements are relevant to most project environments, and they appear in relation to each chapter’s theme and concepts. The expressions represent situations, challenges, and issues that project managers (PMs) regularly face (either by hearing them or by using them) in project realities. They are commonly used, perhaps too commonly; for the most part, they represent misconceptions, misrepresentations, or misunderstandings of the team, situation, project, or even organization.

Usually these statements also lead PMs and other stakeholders to make the wrong decisions. Some of these quotations may sound silly; others are downright ridiculous; but, due to their “popularity,” they all articulate the state of our project realities and may provide some insight into why so many PMs often fall short of delivering on the promises and commitments of their projects.

Each expression is followed by a short discussion about what it really means and its potential impact on a project. It is fair to assume that these things are mostly said—not due to ignorance or carelessness—with good intentions, in an attempt to improve things and make stakeholders feel better. At times, it is apparent that these statements combine reality with hope and wishful thinking. The discussion that accompanies each quotation also provides some approaches for dealing with the true meaning behind what was just said and opens the door to becoming better prepared to take appropriate action. Many of these observations will resonate with you and, in addition to the explanation they offer, the book addresses the challenges they introduce and how to overcome these challenges. Some of the quotations are presented in this chapter; others appear at the start of each subsequent chapter they pertain to.

“Whose fault is it?” Not mine. It is human nature to look for someone else to blame when something goes wrong. However, is it really the first thing we need to do? When something breaks down or goes wrong, we first need to try to address it and then fix it. Pointing fingers and blaming others is not constructive and does not add value; it demoralizes the team and, above all, does not solve the problem at hand. Assuming that most project problems are not a result of sabotage, it would be much wiser to channel our already limited resources into finding a solution. Investigating where the problem originated and by whom will have to take place after we fix it so that we can learn from our mistake, move on, and avoid making the same mistake again.

At times, the best candidates for solving a problem or an issue may be those who are “at fault,” since they might have the specific knowledge and context to fix it. Removing them from the project will leave us shorthanded, resulting in additional work for those remaining—potentially without the specific expertise to help in the recovery effort. Organizations tend to be quick to remove PMs when things do not progress according to plan. While the PM’s leadership skills and ability to drive the project forward are paramount to success, too often it is not clear whether the problem actually is the PM. Replacing the PM may not improve things at all, as we are merely substituting a person. In fact, obtaining a new PM may introduce new risks and cost/time. In addition, it will take even more time to bring the new PM up to speed to the point that this person actually adds value. At the end of the day, there is a chance that the new PM may end up facing the same challenges as the predecessor did, but now the project is further behind and has a new PM who probably lacks experience and expertise.

“This project is a top priority.” Many PMs hear this, but before long, it becomes clear that words are cheap, and there are other projects in the organization that are also labeled “top priority.” When people hear that their project is a top priority, they should expect to see evidence to support it—for example, relevant resources are allocated to their project in a timely manner. When these conditions are not present, it quickly becomes apparent that the project is not really a top priority, and the onus is on the PM to address this issue and set the stakeholders’ expectations that, without the appropriate level of support, the project objectives cannot be delivered as intended.

“I don’t have time.” Time management is related to one’s ability to prioritize what needs to be done. Virtually everyone is pressed for time, and it comes down to figuring out how to manage those things in such a way that the more urgent things get done first. It sounds simple, yet most people simply do not know how to do it. It makes it even more challenging when additional work is delegated onto one’s plate with no indication about its priority in relation to other tasks or any additional time to perform it.

“There is no need to conduct stakeholder analysis. I have worked with them before.” There is growing recognition of the need to conduct stakeholder analysis and to revisit it several times throughout the project. Even if the PM has previously worked with certain team members and stakeholders before, it does not mean that their dispositions, views, or needs are the same as they used to be. Opinions, circumstances, views, agendas, and drivers change, and even previous allies may turn into foes from one project to another. The main challenge with conducting stakeholder analysis is that PMs do not have the time or capacity for it and as a result, simply do not do it in most cases. The results of the analysis should remain essentially confidential, since there may be sensitive information and views about our colleagues, team members, and other stakeholders. As part of the stakeholder analysis, PMs should also measure each stakeholder’s ability to influence the project and their own ability to work with the stakeholders—to reach them, influence them, and change their minds if required.

“We will figure it out later.” During the planning phase, or in early stages of the project, when PMs come across problems and challenges regarding resource and skills shortage, it is important to alert stakeholders, but they often say that there is nothing that can be done about it now and a solution will be found later on. Unfortunately, it is unlikely that there will be an easy solution to these problems later in the project; furthermore, by then the project is probably going to struggle to meet even its least challenging commitments.

“This is not my problem to worry about.” There are many things in a project that are out of the PM’s control, such as vendors and other external deliverables, dependencies on other projects, and cross-project risks. When PMs voice their concerns about these matters, the response is often “it is not your problem to worry about,” which is a mistake. There is a difference between not having control over certain things and failing to address them. PMs cannot micromanage other projects or try to solve their issues, but they do need to communicate with external stakeholders to learn about situations that may affect their own projects downstream. This involves building relationships and a collaborative environment that enables a mechanism to address these challenges in a timely manner. Hiding behind the silo-driven thinking of “this is not my problem” will lead to significant problems later.

“Do it just this time. It’s an exception.” This statement represents special requests that stakeholders make, with the most common ones being requests to do something differently than it should be performed or to include additional scope or features that were originally left out of the requirements without using the change control process. These requests may be accompanied by “I will view it as a personal favor,” or “we go way back.” It reiterates the importance for PMs to understand the project success criteria, manage the trade-offs between them, and let no external (unrelated) factors interfere with success considerations.

“But I sent you an e-mail.” In the early 1990s, e-mail was viewed as the best thing since sliced bread. Since then, many e-mails have been sent and received, and e-mail has become a problem in itself, creating many misunderstandings. E-mail and other forms of written, informal communication may be convenient but cannot replace the basic need for people to talk to each other. It is not enough to send an e-mail and hope that the recipient receives, reads, understands, and responds to it. There are too many potential failure points in any type of communication, and e-mail fails to provide safeguards for most of these. In fact, it introduces potential failures and misunderstandings in the form of tone, style, structure, and at times, intent. To foster effective communication, it is important to introduce a set of best practices for e-mail conduct so that e-mail becomes a value-producing tool, as opposed to one that is misused and falls short of delivering its potential value.

“Just add some resources and do it faster.” Not all project delays can be fixed by adding resources. Even when resources are available to perform the work, which is unlikely, it does not follow that they will add value. When sitting on a delayed flight, no one proposes that the airline call in an additional copilot in order to fly faster and arrive on time. The reality is similar for projects: there are activities that, even if the organization adds resources toward performing them, may not yield any gains to the project, despite adding costs. Due to the law of diminishing returns, adding resources may backfire and slow the process down or lead to more defects. The PM needs to determine whether the situation can benefit from adding resources or other trade-offs need to take place in order to meet project objectives.

NOT ENOUGH OF . . .

Similar to the “reality in quotes,” there are some statements that are not said enough in projects and organizations. There are some exceptions to this rule, but not hearing these statements enough serves as an indication that something is not working the way it should. For any one of these examples, PMs need to ask ourselves: When was the last time we said one of these sentences to one of our colleagues? When was the last time we were on the receiving end of one of these comments? Here are some examples of things that should be said more often, in the hopes that they will become part of the culture in more organizations. Each example is followed by some background, and the book will address ways to help make these expressions more commonly used.

“How I can help you?” We are all overworked, have significant resource constraints, and are in a constant reactive mode to issues, problems, and crises that take place in our projects. It is challenging and complicated enough to handle our own workload, let alone offer help to someone else. However, our skills, knowledge, experiences, and access to resources may be relevant for someone else in the organization and can be used to their benefit. Building a culture of helping others will make us much stronger as a collaborative team and in turn, will encourage other team members to reciprocate. It is not about creating a utopia or a fantasy world, but about showing genuine care about each other, sharing success across the organization, and realizing that: sometimes I may be doing the helping, and other times I will need to leverage someone else’s capabilities to my benefit.

“Thank you. I appreciate your effort.” (Or: “Good job.”) We are often quick to complain or tell someone that they did not do what we expected, but what about a good word? I once made a comment in a project meeting to one of the resources, showing appreciation for his effort, only for that person to approach me afterward to tell me that it was the nicest thing anyone had ever told him in that company over his 10 years there. There is no need to single out people, to compliment the same people over and over again, or to compliment someone for no reason, but a good word does not cost anything and goes a long way in building confidence, strong relationships, a sense of pride, collaboration, and a positive atmosphere.

“What can I do to help us work better together?” Many of us do not really have meaningful conversations with our colleagues at work. We talk to each other and see each other in meetings, but the conversations are not meaningful. We often address issues, deal with problems, report status, or ask technical questions, but usually this is where it ends. There are no meaningful conversations about how to work better together or how to change the way things are now. I once had a new manager that, when she got to her new position, said one of her first orders of business was to cancel the regularly scheduled one-on-one meetings with her team members. Her reasoning was that she did not have time for it, and it was no surprise that it weakened our team and our ability to perform. This was because our manager no longer had the insight necessary to identify underlying issues and to understand, firsthand, what team members were going through.

She essentially eliminated her best way to know what was going on with her team, and by using the excuse of a lack of time, she slowly relinquished her control, along with her ability to know about and proactively deal with situations, challenges, and other team interactions. Informal one-on-one meetings with colleagues and team members are priceless—they establish good working relationships, open the lines of communication, and even spark friendships. They allow us to address issues informally and collaboratively and to improve our ability to work together and understand each other. An attempt to reach out and try to help or look for areas of improvement will most likely trigger a reciprocal reaction and create a positive dynamic with our colleagues.

“We need to do some team building.” This is not something we fail to say to each other; it is rather an observation that we do not have enough team building in our environments. Whether it is a time or a budget constraint that inhibits team building activities, in many organizations, employees find it hard to recall the last time the team went out together for lunch. It does not have to be fancy or paid for by the company; it is enough just to go out, as a team, to celebrate a milestone or alleviate some tension. During any type of team building activity, there is an opportunity to learn something about our colleagues, which may help us to build better relationships with them. With a friendlier atmosphere among our team, it is more likely that individuals will seek win-win resolutions to situations and try to work with each other, rather than against one another. This is not about turning our workplace into a country club and going for a team lunch e...

Table of contents

• Cover
• Title Page
• Copyright
• Dedication
• Acknowledgements
• Table of Contents
• Preface
• About the Author
• Introduction
• Web Added Value™
• CHAPTER 1 The (Sad) Reality of Project Management
• CHAPTER 2 Project Complexity and Readiness Assessment
• CHAPTER 3 Culture and Politics: The Organization’s Pillars and Speed Bumps
• CHAPTER 4 Understanding Stakeholders and What They Want
• CHAPTER 5 Connecting Success and Constraints
• CHAPTER 6 Assumptions: The Project Manager’s Best Friends
• CHAPTER 7 Managing Those Things That Make a Difference
• CHAPTER 8 Managing Risk Effectively: What’s Missing from Current Risk Management Methodologies
• CHAPTER 9 Learn What Quality Means
• CHAPTER 10 Managing Project Change
• CHAPTER 11 Designing and Managing Project Communications
• CHAPTER 12 Organizational Influences
• CHAPTER 13 Integration: Putting It All Together