Archive for the ‘stakeholders’ Category

Requirements and stakeholders

May 7, 2009

When assessing requirements practices within projects I often find a clear list of stakeholders has been created as part of project management activities. This list is usually part of a project plan, PID, or similar document. The associated sensitivity analysis is less common – and less public – but in most cases some sort of analysis has been done by project management.

Unfortunately I cannot say the same for the requirements discipline. Typically – among my clients at least – the requirements manager is happy to refer to the stakeholder list provided by the project manager. Occasionally they have been involved in the analysis. Hardly ever do I see an analysis of what I consider useful from a requirements perspective.

While requirements stakeholder analysis (and management) has an overlap with project management stakeholder analysis, I believe there are some important differences. I will not go into the differences here, instead I wish to look at some often neglected aspects of requirements stakeholder analysis. To my mind, a requirements manager should be looking for answers to questions such as:

  • Which stakeholder groups have a valid interest in the product or service being developed (or modified)?
  • Who is a suitable representative for each valid stakeholder group for requirements-related decision making purposes?
  • Is this representative available for the project?
  • Does the representative have the mandate to make the necessary decisions?
  • How should the project involve each valid stakeholder group in requirements development activities? Note that this could be done entirely through the representative, or could involve several other members of the group – e.g. in interviews and workshops.

To answers these questions, some characteristics of each stakeholder group will need to be collected. This is often called a stakeholder profile. As a minimum this should include the name and short description of the stakeholder group and what their interest in the product or service is. Many other useful attributes have been suggested, notably by Ian Alexander, Suzanne & James Robertson, and Karl Wiegers. Pick what is relevant for your situation.

For example, one organization I worked with knew that some stakeholder groups were spread out geographically, while others were concentrated at the company’s headquarters. This was relevant when deciding on workshop participation for eliciting requirements – flying people in from the other side of the world is costly both financially and in the time it takes up for these people!

It is a happy day when I stumble upon a project in which the requirements manager has looked at even half of the questions. Am I asking too much? Why is requirements stakeholder analysis (unlike project management stakeholder analysis) so poorly understood – or poorly performed?

Any ideas and comments are welcome! Also I’d love to hear your experiences with requirements stakeholder analysis.