The next step is to conduct a quick document walkthrough either using the document itself or some kind of presentation software. It is good idea to plug your laptop into the overhead projector so that everyone can see what is being discussed and recorded. I typically opt for a Word document so that all of the comments, critique, feedback and follow-up items can be recorded right there. It is a good idea to let people word their comments by themselves rather than rephrase them in format acceptable to you. This way you can avoid future misunderstandings about the content of the feedback.
Whatever form you decide to choose – comments in the word processor document or remarks in your notebook – it is worthwhile to re-record all of the action items from these meetings into some kind of “Issues List” and disseminate it to all of the meeting participants and other project stakeholders. Personal experience shows that incorporating this “Issues List” into the meeting minutes that should be created and sent out to all the stakeholders anyways is an effective and time saving technique.
Running Peer Reviews And Inspections
Before getting into the peer review discussion I would like to point out that there are actually two very distinct types of peer reviews. One can call them “proper format” review and “correct technical context” review.
The “proper format” review is typically done by an experienced project manager external to the project. Accordingly this person is usually not familiar with the detailed technical scope of the project. Actually in my experience it has been even better if that person hasn’t heard about the project in question before!
The problem is that someone who has been involved in the project extensively and has participated in many of the project discussions is less likely to be as alert and vigilant when reviewing project documentation. In addition, he or she may subconsciously be subject to the group assumptions, either conscious or unconscious, dominating the project team. A colleague of mine actually came up with a very accurate description of these phenomena; he referred to them
as “soaping of the eyes”.
For instance the technical people on the project team may think that they have a very good idea what a “seamless integration” means. An experienced peer reviewer who hasn’t been burdened by team influence will flag this phrase as inappropriate right away.
Therefore the “proper format reviewer’s” mission is not to validate the technical scope of the project or schedule and budget estimates, or to ask questions like, “What problem you were trying to solve?” His job is to make sure that the document follows the best practices of project management.
The documentation guru’s primary responsibility would be to capture deficiencies and mistakes such as ambiguous language (see Exhibit 4), missing measurability, completeness, consistency, prioritization, proper constructs, etc. (see article “Defining The Detailed Scope: How And Where Do You Find Requirements?” for an in-depth discussion of quality project documentation).
Unfortunately these kinds of reviews can not answer questions like:
- Can this scope item be delivered at all?
- Can this scope item be delivered with the budget and timeline provided?
- Are there any technical inconsistencies in the scope?
And this is where “correct technical context” reviews or inspections come in handy. The technical team members probably would focus on the correctness of technical information, unidentified risks, overlooked resource requirements, etc. in the documents rather than the way in which documentation is written.
For example, a statement like:
“Build a large four-bedroom three-bathroom Tuscan-style home on a budget of one hundred thousand dollars by the end of the next month”
will probably generate different kinds of feedback from the “guru” and from the technical project team members. The documentation guru will almost certainly notice an inappropriate use of the word “large” and will ask the project manager to associate a measurable attribute with that particular term. As a result the word “large” could be replaced with statements like “5,000 square feet” or “three-level, 6,000 square feet”.
On the other hand, technical team members may have an idea (not necessarily a correct one) of what “large” means or they may just miss it because of the lack of training in documentation reviews. However, they will probably come back to you with a comment that buildings of that size can not be built on a budget of hundred thousand dollars and be completed in month and a half.
Who are the people you should invite to peer reviews and inspections? With “proper format” reviews it is fairly straightforward – it’s the project manager and the documentation guru, most likely one of the most experienced project leaders in the company who has been properly trained in the fine art of critical reading.
The technical document inspections will require the presence of the project manager, team leads of each functional group involved in the project, all technical team members, quality assurance people, subject matter experts in each of the functional areas and several key representatives from the customer side.
Running Customer Walkthroughs
For a stakeholder walkthrough you probably want to consider inviting your clients or customer (whichever is applicable) and if possible the end users of the product. Note that each one of these groups could be in turn subdivided into several clusters; some of these clusters could be primary and some of them could be secondary but both are important.
Also, it would be a good idea to invite key representatives from the technical team since some of the questions posed by the customers and users could only be answered by them. You also need technical team reps in order to explain and justify your estimates.
If you are working on a multi-departmental project at a fairly functional organization inviting other department heads could also be valuable because they could end up providing resources for your project.
Peer Review And Walkthrough Challenges
Some of the issues encountered by the project teams during the peer reviews, walkthroughs and inspections include large requirements documents, large inspection teams and geographical separation.
So, what are the tools at your disposal in battling the “walkthrough fatigue”? First, if dealing with larger documents, attempt scheduling several reviews in stages. This way you can reduce the duration of reviews and maintain the focus of the participants. Also, try not to exceed a two hour time limit on meetings. And one final suggestion: when booking a conference room, pick the largest and the best ventilated room possible. Nothing kills the thought process like the lack of oxygen!
Sometimes the review teams can get very large, especially on key project documents like project plan or project scope definition. Having fifty or more people in the room commenting and providing critique on your documentation can turn into chaos very quickly. Therefore, it could be useful to break the inspection teams into groups for initial inspections, and once the major issues discovered in these separate meetings have been analyzed and addressed properly, the final joint technical team and customer walkthrough involving all the project stakeholders can take place.
Geographical separation can also present certain challenges. Try using tools like video conferencing, teleconferencing or tracking and comments functions in word processing software.
What Kinds Of Questions Should You Expect (And Ask)?
So what kinds of questions can one expect from the walkthroughs with the customers and the technical team members? Exhibit 2 lists some of the questions the project manager should expect when engaging in the walkthroughs, inspections and peer reviews.
What To Watch Out For: Defect Checklists
So what are the thing all of the reviewers should be on the watch out for during walkthroughs, peer reviews and inspections? When reviewing scope and other project management documents the stakeholders should be asking themselves the following questions:
Organization and completeness of the documentation:
- Are all parts of the documents written at a consistent and appropriate level of detail?
- Does the scope definition document provide an adequate basis for design?
- Do we have priorities assigned to each scope item?
- Is there any information missing in the document? Are there any “TBDs” in the
- Did we cover all possible alternatives, exceptions, risks and constraints?
- Is every requirement in scope?
- Can all the scope items be implemented with all the known constraints?
- Do all of the scope items have appropriate measurability attributes associated with them?
- Do all the key statements in the document have only one possible meaning?
- Can they be misinterpreted by any of the stakeholders?
- Exhibit 3 provides a list of potentially troublesome words and phrases that tend to frequently appear in project management documentation in basically all of the industries and types of organizations
About the Author
Jamal Moustafaev, MBA, PMP – president and founder of Thinktank Consulting is an internationally acclaimed expert and speaker in the areas of project/portfolio management, scope definition, process improvement and corporate training. Jamal Moustafaev has done work for private-sector companies and government organizations in Canada, US, Asia, Europe and Middle East. Read Jamal’s Blog @ www.thinktankconsulting.ca
Jamal is an author of two very popular books: Delivering Exceptional Project Results: A Practical Guide to Project Selection, Scoping, Estimation and Management and Project Scope Management: A Practical Guide to Requirements for Engineering, Product, Construction, IT and Enterprise Projects.