That’s right, I said it. Stop doing final document review meetings. They take a lot of time and effort to plan, time to get people in the meeting, manage people’s schedules, and then facilitate the final meeting itself. When the document is one of those “200-page monsters,” it’s even tougher to keep people engaged for the length of the meeting. But, you still need to have your documents reviewed and signed-off, right? Without a doubt. What I’m proposing is that you get “sign-off” as you go along, instead of one, big final review at the end. That way, when the document has been finished, it’s already signed-off because the stakeholders have seen and approved all of the requirements.
It takes some planning on the BA’s part, but in the end, it’s a very effective way to run the analysis phase of a project. Here’s what you need to do. Each requirement for the project will contain one of three statuses:
- Draft – this means that the requirement is still being written and will not be a part of any meeting’s discussion.
- Ready for Review – any requirement with this status will be reviewed in one of the requirements workshops, or working sessions. This status is the one that the stakeholders will pay close attention to.
- Approved – the requirement has been reviewed in one of the working sessions, and approved by the stakeholders.
First, you need to plan the analysis phase of the project. As you do so, think about the logical groupings of processes and how they decompose. If you haven’t created a process decomposition diagram yet, now would be a great time to do so. It may be that not every stakeholder needs to be involved in every requirements workshop. This helps you keep only those people who are involved in the processes engaged. Once you understand all of the processes in scope, you have a better idea how to structure the requirements workshops.
Second, set your process as follows: each requirements workshop that you hold will have a basic agenda framework. The framework is set up as: review the requirements that are in a “Ready for Review” status, then discuss new requirements and processes. Since the workshops are planned around specific processes in the decomposition, it becomes very logical to review that way.
Once you finish the workshop, update the requirements as necessary, and change the status to “Approved”. Then, repeat the process in the next workshop. With each workshop, you are essentially reviewing requirements and signing them off. Each meeting is not as long as one final review, people are better able to stay engaged, and at the end of the elicitation, the document is (theoretically, at least) signed off.
Once you ask for approval at the end, all of the stakeholders have reviewed the document during the elicitation phase, and can quickly provide sign-off and approval at the end without a lengthy final requirement review. It also helps to remove swirl at the end since the requirements have been reviewed and discussed in the requirements workshops, and not several weeks later when thoughts and ideas have been forgotten.
This technique can be used with any metholodology, but having a requirements management (RM) tool makes it easier. How? First of all, the RM tool contains statuses for requirements. Having a status within the tool helps you manage them as you move forward. Secondly, the RM tool will help you with traceability. As you move through the document, you need to know how all of the requirements relate to one another. Changing a requirement in week 6 may affect one that was Approved in week 2. You need to know where those exist, and the RM tool really shines here.
Have you used a process like this before? How has it worked in your organization? Thoughts?
- A Requirement from the Business May Not Be a Business Requirement - May 13, 2013
- My Time is Up! Time to Re-certify my CBAP! - April 8, 2013
- “Yeah…but so what?” - March 11, 2013
- When Did Process Improvement Start? - March 5, 2013
- Email: Help or Hindrance? - January 29, 2013
- Good BAs Define Requirements for Orange Juice - September 4, 2012
- Why Use Business Analysis Templates at All? - August 20, 2012
- When is Analysis Complete? When You’re Finished! - June 18, 2012
- Attack of the Conflicting Business Rules - May 17, 2012
- Interface Analysis – it’s not just an afterthought - March 26, 2012