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?
Thanks Paul for sharing experience.
In my case, I’ve notice people become reluctant to review again and again. As per my experience, your technique works well, because it drives off the fear of reviewing whole document in one go. That’s why, in many cases, when asked to do final review, I got reply …last comments in review are considered final. That is no more final review.
Great article Paul! I agree this is a much more efficient approach particularly if your project is going to result in a significant number of requirements. My meetings are exciting & fun but no one can stay awake & alert for a 4 hour marathon review session, right?
I also agree with your assessment on how a requirements management tool really helps with your model. I have been a big believer in RM tools as they make a huge difference compared to Excel or Word (yuck). I have used your suggested model using products from IBM and Borland (CaliberRM) and both worked great in this situation.
Great suggestion – I look forward to hearing what others think!
@Viki – you are correct in saying that people don’t want to get together over and over again to review, and then have to sit through a marathon final review session. There’s only so long that they can stay tuned-in. Different people have different levels. My rule-of-thumb is to make meetings no longer than 90 minutes. Any longer than that, and I find people starting to “check out”. By keeping each session to that length and having a razor focus on those requirements that you have to review, it helps move the meeting along and keep the stakeholders engaged. Also, another thing is to only invite those that need to be involved that day. If you are reviewing sales processes and have nothing planned for Operations, don’t invite Operations to sit in the meeting for 90 minutes when they have nothing to contribute. This will help establish trust with your stakeholders that you are using their time wisely.
@Jennifer – right on with Caliber! That’s the tool that I used when I used this process. There are other tools out there that you can use to do the same thing (yes, even Word and Excel), but the RM tool just made it so much easier. This process also works well for those big projects when the analysis phase is 8 weeks long. During a final review, people don’t remember what was discussed in the first week and they bring up all sorts of questions that were already covered. While you may have the answers documented, it takes time in that final meeting to repeat back what was discussed and decided upon. By approving sections of the document as you move along, you are avoiding the questions that may arise in the final-final-final review that were answered weeks ago. And with some of those big final-final reviews, how do you get them under 4 hours? 🙂
Hi Paul. I tried a similar approach to the one you’ve outlined on a very large project at my company so I thought I’d share my experiences. We held about 10 different workshops each focusing on a different area and only inviting those people who had an input to that part of the project. We used DOORS to manage all our requirements and make it clear which were approved and which were still draft, as well as tracking all the changes. At the end of each session we could baseline the module and have a permanent record of exactly what was agreed at that point and by whom.
Unfortunately what we didn’t do was have one facilitator who was present at all the workshops. There was just too much work to be done in the time we had for me to attend every session so I delegated responsibility for some of them and obviously didn’t explain well enough what needed to be achieved. As a result the output from each workshop varied quite dramatically and thus the quality of requirements generated was not consistent and this led to unnecessary re-work.
So yes, I definitely agree with your approach but you either need to have a consistent facilitator or a better defined process that we did.
@Simon – good for you for putting this in play. When I tried it, people found it unfamiliar that they couldn’t ask questions on what was not ready for review. But then when they saw those sections finished, they knew it was a better use of time because the burning questions they had were answered once we made the sections ready for review. And then we could spend more time targeting the important questions.
You bring up a good point, though, about having a consistent facilitator or a defined process. If each session was going about it differently, it’s a great way to keep stakeholders off-balanced, but not the best for them to get consistency. The first time that I tried what I wrote about in the blog, it was confusing because it was different. Once my group went through 3-4 meetings, we pretty-well had the process defined and it was a decent success.
Thanks for getting engaged in the conversation and sharing your experience. If you’re on Twitter, Follow me at @PaulTheBA. Cheers!