Running with scissors

Abstract

Project stakeholders have expectations. When those expectations conflict, project managers should be wary of potentially dangerous situations. They must address and resolve the conflict, or run the risk of injury to both the project and themselves.

Since the underlying source of the conflicts is not always evident, project managers and teams need to examine relationships between issues and motivations of the stakeholders through interpersonal skills, such as resolving conflict, overcoming resistance to change, and building trust. Three scenarios of real-life projects are described and analyzed, to demonstrate the usage of various techniques for managing conflicting expectations, with a proportionate level of project success.

Introduction

As children, we are told, “Walk slowly when you carry scissors,” in order to protect us from harm. Similarly, as project managers, our preference is for clear-cut direction so that we can ensure the safe delivery of our projects. Then reality intercedes. The sponsor may be adamant that the budget is the priority, while the user group is intent on fulfilling all of their requirements, and the project team is focused on achieving the schedule. All are valid perspectives of legitimate stakeholders. What is a project manager to do?

To start with, assorted tools and techniques are available for managing stakeholder expectations, including communication methods and interpersonal skills. Unfortunately, expectations on projects frequently conflict. When they do, understanding the motivations of stakeholders can assist in the work of finding a resolution. If there is resistance to change, bringing concerns into the open may foster a climate where trust can be established and underlying issues addressed. Otherwise, unresolved conflicts can sabotage the success of even the most strategic and well-planned projects.

Examples of conflicting stakeholder expectations will be illustrated using three actual projects which ended with varying levels of success. A key point is the need to identify and reconcile differences early in the project. Support from senior management may be required to clarify the business objectives and consolidate an approach. Finally, using various forms of communication to verify that agreement has been reached, and is maintained, can be instrumental in keeping the project on course.

Background

Whose Expectations Would Conflict?

Who are stakeholders? According to A Guide to the Project Management Body of Knowledge (PMBOK^® Guide)—Fourth Edition, project stakeholders can be either people or organizations. They may be directly involved in the work of the project or simply affected by the project or its outcome (PMI, 2008, p. 23).

After a project team has identified the stakeholders for their project, the next question to be asked is, “What are their expectations?” Once these expectations are ascertained, project teams can classify stakeholders, based on aspects such as their power and potential to influence the project outcome (PMI, 2008, p. 249).

Further to this analysis is the question, “Why might their expectations conflict?” After all, they are all associated with the same project. Regrettably, the outcome that may be viewed as a success by one group of stakeholders may be seen as failure for another. If a city street is scheduled to be widened to allow increased traffic flow, commuters may anxiously await the end of construction while, at the same time, local residents protest against the proposed destruction of their homes. The project manager who is selected to manage this project must recognize the different interests and perspectives of these diverse stakeholders, and the possibility that they may accelerate or impede the successful completion of the project. If we can resolve conflicts between stakeholders throughout the project, we can also increase our chances of completing the project successfully (Robey, Smith, & Vijayasarathy, 1993).

Interpersonal Skills

Having established the possibility that stakeholder expectations will conflict, we need to develop a strategy for addressing these conflicts. The PMBOK^® Guide—Fourth Edition suggests that our objective in managing stakeholder expectations is to be able to meet the stakeholders' needs and address issues in a timely fashion, with the added advantage of increasing the probability of project success when stakeholders understand the project benefits and risks (PMI, 2008, p. 261–262).

The PMBOK^® Guide—Fourth Edition offers a list of tools and techniques for use in managing stakeholder expectations, including the following three interpersonal skills (PMI, 2008, p. 264):

• Resolving conflict,
• Overcoming resistance to change, and
• Building trust.

These skills are used in different ways on projects, depending upon the project manager, the stakeholders, and their respective cultures. Teams in a Western culture might strive for precision in expectations in order to ensure alignment. In other cultures, where the focus is more on balance and harmony than exactness, ambiguity would be the order of the day (Khor & Lee, 2009). Thus, we need to understand the underlying nature of conflict in order to apply any of these techniques.

Sources of Conflict

Before we can resolve conflicts on projects, we need to know the reason for the conflict. Research on conflicts in projects started in the 1970s, and has shown an evolution over the past 30 years that matches the maturing state of project management. In 1975, Thamhain and Wilemon identified the following seven potential sources of conflicts in projects (Brown, 2009):

• Schedule conflict,
• Conflict of priorities,
• Resource conflict,
• Technical conflict,
• Conflict over administration,
• Personality conflict, and
• Cost conflict.

At that time, projects were often conducted within one department of an organization. Consequently, conflicts were focused on practical aspects of the projects. This is in contrast to the following list of the top sources of conflict, developed by Kezsbom in the 1990s, when more complex, cross-functional teams had resulted from the matrix management that was often in place (Lazaridou, 2002-2009):

• Goals and priority definition,
• Personality and interpersonal conflicts, and
• Communication and information flow.

Move forward another dozen years, and we find a third survey that distilled the essence of conflict into the breakdown of relationships between people. Accordingly, Harrison and Lock grouped the factors that cause conflicts into the following three classifications (Harrison & Lock, 2004, p. 287):

• Structure of the organization,
• People's self-interests, and
• Individuals.

We could then surmise that the source of conflicts may not be as easily determined as we might have once thought. It would appear that, while schedule and costs may always be with us as constraints on projects, conflict is centred on the underlying perspectives of the people involved and how they interact. Thus, the motivations of the relevant stakeholders will play a large part in establishing their expectations, and will be key to a project manager's strategy in managing any conflicts between those expectations.

Let us look at two aspects of motivation for human behavior: resistance to change, and trust.

Resistance to Change

Change is at the heart of all projects. After all, the very nature of projects suggests that something is different at the end from the beginning. If we are producing a tangible product, we assume that someone will then use it. If the project delivers an evaluation of business processes, the expectation is that any recommendations for improvement will be implemented. Stakeholders will react differently to these changes, depending upon how the change affects them.

Before asking anyone to accept change, we need to understand how they came to be in their current position. From an organizational perspective, knowing why the current culture exists is a prerequisite for determining the potential direction for its evolution (Morris & Sember, 2008, p. 202). Similarly, if we understand why a person holds a certain view, we can develop insight into how that view could change.

Not everyone will be readily convinced that the changes resulting from a project will benefit them. They may feel emotionally tied to the current state and hesitate from leaping into the new one. Schuler lists the following ten reasons why people resist change (Schuler, 2003):

1.   The risk of change is seen as greater than the risk of standing still.
2.   People feel connected to other people who are identified with the old way.
3.   People have no role models for the new activity.
4.   People fear they lack the competence to change.
5.   People feel overloaded and overwhelmed.
6.   People have a healthy skepticism and want to be sure that new ideas are sound.
7.   People fear hidden agendas among would-be reformers.
8.   People feel that the proposed change threatens their notions of themselves.
9.   People anticipate a loss of status or quality of life.
10. People genuinely believe that the proposed change is a bad idea.

In addition to Schuler's list, resistance can also be due to rational or behavioral reasons (Piderit, as cited by Bolognese, 2002). Regardless of the reasons for any resistance to change, one of the most important means of overcoming the resistance is to listen to the concerns of the relevant stakeholders (Block, 1981, p. 162). These concerns may lend themselves to improvements in project planning, such as risk mitigation. In addition, the project management team, in conjunction with the leaders of the organization, needs to clearly explain both the reasons and the urgency for the change, as well as the impact if the change is not accepted (Carr, Hard & Trahant, 1996, p. 69). This would be in line with the general role of top management, which is not only to establish goals, both for the organization and the project managers, but to provide guidance and support in meeting the project objectives (Verma, 1995, p. 55). When we communicate effectively with stakeholders, we lay a foundation for trust, which can assist in both preventing and resolving conflicts.

Trust

To satisfy stakeholder expectations, we must first understand what those expectations are. Discovery of both the initial expectations, and any changes in those expectations, often relies upon the existence of a good relationship between the stakeholders, the project manager and/or project team. Lewis Ireland's first principle for good customer relationships is to develop a sense of trust (Cleland, 2004, p. 476). If we expand his definition of customers to include all stakeholders, then trust becomes imperative for revealing and managing expectations.

How do we build trust? Burtonshaw-Gunn offers these suggestions (2008, p. 172):

• Go first: lead the relationship by example.
• Illustrate the topic by drawing on relevant examples.
• Listen for what is different, not for what is familiar.
• Be sure your advice is being sought.
• Say what you mean.
• When you need help, ask for it.
• Show an interest in the person and what is important to them.
• Respect other cultures if different to your own.
• Use compliments, not flattery.
• Show appreciation.

Once we have a trusting relationship with stakeholders, we are in a good position to discuss their expectations and to work with them to resolve conflicts regarding these expectations. Larson and LaFasto support this claim with the assertion that “Collaboration flourishes in a climate of trust” (cited by Opfer in Cleland, 2004, p. 329).

One of the key elements in building trust is effective communication. The PMBOK^® Guide—Fourth Edition offers an example of a communication activity as “negotiating and influencing (stakeholders') desires to achieve and maintain the project goals” (PMI, 2008, p. 261). The means of conducting this communication can be achieved through various dimensions, listed as follows (PMI, 2008, p. 245):

• Internal and external,
• Formal and informal,
• Vertical and horizontal,
• Official and unofficial,
• Written and oral, and
• Verbal and nonverbal.

Consequently, project managers can choose from an array of communication methods to convey messages, elicit feedback, and work to resolve differences, directly or indirectly (such as through project team members or other stakeholders). Let us now look at some examples of projects where these methods were used, along with the techniques for resolving conflicting expectations, and the subsequent results.

When Expectations Conflict

In order to portray the interaction of the variables noted previously, three projects will be described in this section. All of the projects are within the field of information technology, though the industries for the sponsoring organizations range from telecommunications to health services and government. The techniques described previously were implemented in varying degrees, with proportionate levels of success.

Scenario #1 – Is it Really About the Schedule?

In the first scenario, an organization initiated a project to upgrade their desktop operating system, in conjunction with the conversion of sixty proprietary software applications. The project manager facilitated a workshop with the team over the course of 3 days, in which they devised a plan that would require 9 months for implementation. The project sponsor, who had signed a charter stating that there was no scheduling constraint, actually believed that the project could be completed in 6 months. Therefore, he severed the relationship with the external consultant, and took over as project manager. The project was eventually completed in 18 months.

Was this conflict really about the schedule? On the surface—yes; to place it in perspective, though, we need to look at the organization's history. They had only recently implemented a project management methodology. The sponsor disagreed with the need for the team members to participate in the planning process, which was indicative of the sponsor's resistance to embrace the new methodology.

Why was the sponsor resistant? Had he known about motivational psychology, the sponsor would have subscribed to Theory X, as described by Douglas McGregor in 1960 (Envision Software, 1998–2007). Consequently, he had no faith in his own staff. He did not trust their judgement in estimating the work effort nor their work habits in completing assignments efficiently. Therefore, for him, an internal manager was required to run the project by independently creating a project plan and managing the team with a top-down approach.

Scenario #2 – Tread Carefully or Run like Mad?

The second scenario involves a company that hired a vendor to conduct an enterprise application integration program. The contract hinged on the vendor's ability to quickly deliver the five projects within the program. Not surprisingly, the project sponsor continually reiterated the need for speed, when talking to the vendor.

Unfortunately, this message was not consistent with the message that the sponsor gave to his own project team. They were advised to be careful and reminded that they would be responsible for fixing any mistakes. They then resisted the vendor's streamlined approach to the project, due to prior experience of being left with an error-laden product. In addition, the program was not staffed adequately by the client, resulting in a project team that could not complete the work in a timely manner, and was continually shifting focus between projects. The program suffered from “death by a thousand cuts” in that there was no major event that caused a delay, but multiple, minor delays that slowly bled the life out of it.

The conflicting priorities of schedule and quality denoted deeper issues. Contract negotiations had taken longer than expected, resulting in a delayed start date to the program. As often happens, the end-date remained fixed. The vendor was so concerned with meeting the schedule that planning was minimized, and assumptions regarding approach were not documented or confirmed. The vendor's business representative was not available during a crucial stage of the program, meaning that the reason for the immovable end-date was not explored.

Eventually, when it was acknowledged that the program would be delivered late, the sponsor admitted that the program's timeframe had been unrealistic from the beginning. He also revealed that there had been a specific market window for one project within the program, which should have been the top priority. When that window was missed, the entire program was cancelled. Whether it was from a lack of trust in the vendor or governance regulations concerning the sharing of corporate strategy, the concealment of this information directly led to a failed program.

Scenario #3 – “Mistrust” Ran Amok

The third scenario started with a request from a client for a vendor to migrate a software application to a new technical platform. The vendor received authorization to commence work while the contract was being refined. On the first day of the project, the client's representatives from the Information Technology (IT) division announced that the existing application was not appropriate for the client's business processes. As such, they expected the vendor to design and build a custom application.

“Migrate” and “custom-build” are not synonymous expectations. These decidedly different approaches require unique descriptions of scope and are often accompanied by vastly dissimilar budgets and schedules. The vendor immediately reviewed the issue internally, then conducted a meeting with the executive sponsor in IT and the project sponsor from the business community. Agreement was reached to gather requirements for a custom application. A few months later, when the new scope definition was evaluated for the ramifications on time and cost, the vendor was authorized to begin construction of the application.

The executive sponsor stated that budget was a priority; the vendor was to build an application with a minimal number of features, since the long-term strategy included options for either augmenting or replacing the application. Meanwhile, the involvement of the business community ranged from reluctance to participate in design meetings, to listing every possible requirement as mandatory. Moreover, some of the ten specialist areas within the business community resisted the vendor's approach to building a system whereby information could be viewed by all of the areas.

There was immense skepticism from the business community that the application would meet the needs of the diverse areas or, in fact, ever be built at all. Why? Once again, the client's background provided insight to the current situation. Several similar projects had been initiated and abandoned. Each of the business areas had developed their processes independently, with little interaction or sharing of information. They did not trust each other, nor did they trust their IT division. Likewise, IT did not trust the vendor, and was concerned that scope creep would increase the budget beyond acceptable levels.

Where did this leave the vendor? They had to build credibility with both the IT division and the business community. Change requests were documented in detail to demonstrate a fair approach to evaluating changes in scope. The vendor worked to build trust among many of the stakeholder groups by including representatives from IT and all of the specialist areas in the design meetings. Documentation of these meetings served to foster faith in the project and the project team, simply because prior projects had not produced written records. Finally, a list of deferred requirements indicated that the requests would be considered, later. When the software was implemented, many of the doubters had been converted to supporters.

Recommendations

Based on these descriptions of the projects, we can glean the following recommendations for clarifying and aligning expectations, and managing any conflicts between them.

1. Address Conflicts Early

Ignoring clues, which indicate there are conflicts in expectations, while focusing on the actual work of the project, has not shown to be effective. In the first scenario mentioned previously, no one pursued the point when the sponsor casually mentioned being mystified by the team's participation in project planning. Once the contract was signed in the second scenario, the vendor's team quickly moved into implementation, thus missing the opportunity to clarify the approach during planning. To the contrary, in the third scenario, the change in strategic direction was addressed immediately, and alignment achieved, leaving the project team free to focus on the forthcoming issues.

2. Uncover Motivations Behind the Stakeholders' Perspectives

In Steven Covey's book The Seven Habits of Highly Effective People, he names the fifth habit as “Seek First to Understand, Then to be Understood” (Mind Tools Ltd, 1995–2009). This philosophy would work well for project managers who are trying to understand why stakeholders possess certain expectations. In the first scenario, the sponsor's lack of commitment to the new project management processes was a strong indicator that he would not accept the schedule that resulted from them (Carr, 1996, p. 117). In the second scenario, the vendor did not investigate the business reasons for the schedule or the program itself. On the other hand, the project team in the third scenario allowed the business community to express their doubts about the project, leading to implementation of risk mitigation strategies.

3. Look For Relationships Between Issues

There are often links between issues. A lack of trust was inherent in all three scenarios. In two of the scenarios, it led to resistance to change, doubts concerning the validity of the schedule, and for the second project, failure. In contrast, the team in the third scenario developed trust by demonstrating progress and incorporating lessons that had been learned previously.

4. Involve Senior Management

When stakeholders' expectations conflict, project managers can often benefit from leveraging existing relationships, such as those between their senior management and their clients. The project teams in both the first and second scenarios may have benefited from escalating their concerns regarding trust and divergent approaches to their internal management. This approach was successfully used in the third scenario, and is supported by the findings of the Standish Group in their 2006 Chaos Report, which identified the top three reasons for success on application-development projects to be the following (Hartmann, 2006):

• User involvement,
• Executive management support, and
• Clear business objectives.

5. Solicit Agreement to Objectives and Approach from Divergent Stakeholder Groups

Project objectives are not always clear from the outset. As they are refined or changed, and even when we think that they have not changed, the project team needs to work with stakeholders to confirm the project goals and objectives. This type of discussion proved to be effective in the third scenario for clarifying scope, gaining agreement to the approach, and illustrating the ease of sharing information.

6. Use Multiple Routes and Forms of Communication

Human beings communicate in many ways. One of the most productive methods of communication is in face-to-face discussion, since we are able to utilize both verbal and non-verbal signals. Of course, we need to be conscious of confirming that we are interpreting non-verbal signals correctly, since they may have different meaning in different cultures (Heathfield, 2009). In terms of written communication, notes from conversations may be able to jog our own memories—and those of others—long after the conversation has taken place. Minutes can serve the same purpose for meetings.

Formal documentation of the approach in the second scenario would have allowed change control, as well as a common understanding of the trade-offs between quality and schedule. In the third scenario, the vendor facilitated discussions between various groups within the client organization and members of the project team met with business areas separately to hear their concerns and reinforce the project objectives, while potential changes in budget were communicated both verbally and in writing, formally and informally. The multiple methods and routes of communication served to address and resolve the conflicts in expectations, resulting in a successful project being delivered.

Conclusion

There is a correlation between resolving conflicts in stakeholder expectations, and project success. Correspondingly, the earlier that project teams diffuse a potentially dangerous situation by identifying the cause of conflicts, the relationship between issues, and motivations of stakeholders, the easier it is to build trust, resolve conflicts, and overcome resistance to change. Using various forms of communication between the project team, senior management, and stakeholders enhances opportunities for mutual understanding. All of these techniques aid project managers in building alignment in stakeholder expectations, and reducing the prospect of injury to the project. Our parents were right—we need to be careful when we run with scissors.