15 March 2009

Identify Project Stakeholders, a first step in requirements management

I finally got a bit of a stakeolder analysis done for my project today. Questions it helps answer...
  • What groups within the organisation will use the system? 
  • Who is representing thier needs to my project team?  
  • Will there be any orgotten requirements?  
  • How will we release features to them? 
  • How will we manage the change that comes with new tools?
Not to mention the usual stakeholder analysis benefits!

Alistair Cockburn writes:

"One consultant described the first time he and his group listed the stakeholders and their interests for a system they had recently shipped. They suddenly found themselves looking at most of the change requests that had been generated in the first year of operation! In other words, had they simply written down the stakeholders and interests for each use case early on, they would have avoided an entire category of mistakes that didn’t show up until after they had delivered their system. Other people have reported similar experiences. Several people say they find value in listing the stakeholders and interests however casually and informally their capture requirements."

Photo by ewanr CC @ Flickr


  1. I'm going through a similar exercise on one of my projects, which is unusual for its large number of stakeholders. I've found that the stakeholder analysis has helped communicate the project's sheer scale to project manager and customer alike. Additionally I'm now in a better position to estimate resources and effort required for the remainder of the requirements gathering.

  2. Craig,
    We use a process that determines:
    1. The needed capabilities
    2. The requirements
    3. The stakeholders
    4. The physical deliverables

    Then a map is built that cross references all these connections. The result is a clear and concise connection between, who, what, why, where, when, and how.

  3. Glen

    It's a perfectly sensible world you are writing about.

    I am constantly surprised by the different levels of experience and project maturity different places have.

    I find that in political organsiations the stakeholders 'wants' come up before requirements because there is a bit of trading - getting people to buy into the project in exchange for addressing some particular issues.

    Potentially another way is to start with "whata re the needed capabilities (at just a high level) and then what are our capabilities - and then work from there.

    I could see that working in a tough stakeholder environment.

  4. As so many projects fail due to unmet requirements, it is critical to keep the people responsible for them informed throughout the project to ensure they track the organisations needs. After all, it is their sign-off that is the true measure of the success of the project.

    As requirements can change, it makes sense to store these along with the task that delivers them within the PPM system.

  5. A few years ago, I performed some research regarding the successful execution of large IT projects. One of the attributes that I studied was stakeholder involvement. My findings mirror what Pradeep has observed – it is critical to keep stakeholders informed. Frequent stakeholder involvement was found in 84% of the successful projects. However, I was surprised to learn that 12% of the projects were successful with infrequent stakeholder involvement.

    For those interested, the findings of the stakeholder portion of the research project are presented on the Feb 19, 2009 posting at http://managementhouse.blogspot.com/