What is Requirements Management all about?
Requirements Management sometimes are neglected on a project and often it is because it gets overshadowed by the Project Plan.
Do our Online Business Analysis Practitioner Course and earn 24 PD hours!
As a business analyst we tend to enjoy planning our work but very often we neglect doing proper Requirements Management planning upfront! We tend to jump into the requirements gathering activities before clearly planning out how we will manage our requirements during the entire project. This is often because our project managers get us on board at the point when requirements gathering becomes high priority according to the schedule and this causes us to ‘just get on with it!’
What is involved?
Requirements Management essentially includes all aspects around how we will go about managing the requirements on the project. This includes looking at:
Requirements Gathering Approach
This part has a reasonably high impact on how you plan the rest of the Requirements Management plan. Here you should look at what is the most appropriate way of gathering the requirements for your project. Work with your project manager and review the following factors:
- How much time do you have to assign to requirement gathering activities?
- Will you be starting with an ‘open slate‘ as it were or will you present your stakeholders with a draft set of requirements to validate?
- What method of requirement gathering will be used? Interviews, workshops or research?
- At what level will you be gathering requirements? Is it going to be high level business requirements or will it be more specific lower level functional and non-functional requirements?
- What process will be followed to review and approve a requirement document?
These are some of the questions you should ask during the early stages of Requirements Management when you look at the Requirements Gathering Approach.
Roles & Responsibilities
When you are part of a larger project or program of work and there are more than one business analyst assigned to the requirements activities it becomes very important to define roles & responsibilities.
You, as the lead business analyst should ensure that all the requirements related work have been assigned to the different business analysis roles on the project. Often on larger projects there are different subject matter areas and it often makes sense to divide responsibilities up by subject matter area but be sure to agree that each business analyst’s role also includes to adhere to the same approach to requirements gathering, validation and change control! A minor but essential point is to ensure all use the same template for the requirements document or documents traceability.
You should make these responsibilities clear to your business analysts and ensure everyone understands the agreed approach, time frames and deliverables expected. Ensure this is document within your Requirements Management plan. Manage the team with regular team catch ups.
Stakeholder Analysis
Stakeholder Analysis takes on many shapes but it is about you understanding who you are dealing with in relation to the business requirements.
Stakeholders are those groups or individuals who will either be directly or indirectly be affected by the implementation of whatever solution you are gathering requirements for. Stakeholders can include business stakeholders who provide you with requirements, they could be senior roles such as business sponsors or decision makers or they can be operational staff who is only indirectly involved. It is imperative for you to make a list of all your stakeholders, understand their roles in the business and even more importantly their relationship to your requirements!
Ask yourself these questions:
- Who will be affected by the proposed solution in the business?
- How will each of these parties be affected?
- How involved should each stakeholder group or individual be in the requirements gathering, validation and approvals processes?
- Look at each stakeholder or group and decide how they feel about your requirements activities. Are they a great fan and supporter of the project, are they very negative towards the project or are they somewhere in between?
See the Stakeholders pages for more ideas on how to deal with all the different types of stakeholders you will encounter.
Requirements Change Management Plan
All business analysts will know that requirements change is always present on any project. It can however get quite out of control if you don’t implement a requirements change management plan early as part of your Requirements Management plan. This is also a good time to decide how you will implement requirements traceability in your project. During the early requirements gathering and validation phases of your work the requirements changes quite often and can change significantly, the impact is not high on the project yet though. It is when requirements change comes into the picture down the track that it becomes much more expensive to cater for.
Agile development was established as a great methodology to cater for the fact that change is constant in any project and is actually quite a good thing! The trick is to manage that change well and in a control way and have all your stakeholders, including your project team following this methodology.
Other more traditional and common ways of managing change after a certain stage of a project’s life cycle is via change requests. The Change Requests are formal artefacts that describes the change requirement and get managed like its own mini-project. It gets reviewed, approved, estimated and scheduled to be implemented.
Return from Requirements Management to Tools & Techniques..
Return from Requirements Management to Business Analysis Excellence..