Adam, I think you are definitely right as there are many ways to manage this information. A project risk list or issues log may not be specific to requirements-related risks, so on a large project it can be a difficult tool to use as a requirements checklist of sorts as you’ll end up wading through many irrelevant risks and issues relate to the project as a whole and not just the requirements.

What I found when I started thinking about stakeholder concerns is that it broadened my perspective of what information to capture. Typically I try to keep risk and issues lists relatively short and actionable. They need to be reviewed and updated often. Issues are driven to closure. Risks are actively managed. Stakeholder concerns, on the other hand, can include risks and issues, but they can also include other pieces of information or individual perspectives that might not make it into an action-oriented list.

In this particular informal environment I was also using stakeholder concerns as a way to communicate valuable requirements-related information to the development lead who was filling a systems/technical analyst role. This helped eliminate redundant conversations with the stakeholder group and put some context around the business requirements.

I’m wondering whether beneath every ‘stakeholder concern’ lies an underpinning ‘Risk’ or ‘Issue’….for every project I’ve worked on we’ve always had a ‘Risk Log’ and an ‘Issues Log’, which are typically just Excel spreadsheets. Even for projects that don’t require as much so-called formal project mgmt rigour we always have these logs, the rationale being that for any project no matter how big or small, there are always going to be Risks and Issues that come up and these need to be captured somewhere.

In the past, we’ve actually used a single spreadsheet to capture both – we simply have one of the columns in the spreadsheet set as ‘Type’ from which either “R”(isk) or “I”(ssue) must be chosen for each record that is entered. In the specific example you used, this could be reframed and stated as a risk. I suppose for something that is not deemed as being either a ‘Risk’ or an ‘I’ssue – you could set up a third “Type” that being “C”(oncerns).

Like most things, there’s more than one way to skin a cat. The important thing is that as long as it is being captured and is visible then that information can be used.

Adam

When I started writing this post, I was capturing them as you are — all on a single page. I think this can still work well for small, well-defined projects.

For larger projects, I’m considering a separate page. We use a wiki, so each project has an overview page which is organized much like a traditional scope document. I’ve added a new section to this project overview page to capture concerns.

They do come up in multiple stages as stakeholders can have concerns about the need, about a specific requirement, a specific implementation decision, etc. I’m now leaning towards the fact that embedding them in the requirements documents, though it promotes visibility, makes them harder to manage. Like risks, issues, and other miscellaneous information pieces for a project, I need to own the list and own that the items on the list are addressed.

Laura

Michelle

Do you capture your stakeholder concerns on one page and then capture your requirements on another set of hierarchical pages?

At the moment, I’ve been placing all of these on a single page to avoid burying the concerns under too many layers of clicks. I’m trying to keep them more visible, so readers are reminded of them.

Are these coming together all at once or at different stages in your elicitation?

Stages. While I wish all concerns would come out all at once, it never works out that way.