3.4 Steering Projects Toward Success: Reviews

The following are a few methods you could use to review and verify the analyst’s work:

1. Help Arrange for and Participate in Internal Review Activities

By now, the analyst has progressed in their work, and is likely to have a work product that looks promising to deliver to the client for feedback. Before that happens, you need to ensure the deliverable is in a good shape in terms of content and form. A few rounds of quality checks should be run before submitting the deliverable to the client.

To run the review process, consider the following:

• As usual, ask for samples early on. The review phase should not be the first time you see the work product. Otherwise, you might be setting yourself up for unpleasant surprises, in which case, you can’t blame the analyst for doing it their way or expect them to make drastic changes unless things are totally off. If that happens, you might have to share the responsibility and help them in making the changes. It is only fair to share the responsibility, if you had not given them guidance early on.
• Start with a first round of peer review. Have another analyst review the deliverable to catch any obvious issues. Reviewing each other’s work should be a habit in the team, and should be counted for in their time. If the analysts are divided in grades, have the more senior ones do the review.
• Everyone who reviews the deliverable should ideally use checklists to ensure requirements are of good quality. The checklists should cover both the document quality (things like formatting, sections organization, etc), and requirements quality (Are all checks covered? Is their ambiguity anywhere? Are all inputs and outputs clear? etc).
• Once this first level of review is done, and corrections are incorporated, it is time to involve other team members. Use techniques like requirements inspections, walkthroughs, and perspective-based readings to solicit feedback from the team members. The project manager, developer, tester, technical writer are all good candidates to help, and critique the document from their relevant perspective.
• Make sure the defects from the reviews are documented and that the deliverable is corrected.
• Expect that there will be discussions and some conflict of opinions until a consensus on requirements completeness and quality is reached.

2. Monitor Defects Rate for Signs of Problems

Another key point here is to keep an eye on the kind of defects that come out of these reviews. Is there a pattern of issues or signs of problems in the way requirements are handled? For example, if the project manager raises issues of scope late in the project when the requirements are being detailed. It may mean that there is a glitch of communication between the BA and the PM, and not enough information is flowing between the two sides. It could also mean that the analyst does not have enough information to decide if they are working outside the agreed scope of work, or that they do not know when the requirements have slipped off their initial boundaries.

Keep the following in mind:

• High defect rates may be due to system complexity, unfamiliarity with the project, or poor requirements practices.
• Do not use the number of defects as the only measure. Assess the defects quality and categories, particularly the ones related to requirements completeness and accuracy.
• Compare to defect rates of similar projects from history to benchmark the analyst performance. Defect patterns can be related to project type, client style, or specific analysts.

3. Seek consensus on requirements completeness and quality

Make sure the stakeholders in the project agree when a set of requirements is complete and ready for implementation.

Look for the Future

• Is there anything that you and the team can do to avoid some of the issues that appeared in the deliverable in the project?
• Do checklists or processes need to be updated?

Considerations:

• When they offer solutions, do not feel the urge to find something wrong with what they have come up with. If their proposed solution is acceptable, accept it. Accepting what is there IS in itself a good contribution. It is called validation and confirmation.
• If, on the other hand, you find that there is a better way to do something, discuss with them what could be a possible drawback in their proposed solution. If they cannot see the drawback, point it out as an enhancement that you feel the proposed solution can benefit from.
• If the proposed solution appears to be off-track, do not shy away from pointing out the problem and proposing a good solution instead. It is also OK to say that something cannot work. For example, if the solution is not feasible within the limited available resources or is inconsistent with the organization policies, or any other reason.
• Know that it is sometimes difficult to distinguish between what is really a correction and what is a personal style. Do what you can to remain objective, and forgive yourself if you don’t get it right sometimes. You are a human being after all, and you are allowed some space for mistakes, just like they are.
• Do not keep the monitoring level consistent forever. The more you work with the analyst, the more they should be able to understand the logic behind your approach and learn from their mistakes, and be more independent.
• Educate them, and allow space for errors. Analysts are not perfect nor are you.