Ooops, I Forgot a Key Stakeholder!

Ooops, I Forgot a Key Stakeholder!
By Sharon HoSang

I was the business analyst working on a debt management project. One of the deliverables was to develop standard letters to be sent to customers who were in arrears. These letters would differ based on the age of the arrears in terms of number of days. It ranged from 15 days, 30 days, 60 days and 90 days arrears.

It was time for me to look for “stakeholder” defined to be any person or organization that is actively involved in the project, or whose interests may be affected positively or negatively by execution of the project. As you know, stakeholders can be internal or external to the organization. I made a list which excluded the communication manager who had the power to determine the message and structure of the letters.

The letters were completed and submitted to the approval committee for ratification and sign off. The objective was achieved. It was at this stage that I realized that the communication manager should have been consulted and be a member of the committee.

Remedial Action

I quickly informed the committee of the gross mishap and asked for permission to reach out to the communication manager before the letters were released for use. Permission was granted. I invited the communication manager to lunch away from the office which represented a neutral ground. I apologized profusely, and asked for her valuable input. She was gracious enough to oblige me and we resolved the issue. She suggested minor word changes, which did materially affect the output of the letters. Boy was I grateful… you bet!

Lessons Learned

Process of Identifying Stakeholders and their Interests

In identifying stakeholders, the business analyst should gather all resources such as the:

  • Project Charter which authorizes the project manager and the project that would assist me in identifying the stakeholders.
  • Templates, stakeholder registers, lessons learned from former projects. Of course, this depends on whether these were properly documented and stored in a repository for easy access.

  • Procurement Documents if there are outside contractors. This would depend on the nature of the project.

  • Standard Procedures, whether in the organization or in the industry in which it operates, the system and the culture of the organization.

Meeting

Invite representatives of a broad cross-section of the business areas and departments that have an interest in the outcome of the project. These may include the high level management, sponsor, customers, users, project manager, product champion, line managers, business process owner, subject matter experts (SMEs), service manager, business architect, solution providers, testers, maintenance programmers and many more depending on the project.

Ask pertinent questions in order to determine who will be affected by the success or failure of the project. Determine what need or opportunity the solution will satisfy and this will give an indication of each stakeholder’s interest in the project. What constraints such a policies, procedures and standards, the stakeholders place on the system. What are the capabilities they would like to see in the solution? Here I am only listing the broad category of questions. They are to be broken down into specific questions in order to unearth the information.

Document the responses in the “Stakeholders and Interest Table” and a vision document to capture the features of the solution.

Relationship Building

The purposes of identifying stakeholders and their interest in the project are to:

  • Build relationship – the more you know about the stakeholders, you are better able to design the communication to satisfy their needs. This requires flexibility on the part of the business analyst to deal with all the different stakeholders and their preferences for communication.
  • Put all concerns about the project and or solution out on the table. This minimizes surprises that can derail the outcome and schedule of the project.

  • Easily identify oppositions to the project and or solution. The business analyst can plan risk mitigation strategies on how to deal with the opposition.

  • Open a plethora of ideas from such vast group of stakeholders.

  • Gain support and commitment for the project and or solution. When they are on board, the project has a chance of succeeding.

  • Understand the political environment of the organization.

Therefore, the business analyst should be a strong facilitator, consensus builder and negotiator in order to succeed at managing stakeholders and their expectations of the project and or solution. These by no means exhaust the topic of stakeholder identification and relations. It is however, a good place to begin in order not to omit key stakeholders and their input. You might not be so fortunate to get the matter resolved as quickly as I did. This could have dire consequences on your project outcome and schedule. Be warned!

Sharon HoSang is an engaged leader, with ten (10 +) years’ experience managing multiple projects. She has proven ability to identify, analyze and solve thorny technical problems that hamper operational efficiency and effectiveness. She has Initiated and managed cross-functional teams. You can contact Sharon via Linkedin.

PMHut Team

PMHut Team

PMHut.com is a website dedicated to providing PM articles, detailed project management software reviews, and the latest news for the most popular web-based collaboration tools.

Leave a Reply