Stakeholder biases: Why project context matters
Most project managers know and can cite the definition of project management, yet as evidenced by their project documents, discussions, and behaviors they do not know and cannot cite the stakeholder biases for the project. Worse, some project managers have no familiarity with the term. If stakeholder biases are not well-established by the project manager and used at every opportunity over the course of the project, then how likely is it that the application of knowledge, skills, tools and techniques will be appropriate for the project not to mention exceptionally crafted? Do project managers really know the purpose of project management? This presents a challenge and opportunity for the Business Driven PMO Manager.

The Purpose of Project Management

Let’s start at the beginning or as Vince Lombardi, the legendary coach of the 1960s Green Bay Packers would say, “This is a football.”

What is a project? A project is a temporary endeavor undertaken to create a unique product, service or result2.

What is project management? Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements2.

What is the purpose of project management? The purpose of project management is to foresee or predict as many dangers and problems as possible; and to plan, organize and control activities so that the project is completed as successfully as possible in spite of all the risks3.

Now, consider the two projects shown in Figure 1. Assume they are the exact same project with the exact same scope and project phases. You can see the status of each project and the scheduling and cost information for each project. Which project was better managed?

Figure 1: Which Project Was Better Managed?

This is an exercise that has been given to attendees of Business Driven PMO Workshops conducted around the world and their answers are insightful and well worth visiting.

The attendees of the Business Driven PMO Workshops consist of three groups; (1) project managers, including PMO management and staff, (2) agile practitioners, and (3) leadership team members.

Naturally, folks wanted more information, but the instructions given were to consider these two projects as if they were projects in your own PMO and that the information you have is all that is readily available. The attendees were then asked to answer the question by giving one of three possible answers; project #1 was better managed, project #2 was better managed, or more information was needed. And one last instruction was given which was they could only give the more information needed answer if in their own PMO environment they truly would need more information and not have formed an opinion, notion, or gut feel as to which project of the two was better managed.

As shown in Figure 2, these three groups had very different views on which project was better managed. Project managers said it was project #1, agile practitioners strongly asserted that it was project #2, and the leadership team was evenly divided.

Figure 2: Different Views on Which Project Was Better Managed?

What was interesting and revealing were the explanations of why people answered the way they did which were consistent within peer groups and consistent across different countries.

Project managers offered the explanation that Project #1 was better managed because it came in on time and on budget. The agile practitioners had a different view and argued that Project #2 was better managed. Though it missed its schedule and budget, Project #2 finished earlier than Project #1 achieving a faster time-to-market which would produce quicker and more benefits to be realized.

And then there was the leadership team. About half of them believed Project #1 was better managed for the same, on time and on budget, reasons given by the project managers and the other half believed Project #2 was better managed, but not for the time-to-market reasons cited by the agile practitioners, rather because they believed that a project with all green (good) status indicators is a lie and a project with a mix of green, amber, and red (good, caution, trouble) indicators is truthful, more transparent, and therefore better managed.

Important to note, though it was allowed very few people gave the answer that more information was needed, a harbinger of a soon to be realized epiphany.

At this point in the exercise as shown in Figure 3, two project scenarios which happened to be the details behind Projects 1 and 2 in the exercise were provided and explained. Though these projects were similar in time and cost, they could not have been more different when viewed in terms of their business context and stakeholder biases.

Figure 3: Project Scenarios

The details of the two scenarios not only reveal the business context and stakeholder biases of the projects, but the importance of understanding stakeholder biases so that they can be used in the application of project management techniques.

Scenario A was a project to oversee the preparation of a construction site and to ensure that it would be completed on time so that the next phase of development could commence. If late, significant penalties would be incurred. In the overall scheme of the project, time in the form of a bullet-proof date that would not be missed was most important to the stakeholder. Scope was important, but was not at risk and secondary to time, and cost was not a concern. The stakeholder instructed the project manager to safely schedule the project by adding buffer to each of the initial phase estimates. The result was a project that was delivered safely on time as planned, though later than the initial phase estimate inputs, and that avoided all penalties.

Scenario B was a project to deliver an online ordering capability, new to the company, which would result in a $20k benefit per day once in operation. Each day this capability was not in place was an irritant to the stakeholder who had been requesting it for a long time and wanted it delivered as soon as possible. In the overall scheme of this project, time was most important to the stakeholder, scope was secondary and flexible in terms of delivering core functions first and additional features later if need be, and cost was not a concern as it was virtually negligible compared to the business benefits that would be realized. The stakeholder instructed the project manager to aggressively schedule the project by employing negative buffering, a common product marketing technique that involves taking as much time as possible away from the initial phase estimates to shorten time to market. The result was a project that finished as early as possible, though later than its aggressive schedule, and that maximized benefits.
 

… a project that is on time and on budget isn’t necessarily better managed than a project isn’t…

The workshop attendees wanted to change their answers. The project managers realized that a project that is on time and on budget isn’t necessarily better managed than a project that is late and over budget. The agile practitioners realized that a project that finishes earlier isn’t necessarily better managed than a project that takes more time. And the leadership team members realized those points too and more importantly they realized that project status indicators should not be viewed in terms of whether or not the project manager is telling the truth or lies about the project, but rather how the project manager is, or should be, applying project management techniques in order to achieve the results desired by the stakeholder. It was a common refrain that a much better job can be done understanding and using stakeholder biases. A “purpose of project management” epiphany was had by all.

The Stakeholder Biases “Magic” Quarter

That PMOs know the concept of stakeholder bias is of no debate; that stakeholder bias is well-established and used over the course of the projects of the PMO is an entirely different matter. As shown in Figure 4, a good PMO tool for ensuring that practices for stakeholder bias are well-established and used is the Stakeholder Biases “Magic” Quarter.

Figure 4: Stakeholder Biases “Magic” Quarter

The Stakeholder Biases “Magic” Quarter is a 2x2 analysis construct that depicts the degree to which stakeholder biases and practices to use stakeholder bias are well-established. The top-right quarter is the area of the grid that is magical. PMOs in this quarter have approaches for project management that ensure the business context of the project and stakeholder biases for the project are understood and that project management tool usage and techniques are crafted to best meet the stakeholder view of project success. The other three quarters of this 2x2 analysis grid offer little stakeholder bias magic. PMOs in these quarters are less likely to use project management tools and apply project management techniques in the best possible manner. Hence, they are likely to achieve poorer product of the project outcomes and in some cases failure.

As part of the Business Driven PMO book series1 published by J. Ross Publishing, PMO research was conducted by the author including surveys and interviews for the purposes of determining the degree to which stakeholder bias was understood and effectively used. The PMOs surveyed and interviewed consisted of four types of PMOs; IT PMOs (30), enterprise PMOs (30), Agile PMOs (30), and New Product Development PMOs (10). Each of these PMOs was asked to provide a random project charter, project status report, and executive dashboard report. The documents and reports were then examined to determine what percent of PMOs did not reflect or use stakeholder bias for such things as the importance and priority of scope, time, and cost; the will-to-pay and will-to-wait of the stakeholder; and any drop-dead dates and drop-date costs for the project that would compel project termination, etc. The survey findings showed the following:

  • Project Charters – 89% did not reflect stakeholder bias
  • Project Status Reports – 93% did not reflect stakeholder bias
  • Executive Dashboard Reports – 93% did not reflect stakeholder bias

All of these project documents and reports had project measures, but very few of them provided any kind of importance to the measures not to mention stakeholder biases for each of the measures.  For example, as listed below, all of the project charter documents contained data for scope, schedule, and budget but little evidence of actually understanding or using stakeholder biases:

  • Project Charter – Stakeholder Bias for Scope
    • 82% identified key (must deliver) requirements
    • 27% identified optional (can deliver later) requirements
    • 12% prioritized requirements
  • Project Charter – Stakeholder Bias for Time
    • 4% identified the stakeholder will-to-wait
    • 4% identified the stakeholder drop-dead for time
  • Project Charter – Stakeholder Bias for Cost
    • 7% identified the stakeholder will-to-pay
    • 7% identified the stakeholder drop-dead for cost
  • Project Charter – Priority of Scope, Time, Cost
    • 11% prioritized or ranked scope, time, and cost in importance

Project status reports and executive dashboard reports were virtually identical with respect to containing stakeholder bias information or showing its usage with only 7% of these reports indicating an importance or priority to project measures. When an importance or a priority for project measures was shown, it was always a judgment call in the form of a red flag or inserted comment.  Priority and importance for project measures were not part of the core format of project status reports and executive dashboard reports nor consistently present.

The results of the survey begged the question, “If stakeholder biases are not understood or used, how likely is it that stakeholders will be best served over the course of their projects?” The ensuing interviews with the PMOs were intended to both answer that question and to determine if there was any other evidence supporting the understanding or use of stakeholder biases. The interviews did provide interesting insights about stakeholder bias, but no documented evidence. Some of the comments of the interviewees were as follows:

  • “We document stakeholder information such as their power, influence, and expectations and how they will be communicated with and managed, but no, we don’t ask about their biases related to project measures.”
  • “We don’t document stakeholder biases, but we know what they are.”
  • “We assume that by meeting scope, time, and cost, the stakeholder will be satisfied.”
  • “We only talk about drop-deads for the project, time or cost, when it begins to fail.”

Collectively, having participated in the surveys and interviews, it was the general consensus by the PMO managers that there was little to no physical evidence in their project charters, project status reports, and executive dashboard reports that stakeholder biases were understood and used. And though most of the PMOs had some form of stakeholder management, those plans did not material change the view that stakeholder biases were not well-established and not really used. There was also a general consensus by the PMO managers that while project discussions with stakeholders in formal as well as informal meetings often resulted in the understanding of their interests and to some extent biases which then became part of the project record, a better job could be done ensuring that the application of project management techniques is driven and crafted through the understanding and use of stakeholder biases.

Though the sample size of the PMO survey and limited number of different types of PMOs did not support a quantitative finding of fact in terms of the degree to which IT PMOs, Enterprise PMOs, Agile PMOs, and New Product Development PMOs have well-established stakeholder biases and PMO practices in place that use those biases, it did support an inference. Based upon the author’s judgment, this inference is shown in Figure 4, above, with each of these PMOs positioned within the Stakeholder Biases “Magic” Quarter analysis construct.

Conclusion

As PMO managers seek new ways to drive strategy execution, support business agility, sustain change management, deliver value, and continually improve upon their PMO practices, it can be highly beneficial to take a moment from time to time for a review of the basics. Do all involved know what a project is? Do all involved know what project management is? Do all involved know the purpose of project management? Are we sure?

For many people, the practical application of project management has less to do with what must be learned and far more to do with what must be unlearned. The idea that the purpose of project management is to deliver the project on time and on budget is a good example of some of the unlearning that is required.

Enter the Stakeholder Biases “Magic” Quarter. This 2x2 analysis construct is a PMO tool that considers the degree to which stakeholder biases and practices to use those stakeholder biases are well-established. Viewing how PMOs are positioned in this analysis construct, by way of hard evidence as well as practitioner and management judgment, can shed light on new ways and techniques to improve the application of project management and the product of the project outcomes that are achieved.

Since the time of the PMO research discussed in this article was conducted, several of the participating PMO managers have shared their experiences in adopting and applying stakeholder bias within their PMO practices. All of the experiences were reported as successful and the following comments summarize the collective claims of the PMO managers:

  • “Using stakeholder bias has significantly increased stakeholder preparation, attendance, and active participation in project status meetings.”
  • “Adopting stakeholder bias has changed the way our project managers talk to their stakeholders; they now speak the language of business.”
  • “Using will-to-wait and will-to-pay has changed the way we select projects, approach planning, and manage project issues.”
  • “Showing stakeholder bias in our dashboard and discussing it in our portfolio meetings have changed for the better how we argue.”
  • “Using stakeholder bias has transformed the perception of our PMO from template policing to servant-leading.”

Irrespective of type, ensuring the best possible application of project management techniques is an aim of all PMOs. Hence, PMO managers would be well served to consider adopting and applying stakeholder bias in their PMO practices. Like others that have given it a try, they too will experience very satisfactory outcomes.  

 

References

1 This whitepaper is based on books and articles by the author. See:

  1. Mark P. Perry, Business Driven PMO Setup – Practical Insights, Techniques and Case Examples for Ensuring Success (Plantation, Florida: J. Ross Publishing, 2009)
  2. Mark P. Perry, Business Driven Project Portfolio Management – Conquering the Top 10 Risks that Threaten Success (Plantation, Florida: J. Ross Publishing, 2011)
  3. Mark P. Perry, Business Driven PMO Success Stories – Across Industries and Around the World (Plantation, Florida: J. Ross Publishing, 2013)
  4. Mark P. Perry, The Purpose of Project Management, (August 10, 2017)
  5. Mark P. Perry, The Project Management Triangle, (September 5, 2017)
  6. Mark P. Perry, Stakeholder Bias, (September 6, 2017)

2 What is Project Management? The Project Management Institute 2019

3 Brian Miller, The Purpose of Project Management and Setting Objectives, Project Smart 2019