Recently I was asked for a high level requirements plan for a large IT conversion. I googled around a little for something standard. I found some good references (see links at the bottom of this post), but not exactly what I was looking for: a simple, method-agnostic layout of the high level steps and checkpoints in requirements for a big project, emphasizing interactions with business people. I then rifled my files to find the example below.
This summary plan frames up interactions with business subject matter experts and their review of results. The table lays out the steps, “granularity” (meaning how often each step is carried out), what comes out of each step, who does the work, and offers a few notes.
Before the table, here are two important definitions:
- Sponsor: Very early on in your project you should identify the one person who you need to make happy in order to succeed. The bigger the project, the higher up the sponsor. Keep in touch to make sure they know what’s going on, keep them happy, and if something happens that will make them not happy don’t keep it secret. Maintain a vibrant risk/issue process so that you can give them early warning of bad possibilities and they can help early.
- Stakeholder: A stakeholder is anyone who will benefit from or be harmed by your project. Requirements come from stakeholders. Be sure to build support even with the latter group if at all possible, and at least make the adjustments that will keep them from working to prevent you from succeeding.
Careful, this is just an empty vessel. Within this high level framework a team can apply whatever requirements techniques they want. (In fact, I highly recommend structured analysis techniques like use cases or process models, but that’s for the requirements team and this framework is for the PM). Of course a smaller effort suitable for agile techniques wouldn’t need something like this. This is for big transitions like conversion to a new COTS package, for example, where it is easy to get lost in the detail.
Hopefully if you’re a PM on a big project you’ll find this framework as useful as I did.
|
Step |
Granularity |
Work Products |
Responsible Group |
Notes |
|
Prerequisite |
n/a |
–Scope definition |
–Project manager |
Defines context for requirements gathering by defining project objectives, constraints, stakeholders, and schedule |
|
Preparation |
n/a |
–Interview checklist –Stakeholder overview –Requirements Standards |
–Requirements team –Project manager
–Requirements team with PM
|
Interviewchecklist should include date range, meeting participants, meeting objectives in terms of expected objects specified |
|
Interview |
At least once per stakeholder group |
–Meeting notes –Risks / Issues / Actions –Draft Stakeholder Group requirements |
Requirements team
|
Stakeholder group requirements are from the point of view of a single stakeholder group only |
|
Stakeholder Validation |
At least once per stakeholder group |
Stakeholder feedback on / correctionsto the three items resulting from Interviews |
Requirements team, stakeholder group |
|
|
Analysis |
Either after all interviews or throughout the interview process |
Project Requirements |
Requirements team (with stakeholder groups) |
Project Requirements result from analysis/refinement of requirements by resolution of inconsistencies, conflicts, and errors discovered in close review.This step should involve dialog with stakeholder groups. |
|
Approval |
PMO, Stakeholder Groups, Project Sponsor |
Approved project requirements |
Project management |
|
Here are some of the other references I found along the way, caveat emptor:
2 responses to “A pretty good requirements analysis checklist”
Good post!
Hi, I am peter ross I own business in the USA. The blog you have posted was very informative keep posting stuff like this. I would like to read more from you.