How Important is a Robust Stakeholder Analysis?

[Former Member]

One of the key pieces of analysis that every project should have as early in the project as possible is a very robust Stakeholder Analysis. A robust Stakeholder Analysis will include both internal and external stakeholders. While the internal stakeholders may vary based on the scope of the project, external stakeholders will generally include customers, vendors, regulatory agencies, strategic partners, etc.

When starting a Stakeholder Analysis, the change teams I work with try to envision anyone who might feel an impact from the implementation. We then describe and “quantify” the impacts to the various stakeholder groups. The goals of the stakeholder analysis are to do a thorough identification of stakeholders to be sure all stakeholder groups are included and then to identify what types and levels of communication, training, and support the various groups will need to successfully transition through the changes and issues inevitable with new processes and systems.

For teams I have worked with, the stakeholder analysis is a living document that is updated throughout the project as additional information and detail is developed.

I am curious as to how other OCM consultants are using a Stakeholder Analysis and when in the project life cycle it is developed.

I look forward to hearing from the community.

Caryl Barclay

SAP Organizational Change Principal

[Former Member · Accepted solution]

I have typically developed the Stakeholder Analysis with key project team members at the start of a project. Calling such a meeting provides an opportunity to talk about some of the OCM activities you will be doing accross the lifecycle of the project; activities having to do with stakeholders and otherwise. I try to make the meeting interactive so that the team members feel like their contributions are helpful and then point out that while OCM is coordinated by you and your team, the real input and knowledge about the business comes from all of them.

After the initial development of the tool, I pull it out and update it every 6 - 8 weeks. Especially if you find that a person has moved from one place to another in support of the project due to an OCM activity, I document and make sure the PMO/Steering Committee knows how and why that happened. Hence, your value is exhibited from that standpoint.

In terms of customers and vendors as stakeholders....I only separate them at the customer v. vendor level, not any lower. Communications to them usually happen twice: 1st to announce that the company is implementing SAP and to assure them of all the risk mititgation strategies that have been taken into account and 2nd to show them how their new invoice or P.O. will look and how to read it. Additionally, I would provide a FAQ document for use by all internal purchasing agents, customer service reps, and sales people to use. They know the customers/vendors better than you ever will and should take the ownership in explaining how the company is implementing SAP. If the internal folks need more/different info to answer questions, they can work through the OCM team.

Rebecca Potts

SAP Org Change Engagement Principal

[Former Member]

Caryl, is it possible to attach an example to this blog? I think the one you did at HMX was the most thorough analysis I've seen in over a decade of doing this stuff! Of course, we all know to customize for the client, and we always want germane and useful data captured, but I still think an example for those not working in OCM might be helpful.

What do you think?

Martha

[Former Member]

Caryl,

As you have indicated, the Stakeholder analysis is a very important document as it ensures that every stakeholder has been considered when conducting risk assessment work and action planning. By analyzing stakeholders, we can identify certain groups of Stakeholders, or individuals, and rate them as High, Medium or Low, from a "risk" perspective. When important Stakeholders are rated as "High risk" they can be highlighted in our Stakeholder plans and we should work with them accordingly, using all of the Change Management Behavioral approaches and tools at our disposal.

The stakeholder analysis will cover all businesses affected by the project implementation and should take place at the very beginning of the project (during the Project Preparation phase) and then it should be updated and monitored throughout the project.

John R. Davis

OCM Consulting Principal

Organizational Change Management

SAP Americas

[Former Member]

Dearest Caryl,

I am really happy to be blogging TECHNICAL SAP OCM.

I agree with everything you said and take the same approach.

There is a process underlying the Stakeholder Analysis, and that is maintaining a stakeholder database which then forms the basis of communications (such as e-mail addresses per stakeholder), training (per geographic region for example), impact analysis (per role for example) etc. Once you have a maintainable stakeholder database, you can then run reports which become your stakeholder analysis reports.

It really is a case of which comes first - The Chicken or the Egg?

The stakeholder analysis will start with identifying the correct stakeholder groups who either affect, or will be affected by the implementation. These could be Customers, Vendors Environmental Groups, Unions etc.

The stakeholder groups is what you use as "Master Data" for your stakeholder database.

Once the stakeholder groups have been identified and signed off by the client, the SAP OCM Specialist can then begin sourcing individual’s information within these stakeholder groups. An example is downloading employee information from SAP HR Personnel records.

Of course this is just a blog, however, may I suggest that we start a series of discussions from the first of the SAP OCM process, which according to SAP OCM Roadmap is:

<b>1.1 Initial Project Planning and Kick-Off</b>

1.1.1 Transition from Discovery and Evaluation

1.1.1.2 Review Discovery and Evaluation Documents

1.1.2 Enterprise Strategy Framework

1.1.2.1 Review All Required Strategic Documentation

1.1.2.2 Conduct Executive Workshops

1.1.2.4 Review Workshop Results

1.1.4 Project Charter

1.1.4.6 Develop Organizational Change Strategy

There is just so much that we can blog about with regard to SAP OCM, I was just thinking that if we gave it a structure, at least we can maintain a level of flow. Ofcourse just blogging about any aspect is also great, perhaps a structured SAP OCM project work-packages forum could be just one road.

I am actually just about to start a new Stakeholder Database/Analysis.

Thanks and Regards,

Paul

[Former Member]

Dear Paul,

Our OCM Team is actually doing something very similar on the stakeholder analysis. We determined the stakeholder and communications groups using top down (brainstorming). We are using a bottom up detailed cost center analysis to help define both roles and training plans. We plan to develop training plans by cost center and role. When we get closer to implementation, we can then pull the latest information on which employees are in the various cost centers to determine which individuals need to attend which training classes. We are currently working with both our detailed database and also a rather lengthy, but more readable, summary of the detailed information which we plan to present to the various business teams for validation.

As a next topic, let's take you suggestion and have a discussion on Project Planning and Kick-Off.

I am looking forward to blogging with you and our other OCM colleagues.

Caryl

[Former Member]

We develop the Stakeholder Analysis almost concurrently with the project. This drives all forms of communication, including who needs to participate and be informed of the project kick-off itself all the way through who will have an ongoing accountibility to stabilize the system after the core team disbands.

Updates occur formally, but tracking has been informal to ensure that stakeholder are progressing towards the desired role we need them to play. We step up, or down, our communications efforts based on how we track against the stakeholder analysis.

[Former Member]

Andrew,

Thank you for your response and for participating in the discussion.

I do have some additional questions. It is always helpful to explore what other are doing.

Do you include both internal and external stakeholder groups?

On our project, communication with customers and vendors will be important as both customer/vendor number and item numbers for both raw materials and finished goods will be changing.

We are planning to use our sales and customer services groups to help provide information on customers and our purchasing group to help with vendors.

Being customer centric, we are trying to geer our communications to the customer's communications preferences for key customers. To what extent do you customize communications for key customers / vendors? If you do customize your communications, how do you go about determining their preferences?

I look forward to hearing from as many contributors as possible.