Leading through transparency: the value of a requirements management plan

Being a leader within your organization requires a consistent commitment to results and continuous improvement. It’s also about establishing transparency into what you are doing, why you are doing it, and how your activities drive value within your organization.  A solid requirements management plan can help you achieve many of these leadership goals.

Although I’m a planner by nature, I’ve shied away from documenting formal requirements management plans for years because all the examples I’ve seen have been full of formality and fluff. In late November, I attended an IIBA webinar hosted by Julian Sammy, Chief Architect of the IIBA and Process Manager at BMO, and he changed my mis-perception rather quickly.

According to Julian, a requirements management plan should fulfill 3 main objectives:

1. Describe your approach to requirements analysis, including how you’ll engage stakeholders, document requirements, establish traceability, perform scope/change management, prioritize requirements, and approve requirements.  This sounds like a lot of information, but the point is not to dive deep into “how” you’ll do each individual item, but to include key talking points and decisions-driving explanations.
2. List your stakeholders and their respective roles. This list should include every individual who will contribute to the requirements process and indicate if they are a source of requirements, reviewer, and/or approver.
3. Describe your plan.  This is where you provide the sequence of steps and actions you’ll be doing and how long each item will take.

This set of objectives changed my thinking because the focus of the first two steps is on gaining buy-in across your organization on core elements of your requirements process. Walking through these questions exposes gaps in your approach and provides a structure to frame discussions with members of the project team. Moreover, a lack of clarity in these areas results in misses such as an forgotten stakeholder, varying criteria for prioritization, or missed deliverables — all potential causes of poor requirements resulting in projects that fail to meet expectations.

The third step, describing the plan is a critical piece and I think we should aim to be as detailed as possible.  Business analysis tasks should be clearly linked to items in our approach and this is what allows us to negotiate schedules and deadlines in a meaningful way.  How many times have you been asked to shorten the time frame for producing a deliverable?  How often have you been able to clearly express the impact that will have on the quality or scope of the deliverable in terms that your project manager can understand?  Simply put, creating a detailed plan creates transparency into our activities.  Linking the plan to an approach shows the value of each task.

I don’t want to minimize the effort it will take to get to this sort of a plan, because it’s significant, but the value of getting there is equally significant and potentially puts us on a new level within our organizations.

I’d love to see your comments on how you’ve used requirements plans.  What have you accomplished with one?

Related posts:

1. Reverse engineering requirements: Create a Work Plan
2. Requirements specifications: what to do when you must start from scratch
3. Grooming the product backlog: agile requirements management for improved sprint planning

Tagged as: iiba