Stakeholder Expectations Management
(191 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
− | + | ''Developed by Sean O'Regan'' | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | |||
− | |||
− | |||
− | Expectations | + | [[File:Expectations.png|thumb|330px|Figure 01: Example of misaligned expectations; Adapted from: http://advancedcommunicationsclassblog.blogspot.dk/2011/12/miscommunication-picture.html]] |
+ | Stakeholder satisfaction is a main factor in a project success. Therefore, for a project manager is vital to have the satisfaction of the different stakeholders under control. | ||
+ | Stakeholder satisfaction is impacted by multiple factors during a project and it can be hard to directly manage it. However, it can be improved by understanding, aligning and managing the stakeholders expectations. In fact, as illustrated by the expectancy confirmation model the stakeholder satisfaction is given by the discrepancy between the perceived performance of and the prior expectations about the outcomes. | ||
− | + | Expectations usually differ between the different parties in a project and as the number of stakeholders increases aligning becomes more and more difficult. | |
+ | |||
+ | The scope of this article is to present a set of tools to identify and manage stakeholder expectations. The tools are applicable both in the planning and execution phases and will be divided in proactive tools, to use in the planning phase and reactive tools, to support the project execution. | ||
+ | |||
+ | For each tool a brief description should provide the reader with enough information to apply it, and links for further information. | ||
=Project Management and Stakeholder Management= | =Project Management and Stakeholder Management= | ||
− | Stakeholders are defined by the ISO 21500 standard as "a person, group or organisation that has interests in, or can affect, be affected by, or perceive itself to be affected by, any aspect of the project" | + | [[Stakeholder Management]] is used to describe the process of identifying, assessing and building a relationship with the stakeholders. Stakeholders are defined by the ISO 21500 standard as "a person, group or organisation that has interests in, or can affect, be affected by, or perceive itself to be affected by, any aspect of the project" <ref name="Iso">''ISO21500. 2012. Guidance on Project Management. International Organization for Standardization.'' </ref>. |
+ | |||
+ | |||
+ | Any project manager should identify and categorize all the key stakeholders defining which interests they have and how important they are for the completion of the project. | ||
+ | |||
− | ''' | + | Most of the literature on project management recognizes the importance of stakeholders. As an example: |
+ | *PRINCE2 <ref name="Prince">''Managing successful projects with PRINCE2, TSO, 2009'' </ref>, states that in order to run a successful project, the project management team should have an effective strategy to manage communication flows to and from stakeholders. It also puts an emphasis on the importance of analysing the involved stakeholders with the purpose of being able to engage properly with them. Furthermore, it underlines the importance of stakeholder involvement, especially in projects that are not a part of a program. | ||
+ | *The 5th edition of PMBOK from the Project Management Institute (PMI) has recognized the importance of stakeholder management and dedicated a knowledge area to it - ''Project Stakeholder Management''. <ref name="PMI">''Project Management Institute. (2004). A guide to the project management body of knowledge (PMBOK guide). Newtown Square, Pa: Project Management Institute.'' </ref> | ||
− | |||
− | + | Therefore, correctly managing stakeholders is extremely important. Indeed, even if different theories provide different criteria for project success, recent literature is converging on defining the project success as a result of stakeholder satisfaction. <ref>''Cavarec, Y. B. (n.d.). Revisiting Definition of Project Success. Retrieved September 26, 2016, from http://www.pmi.org/learning/library/revisiting-definition-project-success-6098/'' </ref> | |
=The importance of expectations in stakeholder satisfaction= | =The importance of expectations in stakeholder satisfaction= | ||
− | From the previous section we understood how important ending the project with satisfied stakeholder is for the project success. In this section | + | From the previous section we understood how important ending the project with satisfied stakeholder is for the project success. In this section a summary of what expectations are in the field of project management will be presented as well as what the connection between expectations and satisfaction is. |
− | + | ||
− | + | ||
− | + | ||
− | + | Expectation in general terms is defined as ''"a belief that something will happen or is likely to happen"''. | |
− | + | In every project each stakeholder has different interests to participate or not, has different expectations as to the results of the project and has different definitions of when the project will be successful. Also the answer to the question "what's in it for me" is different for each stakeholder. | |
− | + | ||
− | + | To better understand the concept of expectation and how it usually differs between stakeholders a practical example can help.<ref name="ex">''MECHanisms | Make Energy Change Happen Toolkit. (n.d.). Retrieved September 26, 2016, from http://mechanisms.energychange.info/backgrounds/8'' </ref> | |
− | |||
− | + | '''Project: Refurbish homes and improve energy efficiency''' | |
− | ''' | + | *Central government is likely to perceive success in terms of reduced energy demand, improved energy security and reduced CO2 emissions. In some countries, refurbishment may also be a social policy measure to combat fuel poverty. |
+ | *Local government may be more interested in employment effects and keeping the building stock in good shape. In some regions, refurbishment may also be a social policy measure to combat fuel poverty. | ||
+ | *Participating companies may expect the project to create new markets and increased revenues. | ||
+ | *Residents (energy end-users) are most likely to value increased comfort, better living conditions and lower energy bills as important outcomes. | ||
− | |||
− | = | + | The PMBOK guide include the topic of stakeholder expectations in the topics of " Identify Stakeholders" and "Manage Stakeholder Engagement" that is included in "Project Stakeholder Management". However, the standards don't include particular procedures and tools to discover and manage stakeholders expectations besides the stakeholder analysis. <ref name="PMI"/> |
+ | |||
+ | In general, finding literature focused on stakeholders expectation is hard, and, as in the PMBOK, the topic is usually included in other tools and theories and does not stand by it self. | ||
+ | |||
+ | In the next section, the ''expectation confirmation theory'' will be presented as a proof of the relationship between stakeholder satisfaction and expectations. | ||
+ | |||
+ | ==Expectation confirmation theory== | ||
+ | [[File:Expectation confirmation theory.png|thumb|300px|Figure 02: Expectation confirmation theory, visual process]] | ||
+ | |||
+ | Expectation confirmation theory is a cognitive theory developed in the '70 by Richard L. Oliver. It was developed in a marketing literature but from there it was applied in multiple fields since its versatility and simplicity. The first application was to explain post-purchase or post-adoption satisfaction. | ||
+ | |||
+ | According to the model, satisfaction is caused by positive or negative dis-confirmation between expectations and performance. If a product outperforms expectations (positive dis-confirmation) post-purchase satisfaction will result. If a product falls short of expectations (negative dis-confirmation) the consumer is likely to be dissatisfied. <ref name="Confirmation">''Expectation confirmation theory. (n.d.). Retrieved September 26, 2016, from http://is.theorizeit.org/wiki/Expectation_confirmation_theory'' </ref> | ||
+ | |||
+ | Although this gap model of satisfaction was developed primarily within marketing to explain customer satisfaction, the relationships between buyer-seller is applicable to the relationship stakeholder-project manager <ref name="Satisfaction">''Strong, K. C., Ringer, R. C., & Taylor, S. A. (2001). THE rules of stakeholder satisfaction (timeliness, honesty, empathy). Journal of Business Ethics, 32(3), 219–230.'' </ref>. | ||
+ | |||
+ | Thanks to this model is clear that if we are not conscious of the expectation of a stakeholder, even if the project goes accordingly to plans, he might still be unsatisfied. | ||
+ | |||
+ | =Toolboxs= | ||
==Proactive toolbox== | ==Proactive toolbox== | ||
+ | Ensuring stakeholder satisfaction is a process that starts before a project begins. The planning phase is the most crucial to understand what value is expected by the various stakeholders and how to actually deliver it. Indeed, once the project starts, modifications to satisfy stakeholders who were not included in the planning phases can cause big delays and cost increase. | ||
+ | |||
+ | The process has to begin by understanding who are the stakeholders involved (phase 1) and their relation with the project (phase 2). | ||
+ | However, even after understanding the parties involved, stakeholders most of the time are not able to clearly explain their expectations. That is why in the toolbox two tools are dedicated to extract hidden desires and avoid communication misunderstanding (phase 3). | ||
+ | Afterwards, stakeholders expectations have to be aligned and, when this is not possible, prioritized (phase 4). | ||
+ | Once the expectations are clearly understood, the project manager should store the agreement in a written form to inform the project team on the goals and have a written proof in case that stakeholders change their mind (phase 5). | ||
+ | |||
+ | Figure 03 summarizes the process and shows the suggested tools. | ||
− | [[File:Proactive toolbox.png]] | + | [[File:Proactive toolbox.png|thumb|600px|center|Figure 03: Proactive toolbox and application process]] |
===Stakeholder inventory === | ===Stakeholder inventory === | ||
− | The first step of managing the stakeholders expectation is to have the complete picture of who is a stakeholder in the project. | + | The first step of managing the stakeholders expectation is to have the complete picture of who is a stakeholder in the project. |
− | ===Stakeholder | + | The best method to create an exhaustive list is to hold a brainstorming workshop between the project team. The objective in this phase is to think creative to include every possible stakeholder. For normal projects, a brainstorm of 10-15 minutes should be sufficient. |
− | From | + | |
− | For the purpose of this article, the theory background and detailed explanation on | + | ===Stakeholder mapping=== |
+ | [[File:Power-Interest.PNG|thumb|240px|Figure 04: Stakeholder mapping]] | ||
+ | |||
+ | From the stakeholder inventory is important to prioritize the stakeholders in base at their relationship with the project. | ||
+ | For the purpose of this article, the theory background and detailed explanation on the different version of the tool will not be presented. The page [[Stakeholder Analysis]] explains in depth the concept and it's application. | ||
+ | |||
+ | The suggested version of the stakeholder mapping is the Power/Interest diagram. It is created by positioning the stakeholders in the different areas according to the estimated power, how much a stakeholder can affect the project, and interest, how much a stakeholder is involved in the project. | ||
+ | |||
+ | The x axis represents the interest, so the interest increases going from the left to the right. The y axis represents the power, so the power increases going from the bottom to the top. | ||
===Reverse brainstorming=== | ===Reverse brainstorming=== | ||
− | Trying to understand the stakeholder expectation in a project, a main issue can be found in the lack of a clear vision from the stakeholder of its desires. | + | [[File:Reverse Brainstorming.png|thumb|300px|left|Figure 05: Reverse brainstorm process]] |
− | + | Trying to understand the stakeholder expectation in a project, a main issue can be found in the lack of a clear vision from the stakeholder of its desires. If asked with direct questions like "What do you expect this project to achieve?" or "How will this project help you?" stakeholders can have some difficulties in answering. | |
− | Reverse brainstorming solves the problems of direct questioning | + | |
− | + | Reverse brainstorming is a 5 step progress that solves the problems of direct questioning by exploring multiple factors in reverse. This encourages more creative thoughts creating robust solutions. | |
− | + | ||
+ | The project manager should reverse the question he would need to understand the expectations. Examples could be "How can the project dissatisfy you?" and "How could we fail this project?"; by asking this kind of questions participation is encouraged through outside-the-box thinking. | ||
+ | |||
+ | From this first first phase, the negative ideas generated are reversed again to understand what are the positive expectation of the stakeholder. | ||
+ | <ref ">''How to Solve Problems with Reverse Brainstorming. (2011). Retrieved September 26, 2016, from http://www.halogensoftware.com/blog/how-to-solve-problems-with-reverse-brainstorming'' </ref> | ||
===Prototyping=== | ===Prototyping=== | ||
− | A prototype is an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from. | + | After some meeting and information exchange the project manager should have a preliminary idea of the expectations of the stakeholder. In case this expectations concern data and measurable results it is easy to communicate and agree with the stakeholder. |
− | + | However, many times the expectations regard subjective evaluation and even if the two parties agree it is not obvious that they are picturing the same result. | |
+ | |||
+ | Therefore, before closing the confrontation with the stakeholder about their expectations is important to make sure that there during the process a misunderstanding caused a distance between the actual expectation and what the project manager understood | ||
+ | A prototype is an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from.<ref >''Design Thinking: Putting the Customer at the Heart of Development. (n.d.). Retrieved September 26, 2016, from https://www.mindtools.com/pages/article/design-thinking.htm'' </ref>. | ||
+ | |||
+ | In the context of this article, a prototype can both be a physical or digital representation of the final output, in case of a physical output, or a more abstract picture of the final state for project such as organizational change. | ||
+ | |||
+ | ===Value vs complexity grid=== | ||
+ | [[File:Value vs complexity.PNG|thumb|240px|Figure 06: Value vs Complexity grid]] | ||
+ | |||
+ | From the brainstorming a number of requirements and needs will be collected. However, in a project satisfying every expectation is impossible. The value vs complexity grid supports the decision making process of selecting the requirements to keep and the one to eliminate <ref>''Value vs Complexity - A Prioritization Framework. (n.d.). Retrieved September 26, 2016, from http://www.product-arts.com/resourcemain/articlemenu/1049-value-vs-complexity-a-prioritization-framework'' </ref>. It is based on two factors: | ||
+ | *Difficulty and complexity: it is related to technical considerations on how challenging the implementation will be, therefore there is a need of clear measurements for the criteria and support of technical team in order to help define the complexity of each requirement. | ||
+ | *Value and importance: it considers the functionality each requirement represents, dependencies other requirements have on it, value/benefits realized for the organization, and the importance of the stakeholders that are associated with it. | ||
+ | |||
+ | From the grid the project manager should understand which expectations should be satisfy and which ones should be dismissed. | ||
===SMART requirements agreement=== | ===SMART requirements agreement=== | ||
− | A requirement is nothing more than an expected outcome of the project. | + | After multiple iteration at this phase stakeholder expectations should be clear. However, it is necessary to formally store the information collected as a project requirement both to inform the project team avoiding internal misalignment and have a agreement proof in case a stakeholder changes its mind. |
+ | |||
+ | A requirement is nothing more than an expected outcome of the project. However the way the requirement is formulated should not leave space to interpretations. In the absence of facts and details, the stakeholder will interpret and make up assumptions. Moreover, everything should be stated in the requirements, if it is not stated, it is not committed to be completed. | ||
+ | To ensure a flawless requirements definition each requirement should be expressed through as a S.M.A.R.T. requirement: <ref>''SMART Requirements. (2010). Retrieved September 26, 2016, from https://jessica80304.wordpress.com/2008/08/04/smart-requirements/'' </ref> | ||
− | + | *'''Specific:''' A good requirement is specific and not generic. It should not be open to mis-interpretation when read by others. | |
− | + | *'''Measurable:''' This answers whether you will be able to verify the completion of the project. You should avoid signing up for any requirement that cannot be verified as complete. | |
− | + | *'''Attainable:''' The requirement is physically able to be achieved given existing circumstances | |
− | + | *'''Realistic:''' Answers whether the requirement is realistic to deliver when considering other constraints of the project and requirements | |
− | + | *'''Time-bounded:''' Specify by when or how fast a requirement needs to be completed or executed | |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
==Reactive toolbox== | ==Reactive toolbox== | ||
+ | Even after a meticulous planning process to understand and accommodate stakeholder expectations, new and unexpected expectations could emerge. This new expectations could emerge from stakeholders that were not considered before or by changes in the environment. | ||
− | [[File:Reactive toolbox.png]] | + | The new expectations are are usually hidden within a request to change some parameter of the project that have to be recorded to keep track of all the issues emerged (phase 1). |
+ | Once the project manager comes across this requests, he/she has to act to understand what the interest behind this new expectations is. Indeed, as in the proactive toolbox, the direct request of changing something can not be the real need of who's asking. Negotiation techniques can support this process limiting the divergence from the original plan (phase 2). | ||
+ | If there is no way to avoid changing plans, a delicate phase begins where the project manager has to understand how changing some parameters will influence the rest of the project and agree with the stakeholders a trade off between satisfying this new expectation and existing project requirements (phase 3). | ||
+ | |||
+ | Figure 07 summarizes the process and shows the suggested tools. | ||
+ | [[File:Reactive toolbox.png|thumb|600px|center|Figure 07: Reactive toolbox and application process]] | ||
===Issue log=== | ===Issue log=== | ||
− | When analyzing stakeholder expectation | + | When analyzing stakeholder expectation an issue represents the distance between the stakeholder expectation and the reality of the project. |
− | An issue log, in general project management term, | + | An issue log, in general project management term, contains a list of ongoing and closed issues of the project. While issue logs can be viewed as a way to track errors in the project, the role it plays often extends further. Issue logs can be used to order and organize the current issues by type and severity in order to prioritize issues associated with the current milestone or iteration<ref>''What is an Issue Log? (n.d.). Retrieved September 26, 2016, from http://www.simplilearn.com/issue-log-concepts-article'' </ref>. |
− | + | In this toolbox, the issue log is the backbone to keep track of the emerged problems, what expectation was besides them and how they where solved. | |
− | + | ||
− | === | + | ===Integrative bargaining=== |
− | + | [[File:Stakeholder negotiation.gif|thumb|150px|Figure 08: Integrative bargaining]] | |
− | + | When a new issue is identified, a project manager can't just approve every change and keep changing the scope of the project. Changes in plan will cause distortions in cost and time of the project and could affect some other stakeholder expectation. | |
− | + | ||
− | + | That is why is it important to understand if the issue has to be resolved and what the easiest way to solve it is. | |
− | + | Integrative bargaining is a negotiation strategy in which parties collaborate to find the motivation behind the initial request and develop a "win-win" solution to their dispute<ref>'' Beyond Intractability. (n.d.). Retrieved September 26, 2016, from http://www.beyondintractability.org/essay/interest-based-bargaining'' </ref>. In other words, the project manager has to understand what is the stakeholder expectation behind the request of a new project requirement and find others way to satisfy it. | |
− | + | Figure 08 gives and overview of the method and Video 1 visualizes the benefits of Integrative bargaining as explained in the article. | |
+ | {{#ev:youtube|https://https://www.youtube.com/watch?v=rJEOylZCUUs|600|center|'''Video 1: '''Integrative bargaining|frame}} | ||
− | + | ===Project Management Triangle=== | |
+ | [[File:Project Management Triangle.png|thumb|200px|left|Figure 09: Project Management Triangle]] | ||
+ | To support the negotiation the [[Project Management Triangle]] is a tool for the project manager to understand the effects of accepting to satisfy a new expectation. It is formed by its three dimensions, time, cost and scope, and a side of the triangle cannot be changed without affecting the others <ref >''The Iron Triangle of Project Management: Balancing Your Budget, Scope, and Schedule. (n.d.). Retrieved September 26, 2016, from https://www.mindtools.com/pages/article/newPPM_54.htm'' </ref> . | ||
− | + | When a new expectation comes to the table, the project manager will now be able to analyze the feasibility of implementation and explain what other project requirements will be changed to accommodate the request. As an example, if a stakeholder request the project to finish before the set deadline the project manager will ask for a higher budget or to remove some features (scope). | |
+ | |||
+ | =Other tools= | ||
+ | |||
+ | *'''RACI Matrix: ''' The [[Responsibility Assignment Matrix (RACI Matrix)]] can clarify which stakeholders and how they are connected in a context of a specific task or project step. | ||
+ | *'''Risk Matrix:''' The [[Risk matrix]] can help to improve the robustness of the promises made to the stakeholders. | ||
=Field of application toolbox= | =Field of application toolbox= | ||
+ | These toolboxes are not designed for any particular project category. | ||
+ | They have applicability in most of the projects, and they are particularly relevant when the project manager senses different interests from different stakeholders. | ||
+ | |||
+ | It is recommended that the proactive toolbox is used in the beginning of the project to ensure a correct stakeholder identification. Indeed, the usefulness of understanding the expectations once the project has already clear output would be quite low. | ||
+ | Instead, the reactive toolbox is to be used once the exaction of the project has began. It should be kept on hand for when a new issue is identified to ensure that all new problems are correctly documented and managed. | ||
+ | |||
+ | Because of the strategic impact of expectations management, the responsible of the process should be the project manager. However, it is extremely important to include in the project team in the process to ensure internal alignment. | ||
+ | |||
=Case Example= | =Case Example= | ||
+ | To better understand the application of the toolbox, a simplified fictional case is provided below inspired by the construction of the University of Exeter’s new business school in December 2007 <ref >''University of Exeter Business School, Turner & Townsend. (n.d.). Association for Project Management. Retrieved September 26, 2016, from http://www.apm.org.uk/node/633#EXE'' </ref>. | ||
+ | |||
+ | '''Proactive tools''' | ||
+ | |||
+ | The project manager identified the following stakeholders: | ||
+ | *University | ||
+ | *Student | ||
+ | *Government | ||
+ | He analyzed the stakeholder and developed the following stakeholder map: | ||
+ | [[File:example 1.png|thumb|300px|center|Figure 10: Stakeholder map]] | ||
+ | |||
+ | Talking with the stakeholders, the project manager collected the following first inputs: | ||
+ | *a very clear explanation of what the university was expecting: enhance its position as an international business school through the creation of a state-of-the-art educational facility. The client wanted a building with ‘wow factor. | ||
+ | *a lack of ideas from the students on what they would like in the new facility. | ||
+ | *clear guideline in terms of budgeting for the government sponsoring the project. | ||
+ | After, he conducted a reverse brainstorming for each stakeholder focusing especially on the students that were not able to provide their expectations: | ||
+ | *the university and government results show that they would mainly be dissatisfied by a delays in the projects. | ||
+ | *the students were able to describe what usually makes a faculty building less attractive, and from the analysis of their toughs the project manager understood that they were incredibly interested in places to conduct group work. that were not requested by the university, and a new student bar. | ||
+ | Having a clear idea of the initial expectations, the project manager collaborated with some architecture and design firms to develop detail 3-D models and renderings of the outcome project to make sure he understood the requests from the stakeholders. | ||
+ | |||
+ | |||
+ | Analyzing the different expectation on the project through the value vs complexity grid the project manager discovered that a few of the request were going to be extremely difficult to realize and would have brought small benefits, while requests from marginal stakeholders were easily implementable. | ||
+ | [[File:example 2.png|thumb|300px|center|Figure 11: Value vs. complexity grid]] | ||
+ | After deleting the unfeasible expectations and other workshops based on prototypes with the stakeholders, the project manager recorded the expectation in form of SMART project requirements and started the project. | ||
+ | |||
+ | '''Reactive tools''' | ||
+ | |||
+ | Three months into the project huge protest from the student association began asking for the suspension of the project for the duration of the exam session. The complains were caused by the noise that disturbed the students in the library near by the construction site. By applying the project management triangle framework the project manager developed an initial analysis of what a month of delay, to wait till the end of the exam session, would have caused and discusses the results with all the stakeholders. Since the increase in cost was not acceptable for the project sponsor, the project manager established a discussion table with the student to develop a win-win solution. | ||
+ | |||
+ | From the discussion the project manager understood that the noise complain were not caused by the construction itself but by the trucks delivering the material to the site. Therefore, project manager and students agreed on stopping the deliveries from 10 am to 4 pm without any stop on the construction. The new delivery scheme caused a raise in procurement cost but the final increase of expenses was not comparable with the initial request from the students of stopping the project. | ||
+ | |||
+ | The project manager stored the information acquired on the issue log on including the root causes of the complains to avoid similar problems in the future and keep track of the change in project requirements. | ||
+ | |||
=Template= | =Template= | ||
− | = | + | This template can support the proactive toolbox process providing step by step instructions and models for graphic visualization: [http://bit.ly/TemplateAPPPM bit.ly/TemplateAPPPM] |
+ | |||
+ | =Limitations= | ||
+ | |||
+ | *'''Personal skills of PM are extremely important:''' In the book Managing Stakeholder Expectations for Project Success, one of this supporting pillars of this article, the author dedicates great attention to the soft skills of the project manager. Indeed, most of the tools and procedure presented are useless if the project manager is not able to communicate and understand the stakeholders on a personal level. Indeed, many times expectations are expressed by non-verbal communications and require a sensible eye to be spotted. Moreover, while contracting with stakeholders communications skills are vital to achieve positive results. | ||
+ | |||
+ | *'''Number of stakeholders:''' A critical limitation whit theories concerning stakeholders satisfaction is the relationship between the different stakeholder satisfactions. Indeed, some studies described that improve managerial performance in one stakeholder group can comes at the expense of performance for another group. However, more recent studies suggest that, within limits, managers are able to meet the performance expectations of three primary stakeholder groups simultaneously. The research paper,''THE rules of stakeholder satisfaction'' (Kelly C. Strong et al 2001), presents a summary of this contrasting theories and a case study on the feasibility of satisfying three stakeholders groups simultaneously. However, even if this paper proves the possibility of satisfying different groups together, as the number of stakeholder increases satisfying all of them becomes harder and harder. That is why stakeholder mapping is of extreme importance, allowing the project manager to prioritize expectations. | ||
+ | |||
+ | =Annotated bibliography= | ||
+ | *'''A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition''' ''-Chapter 13'' | ||
+ | |||
+ | The chapter "Project Stakeholder Management" explains what a stakeholder is for a project. | ||
+ | |||
+ | Moreover, it gives a good overview on how to analyze stakeholder and their impact on the project, and to develop appropriate management strategies to effectively engage stakeholders in project decisions and execution. | ||
+ | It represents a good overview on current best practices of stakeholder management and is a good starting point to understand the general topic on which this article develops. | ||
+ | |||
+ | *'''Managing Stakeholder Expectations for Project Success:A Knowledge Integration Framework and Value Focused Approach ''' '' Ori Schibi'' | ||
+ | |||
+ | This book provides plenty of material concerning stakeholder expectations. | ||
+ | |||
+ | This article is mainly related to Chapter 4, in which chapter, it is described how to perform a stakeholder analysis and why doing it has a positive impact on project success. | ||
+ | In the rest of the book other topics of project management, such as communication, risk, change, and quality, are related with stakeholders and project success. | ||
+ | |||
+ | *'''Managing the Expectations of Stakeholders''' ''MAX Technical Training'' | ||
+ | |||
+ | This one hour YouTube video provides ten practical tips to manage stakeholder expectations. | ||
+ | |||
+ | This article takes inspiration from this tips and re-frames them in a more theoretical based approached. The video is a very good start for a practitioner not familiar with the topic and it provides useful examples on how the toolbox could be applied. | ||
+ | |||
+ | {{#ev:youtube|https://www.youtube.com/watch?v=oeE383ZHU24|600|center|'''Video 2:'''Managing the Expectations of Stakeholders|frame}} | ||
+ | |||
+ | *'''THE* Rules of Stakeholder Satisfaction (* Timeliness, Honesty, Empathy)''' ''Kelly C. Strong, Richard C. Ringer and Steven A. Taylor'' | ||
+ | |||
+ | This research paper is an interesting view on the stakeholder satisfaction world. | ||
+ | |||
+ | It focuses on the role of trust in stakeholder satisfaction. Customers, stockholders, and employees of financial institutions were surveyed to identify management behaviors that lead to stakeholder satisfaction. The model used for analyze stakeholder satisfaction and the literature critic on the topic is of great value for understanding the content of this article. | ||
+ | |||
+ | =References= | ||
+ | <references /> | ||
+ | |||
+ | [[Category:Project Management]] [[Category:Stakeholder Analysis]] |
Latest revision as of 15:04, 18 December 2018
Developed by Sean O'Regan
Stakeholder satisfaction is a main factor in a project success. Therefore, for a project manager is vital to have the satisfaction of the different stakeholders under control.
Stakeholder satisfaction is impacted by multiple factors during a project and it can be hard to directly manage it. However, it can be improved by understanding, aligning and managing the stakeholders expectations. In fact, as illustrated by the expectancy confirmation model the stakeholder satisfaction is given by the discrepancy between the perceived performance of and the prior expectations about the outcomes.
Expectations usually differ between the different parties in a project and as the number of stakeholders increases aligning becomes more and more difficult.
The scope of this article is to present a set of tools to identify and manage stakeholder expectations. The tools are applicable both in the planning and execution phases and will be divided in proactive tools, to use in the planning phase and reactive tools, to support the project execution.
For each tool a brief description should provide the reader with enough information to apply it, and links for further information.
Contents |
[edit] Project Management and Stakeholder Management
Stakeholder Management is used to describe the process of identifying, assessing and building a relationship with the stakeholders. Stakeholders are defined by the ISO 21500 standard as "a person, group or organisation that has interests in, or can affect, be affected by, or perceive itself to be affected by, any aspect of the project" [1].
Any project manager should identify and categorize all the key stakeholders defining which interests they have and how important they are for the completion of the project.
Most of the literature on project management recognizes the importance of stakeholders. As an example:
- PRINCE2 [2], states that in order to run a successful project, the project management team should have an effective strategy to manage communication flows to and from stakeholders. It also puts an emphasis on the importance of analysing the involved stakeholders with the purpose of being able to engage properly with them. Furthermore, it underlines the importance of stakeholder involvement, especially in projects that are not a part of a program.
- The 5th edition of PMBOK from the Project Management Institute (PMI) has recognized the importance of stakeholder management and dedicated a knowledge area to it - Project Stakeholder Management. [3]
Therefore, correctly managing stakeholders is extremely important. Indeed, even if different theories provide different criteria for project success, recent literature is converging on defining the project success as a result of stakeholder satisfaction. [4]
[edit] The importance of expectations in stakeholder satisfaction
From the previous section we understood how important ending the project with satisfied stakeholder is for the project success. In this section a summary of what expectations are in the field of project management will be presented as well as what the connection between expectations and satisfaction is.
Expectation in general terms is defined as "a belief that something will happen or is likely to happen".
In every project each stakeholder has different interests to participate or not, has different expectations as to the results of the project and has different definitions of when the project will be successful. Also the answer to the question "what's in it for me" is different for each stakeholder.
To better understand the concept of expectation and how it usually differs between stakeholders a practical example can help.[5]
Project: Refurbish homes and improve energy efficiency
- Central government is likely to perceive success in terms of reduced energy demand, improved energy security and reduced CO2 emissions. In some countries, refurbishment may also be a social policy measure to combat fuel poverty.
- Local government may be more interested in employment effects and keeping the building stock in good shape. In some regions, refurbishment may also be a social policy measure to combat fuel poverty.
- Participating companies may expect the project to create new markets and increased revenues.
- Residents (energy end-users) are most likely to value increased comfort, better living conditions and lower energy bills as important outcomes.
The PMBOK guide include the topic of stakeholder expectations in the topics of " Identify Stakeholders" and "Manage Stakeholder Engagement" that is included in "Project Stakeholder Management". However, the standards don't include particular procedures and tools to discover and manage stakeholders expectations besides the stakeholder analysis. [3]
In general, finding literature focused on stakeholders expectation is hard, and, as in the PMBOK, the topic is usually included in other tools and theories and does not stand by it self.
In the next section, the expectation confirmation theory will be presented as a proof of the relationship between stakeholder satisfaction and expectations.
[edit] Expectation confirmation theory
Expectation confirmation theory is a cognitive theory developed in the '70 by Richard L. Oliver. It was developed in a marketing literature but from there it was applied in multiple fields since its versatility and simplicity. The first application was to explain post-purchase or post-adoption satisfaction.
According to the model, satisfaction is caused by positive or negative dis-confirmation between expectations and performance. If a product outperforms expectations (positive dis-confirmation) post-purchase satisfaction will result. If a product falls short of expectations (negative dis-confirmation) the consumer is likely to be dissatisfied. [6]
Although this gap model of satisfaction was developed primarily within marketing to explain customer satisfaction, the relationships between buyer-seller is applicable to the relationship stakeholder-project manager [7].
Thanks to this model is clear that if we are not conscious of the expectation of a stakeholder, even if the project goes accordingly to plans, he might still be unsatisfied.
[edit] Toolboxs
[edit] Proactive toolbox
Ensuring stakeholder satisfaction is a process that starts before a project begins. The planning phase is the most crucial to understand what value is expected by the various stakeholders and how to actually deliver it. Indeed, once the project starts, modifications to satisfy stakeholders who were not included in the planning phases can cause big delays and cost increase.
The process has to begin by understanding who are the stakeholders involved (phase 1) and their relation with the project (phase 2). However, even after understanding the parties involved, stakeholders most of the time are not able to clearly explain their expectations. That is why in the toolbox two tools are dedicated to extract hidden desires and avoid communication misunderstanding (phase 3). Afterwards, stakeholders expectations have to be aligned and, when this is not possible, prioritized (phase 4). Once the expectations are clearly understood, the project manager should store the agreement in a written form to inform the project team on the goals and have a written proof in case that stakeholders change their mind (phase 5).
Figure 03 summarizes the process and shows the suggested tools.
[edit] Stakeholder inventory
The first step of managing the stakeholders expectation is to have the complete picture of who is a stakeholder in the project. The best method to create an exhaustive list is to hold a brainstorming workshop between the project team. The objective in this phase is to think creative to include every possible stakeholder. For normal projects, a brainstorm of 10-15 minutes should be sufficient.
[edit] Stakeholder mapping
From the stakeholder inventory is important to prioritize the stakeholders in base at their relationship with the project. For the purpose of this article, the theory background and detailed explanation on the different version of the tool will not be presented. The page Stakeholder Analysis explains in depth the concept and it's application.
The suggested version of the stakeholder mapping is the Power/Interest diagram. It is created by positioning the stakeholders in the different areas according to the estimated power, how much a stakeholder can affect the project, and interest, how much a stakeholder is involved in the project.
The x axis represents the interest, so the interest increases going from the left to the right. The y axis represents the power, so the power increases going from the bottom to the top.
[edit] Reverse brainstorming
Trying to understand the stakeholder expectation in a project, a main issue can be found in the lack of a clear vision from the stakeholder of its desires. If asked with direct questions like "What do you expect this project to achieve?" or "How will this project help you?" stakeholders can have some difficulties in answering.
Reverse brainstorming is a 5 step progress that solves the problems of direct questioning by exploring multiple factors in reverse. This encourages more creative thoughts creating robust solutions.
The project manager should reverse the question he would need to understand the expectations. Examples could be "How can the project dissatisfy you?" and "How could we fail this project?"; by asking this kind of questions participation is encouraged through outside-the-box thinking.
From this first first phase, the negative ideas generated are reversed again to understand what are the positive expectation of the stakeholder. [8]
[edit] Prototyping
After some meeting and information exchange the project manager should have a preliminary idea of the expectations of the stakeholder. In case this expectations concern data and measurable results it is easy to communicate and agree with the stakeholder. However, many times the expectations regard subjective evaluation and even if the two parties agree it is not obvious that they are picturing the same result.
Therefore, before closing the confrontation with the stakeholder about their expectations is important to make sure that there during the process a misunderstanding caused a distance between the actual expectation and what the project manager understood A prototype is an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from.[9].
In the context of this article, a prototype can both be a physical or digital representation of the final output, in case of a physical output, or a more abstract picture of the final state for project such as organizational change.
[edit] Value vs complexity grid
From the brainstorming a number of requirements and needs will be collected. However, in a project satisfying every expectation is impossible. The value vs complexity grid supports the decision making process of selecting the requirements to keep and the one to eliminate [10]. It is based on two factors:
- Difficulty and complexity: it is related to technical considerations on how challenging the implementation will be, therefore there is a need of clear measurements for the criteria and support of technical team in order to help define the complexity of each requirement.
- Value and importance: it considers the functionality each requirement represents, dependencies other requirements have on it, value/benefits realized for the organization, and the importance of the stakeholders that are associated with it.
From the grid the project manager should understand which expectations should be satisfy and which ones should be dismissed.
[edit] SMART requirements agreement
After multiple iteration at this phase stakeholder expectations should be clear. However, it is necessary to formally store the information collected as a project requirement both to inform the project team avoiding internal misalignment and have a agreement proof in case a stakeholder changes its mind.
A requirement is nothing more than an expected outcome of the project. However the way the requirement is formulated should not leave space to interpretations. In the absence of facts and details, the stakeholder will interpret and make up assumptions. Moreover, everything should be stated in the requirements, if it is not stated, it is not committed to be completed.
To ensure a flawless requirements definition each requirement should be expressed through as a S.M.A.R.T. requirement: [11]
- Specific: A good requirement is specific and not generic. It should not be open to mis-interpretation when read by others.
- Measurable: This answers whether you will be able to verify the completion of the project. You should avoid signing up for any requirement that cannot be verified as complete.
- Attainable: The requirement is physically able to be achieved given existing circumstances
- Realistic: Answers whether the requirement is realistic to deliver when considering other constraints of the project and requirements
- Time-bounded: Specify by when or how fast a requirement needs to be completed or executed
[edit] Reactive toolbox
Even after a meticulous planning process to understand and accommodate stakeholder expectations, new and unexpected expectations could emerge. This new expectations could emerge from stakeholders that were not considered before or by changes in the environment.
The new expectations are are usually hidden within a request to change some parameter of the project that have to be recorded to keep track of all the issues emerged (phase 1). Once the project manager comes across this requests, he/she has to act to understand what the interest behind this new expectations is. Indeed, as in the proactive toolbox, the direct request of changing something can not be the real need of who's asking. Negotiation techniques can support this process limiting the divergence from the original plan (phase 2). If there is no way to avoid changing plans, a delicate phase begins where the project manager has to understand how changing some parameters will influence the rest of the project and agree with the stakeholders a trade off between satisfying this new expectation and existing project requirements (phase 3).
Figure 07 summarizes the process and shows the suggested tools.
[edit] Issue log
When analyzing stakeholder expectation an issue represents the distance between the stakeholder expectation and the reality of the project. An issue log, in general project management term, contains a list of ongoing and closed issues of the project. While issue logs can be viewed as a way to track errors in the project, the role it plays often extends further. Issue logs can be used to order and organize the current issues by type and severity in order to prioritize issues associated with the current milestone or iteration[12].
In this toolbox, the issue log is the backbone to keep track of the emerged problems, what expectation was besides them and how they where solved.
[edit] Integrative bargaining
When a new issue is identified, a project manager can't just approve every change and keep changing the scope of the project. Changes in plan will cause distortions in cost and time of the project and could affect some other stakeholder expectation.
That is why is it important to understand if the issue has to be resolved and what the easiest way to solve it is.
Integrative bargaining is a negotiation strategy in which parties collaborate to find the motivation behind the initial request and develop a "win-win" solution to their dispute[13]. In other words, the project manager has to understand what is the stakeholder expectation behind the request of a new project requirement and find others way to satisfy it.
Figure 08 gives and overview of the method and Video 1 visualizes the benefits of Integrative bargaining as explained in the article.
[edit] Project Management Triangle
To support the negotiation the Project Management Triangle is a tool for the project manager to understand the effects of accepting to satisfy a new expectation. It is formed by its three dimensions, time, cost and scope, and a side of the triangle cannot be changed without affecting the others [14] .
When a new expectation comes to the table, the project manager will now be able to analyze the feasibility of implementation and explain what other project requirements will be changed to accommodate the request. As an example, if a stakeholder request the project to finish before the set deadline the project manager will ask for a higher budget or to remove some features (scope).
[edit] Other tools
- RACI Matrix: The Responsibility Assignment Matrix (RACI Matrix) can clarify which stakeholders and how they are connected in a context of a specific task or project step.
- Risk Matrix: The Risk matrix can help to improve the robustness of the promises made to the stakeholders.
[edit] Field of application toolbox
These toolboxes are not designed for any particular project category. They have applicability in most of the projects, and they are particularly relevant when the project manager senses different interests from different stakeholders.
It is recommended that the proactive toolbox is used in the beginning of the project to ensure a correct stakeholder identification. Indeed, the usefulness of understanding the expectations once the project has already clear output would be quite low. Instead, the reactive toolbox is to be used once the exaction of the project has began. It should be kept on hand for when a new issue is identified to ensure that all new problems are correctly documented and managed.
Because of the strategic impact of expectations management, the responsible of the process should be the project manager. However, it is extremely important to include in the project team in the process to ensure internal alignment.
[edit] Case Example
To better understand the application of the toolbox, a simplified fictional case is provided below inspired by the construction of the University of Exeter’s new business school in December 2007 [15].
Proactive tools
The project manager identified the following stakeholders:
- University
- Student
- Government
He analyzed the stakeholder and developed the following stakeholder map:
Talking with the stakeholders, the project manager collected the following first inputs:
- a very clear explanation of what the university was expecting: enhance its position as an international business school through the creation of a state-of-the-art educational facility. The client wanted a building with ‘wow factor.
- a lack of ideas from the students on what they would like in the new facility.
- clear guideline in terms of budgeting for the government sponsoring the project.
After, he conducted a reverse brainstorming for each stakeholder focusing especially on the students that were not able to provide their expectations:
- the university and government results show that they would mainly be dissatisfied by a delays in the projects.
- the students were able to describe what usually makes a faculty building less attractive, and from the analysis of their toughs the project manager understood that they were incredibly interested in places to conduct group work. that were not requested by the university, and a new student bar.
Having a clear idea of the initial expectations, the project manager collaborated with some architecture and design firms to develop detail 3-D models and renderings of the outcome project to make sure he understood the requests from the stakeholders.
Analyzing the different expectation on the project through the value vs complexity grid the project manager discovered that a few of the request were going to be extremely difficult to realize and would have brought small benefits, while requests from marginal stakeholders were easily implementable.
After deleting the unfeasible expectations and other workshops based on prototypes with the stakeholders, the project manager recorded the expectation in form of SMART project requirements and started the project.
Reactive tools
Three months into the project huge protest from the student association began asking for the suspension of the project for the duration of the exam session. The complains were caused by the noise that disturbed the students in the library near by the construction site. By applying the project management triangle framework the project manager developed an initial analysis of what a month of delay, to wait till the end of the exam session, would have caused and discusses the results with all the stakeholders. Since the increase in cost was not acceptable for the project sponsor, the project manager established a discussion table with the student to develop a win-win solution.
From the discussion the project manager understood that the noise complain were not caused by the construction itself but by the trucks delivering the material to the site. Therefore, project manager and students agreed on stopping the deliveries from 10 am to 4 pm without any stop on the construction. The new delivery scheme caused a raise in procurement cost but the final increase of expenses was not comparable with the initial request from the students of stopping the project.
The project manager stored the information acquired on the issue log on including the root causes of the complains to avoid similar problems in the future and keep track of the change in project requirements.
[edit] Template
This template can support the proactive toolbox process providing step by step instructions and models for graphic visualization: bit.ly/TemplateAPPPM
[edit] Limitations
- Personal skills of PM are extremely important: In the book Managing Stakeholder Expectations for Project Success, one of this supporting pillars of this article, the author dedicates great attention to the soft skills of the project manager. Indeed, most of the tools and procedure presented are useless if the project manager is not able to communicate and understand the stakeholders on a personal level. Indeed, many times expectations are expressed by non-verbal communications and require a sensible eye to be spotted. Moreover, while contracting with stakeholders communications skills are vital to achieve positive results.
- Number of stakeholders: A critical limitation whit theories concerning stakeholders satisfaction is the relationship between the different stakeholder satisfactions. Indeed, some studies described that improve managerial performance in one stakeholder group can comes at the expense of performance for another group. However, more recent studies suggest that, within limits, managers are able to meet the performance expectations of three primary stakeholder groups simultaneously. The research paper,THE rules of stakeholder satisfaction (Kelly C. Strong et al 2001), presents a summary of this contrasting theories and a case study on the feasibility of satisfying three stakeholders groups simultaneously. However, even if this paper proves the possibility of satisfying different groups together, as the number of stakeholder increases satisfying all of them becomes harder and harder. That is why stakeholder mapping is of extreme importance, allowing the project manager to prioritize expectations.
[edit] Annotated bibliography
- A Guide to the Project Management Body of Knowledge (PMBOK® Guide), Fifth Edition -Chapter 13
The chapter "Project Stakeholder Management" explains what a stakeholder is for a project.
Moreover, it gives a good overview on how to analyze stakeholder and their impact on the project, and to develop appropriate management strategies to effectively engage stakeholders in project decisions and execution. It represents a good overview on current best practices of stakeholder management and is a good starting point to understand the general topic on which this article develops.
- Managing Stakeholder Expectations for Project Success:A Knowledge Integration Framework and Value Focused Approach Ori Schibi
This book provides plenty of material concerning stakeholder expectations.
This article is mainly related to Chapter 4, in which chapter, it is described how to perform a stakeholder analysis and why doing it has a positive impact on project success. In the rest of the book other topics of project management, such as communication, risk, change, and quality, are related with stakeholders and project success.
- Managing the Expectations of Stakeholders MAX Technical Training
This one hour YouTube video provides ten practical tips to manage stakeholder expectations.
This article takes inspiration from this tips and re-frames them in a more theoretical based approached. The video is a very good start for a practitioner not familiar with the topic and it provides useful examples on how the toolbox could be applied.
- THE* Rules of Stakeholder Satisfaction (* Timeliness, Honesty, Empathy) Kelly C. Strong, Richard C. Ringer and Steven A. Taylor
This research paper is an interesting view on the stakeholder satisfaction world.
It focuses on the role of trust in stakeholder satisfaction. Customers, stockholders, and employees of financial institutions were surveyed to identify management behaviors that lead to stakeholder satisfaction. The model used for analyze stakeholder satisfaction and the literature critic on the topic is of great value for understanding the content of this article.
[edit] References
- ↑ ISO21500. 2012. Guidance on Project Management. International Organization for Standardization.
- ↑ Managing successful projects with PRINCE2, TSO, 2009
- ↑ 3.0 3.1 Project Management Institute. (2004). A guide to the project management body of knowledge (PMBOK guide). Newtown Square, Pa: Project Management Institute.
- ↑ Cavarec, Y. B. (n.d.). Revisiting Definition of Project Success. Retrieved September 26, 2016, from http://www.pmi.org/learning/library/revisiting-definition-project-success-6098/
- ↑ MECHanisms | Make Energy Change Happen Toolkit. (n.d.). Retrieved September 26, 2016, from http://mechanisms.energychange.info/backgrounds/8
- ↑ Expectation confirmation theory. (n.d.). Retrieved September 26, 2016, from http://is.theorizeit.org/wiki/Expectation_confirmation_theory
- ↑ Strong, K. C., Ringer, R. C., & Taylor, S. A. (2001). THE rules of stakeholder satisfaction (timeliness, honesty, empathy). Journal of Business Ethics, 32(3), 219–230.
- ↑ How to Solve Problems with Reverse Brainstorming. (2011). Retrieved September 26, 2016, from http://www.halogensoftware.com/blog/how-to-solve-problems-with-reverse-brainstorming
- ↑ Design Thinking: Putting the Customer at the Heart of Development. (n.d.). Retrieved September 26, 2016, from https://www.mindtools.com/pages/article/design-thinking.htm
- ↑ Value vs Complexity - A Prioritization Framework. (n.d.). Retrieved September 26, 2016, from http://www.product-arts.com/resourcemain/articlemenu/1049-value-vs-complexity-a-prioritization-framework
- ↑ SMART Requirements. (2010). Retrieved September 26, 2016, from https://jessica80304.wordpress.com/2008/08/04/smart-requirements/
- ↑ What is an Issue Log? (n.d.). Retrieved September 26, 2016, from http://www.simplilearn.com/issue-log-concepts-article
- ↑ Beyond Intractability. (n.d.). Retrieved September 26, 2016, from http://www.beyondintractability.org/essay/interest-based-bargaining
- ↑ The Iron Triangle of Project Management: Balancing Your Budget, Scope, and Schedule. (n.d.). Retrieved September 26, 2016, from https://www.mindtools.com/pages/article/newPPM_54.htm
- ↑ University of Exeter Business School, Turner & Townsend. (n.d.). Association for Project Management. Retrieved September 26, 2016, from http://www.apm.org.uk/node/633#EXE