Walkthrough meetings are one of the common business analysis techniques identified in the BABOK. They’re used to identify (but not necessarily correct) errors or inconsistencies in work products – for example a walkthrough of a requirements document might be used to verify the completeness of requirements.
If you’re running a walkthrough meeting it can be a bit daunting. It’s all too easy to get off track or try to fix (rather than just identify) problems.
Here’s a guide to help you run a successful walkthrough meeting:
What It Is
Peer review of a work product, document or specification, conducted in an ego-less but structured fashion. The objective is to find errors, not to correct them.
What It Achieves
A team approach to finding errors and inconsistencies. A team approach offers a much better chance of identifying all the issues.
Who Does It
The author(s) of the document and the subject matter experts and stakeholders who have the responsibility for producing it.
The manager should only attend if she/he has knowledge which is specifically needed and should not be the facilitator.
How Is It Done
Specific roles are given to participants. The author presents the item section by section. A scribe notes all items requiring correction and all decisions of the participants. A facilitator keeps everyone on track.
All participants should receive adequate preparatory documentation – including the item to be reviewed, an explanation of objectives, and (possibly) suitable checklists. The participants should be given adequate time to study the documentation in advance.
A specific time limit should be imposed for the walkthrough meeting (not more than 2-3 hours). Any longer and participants may be tempted to rush through the process just to get to the end. If reviewing large documents/specifications, schedule separate sessions covering different sections.
Problems To Watch Out For
Needs a competent, unbiased facilitator.
If the boss attends then: (a) the author may become defensive; (b) others may play political “games”; and (c) the positive team-building effect of the process will not take place.
If the objective of “finding errors, not correcting them” is forgotten, then argument on the “best way” to do something is likely to result. This is not only time-wasting but compromises the author’s sense of ownership of the product.
What Needs To Be Documented
The objective of a peer review is consensus – so it’s wise to record who was there, what was covered and what was, and was not, agreed. The role of the participants should also be identified (e.g. author, SME, stakeholder).
At the end of the meeting there should be a clear indication as to one of the following:
- Accept as is
- Revise, no further walkthrough
- Revise, walkthrough again (action list)
* * * * *
Now you might think that we’re breaking one of the rules with point 2 above, but as you get skilled in the art of facilitation you’ll recognise when an item can be fixed there and then or when it needs to be deferred for subsequent action.
Either way you’ll need to finish the meeting on a positive note to give participants a sense of achievement. Even if the result of the meeting is a whole new list of action points, at least the errors been identified now rather than later!
If you enjoyed this article, you may also like:
Facilitated Workshops – When and Why?
A Manager’s Guide to User Acceptance Testing
Join our 2-day course:
