4 March 2008

On Stakeholder Communication

I had an opportunity to listen to a webcast on Catalyze called Designing a Sure-fire Stakeholder Communication Strategy.

Barbara Carkenord discussed the importance of conducting Stakeholder Analysis and developing a Communication Plan in the Requirements Gathering process. Here are some take-aways that will be helpful in any requirements communication process.

A firm understanding of all stakeholders involved in a project is paramount to business analysis. While documenting such analysis may seem extraneous and perhaps impractical, the knowledge gained from doing so is invaluable.

Barbara highlighted 7 Golden Rules to abide by when coming up with a Stakeholder Communication Strategy:
  1. Identify the people
  2. Get to know them
  3. Engage them early and communicate often
  4. Identify potential problems
  5. Reduce problems with your communication plan
  6. Fit that knowledge into your business analysis work plan
  7. Review alignment to project goals and adjust as necessary
Stakeholder analysis includes determining:
  • The stakeholders (who)
  • Their role in the project (what)
  • Their characteristics (what)
  • Their availability (when)
  • Their location (where)
  • Their motivations (why)
In my recent dealings with the stakeholders on my project, I found this form of analysis highly insightful in determining what questions can be directed at a particular stakeholder, lessening the amount of time taken to elicit accurate requirements. In listening to and documenting every stakeholder's concerns and motivations, I was able to see potential roadblocks in the project early on. And subsequently, in working through these issues with my project manager earlier on, we were able to minimize the loss of time and resources in analyzing and communicating requirements with our clients and our developers.

It is important to review such documentation prior to meetings so as to recognize the strengths, weaknesses, opportunities and threats in discussing aspects of the project with a specific stakeholder. If the goal of stakeholder communication is to engender trust among all parties involved in a project, then knowing how each stakeholder is motivated and works allow the BA to have more success during requirements elicitation.

A simple MS Excel Workbook with separated with worksheets, each representing a project stakeholder is sufficient enough to capture details of every stakeholder. I have taken to answering the 'W' questions as listed above as a starting point, but also included more material, including any information that may help me understand the stakeholder or the project better.

Having documented such material, my PM and I were able to plan our meetings more effectively, knowing exactly WHO mattered in WHAT discussion and WHY, and WHAT strategy was best way to draw information out of them. I went further to derive WHAT forms of documentation each stakeholder would need in order to lessen the burden on my end when writing up documents for them.

With regards to this particular project I had, having Business Requirements Document supplemented with high-level business system use cases were appropriate for the business users and management. A User Requirements document was appropriate material for the developers, and a separate system configuration and installations document was also written up so that the client's IT administrative staff was provided the ideal level of information for them to carry out their job in maintaining our software on the client's side.

Not knowing these needs would have left me in a frenzy of documentation that had little purpose and direction to any stakeholder - Lots of pain but no gain.

Therefore, if effective requirements communication leads to more successful projects, then understanding the stakeholders in their entirety will certainly go a long way in improving our work and delivery.

Photo originally by Hugo and sourced from flickr here.


  1. Anonymous2:30 am

    Hi Craig - interesting article. Coincidentally I blogged about stakeholder management a couple of days ago - see http://www.durantlaw.info/The+Stakeholder+Management+Target . I divided the staeholders into those who must be actively managed, those who are engaged, those who are kept informed, and those you just monitor. The idea is a bit raw, but maybe it is useful?

    Also Doctor Lynda Bourne has done some work on stakeholder management, and uses the notion of stakeholder circles. Her thesis - http://www.mosaicprojects.com.au/Resources_Papers_021.html#Top - is an interesting read.

    Regards Graham

  2. Hi Graham, I think your blog on stakeholder management lends itself well to this post.

    In essence, the goal is to be able to identify stakeholders, recognize their contributions and needs in order to better understand and address requirements in a project.

    Thanks for your supplementing this post with some great material!

  3. Anonymous12:03 am

    Hey Craig,

    You keep cranking out these nice, relevant, not beat to death articles. This topic, in particular, is much overlooked. Cheers.


  4. THanks to Chris, part of the new "Better Projects team" on this one.