'Alligator' peer reviews drain project swamp and reveal hidden threats

Afraid of being bitten by a project problem lurking just beneath the surface? Consider these tips on how to conduct an 'alligator' peer review, a unique twist on the common practice of asking a peer to go over your project.

The nimble project manager can usually get an accurate reading on what’s happening with a project by practicing “management by walking around” and fostering an effective bidirectional team communications plan. But these methods aren’t foolproof. Sometimes, a project manager can simply be too close to the action; too involved in the day-to-day detail, to actually see the forest for the trees.

Authors Andrew P. Snow and Mark Keil, in “The Challenge of Accurate Software Project Status Reporting: A Two Stage Model Incorporating Status Errors and Reporting Bias,” refer to this situation as errors in “perceived status”. On particularly difficult projects, a PM may find it easier to ignore a lurking problem than to confront a perceived no-win situation. That strategy is similar to one used by Sgt. Hans Schultz in the 60s TV series "Hogan’s Heroes". Schultz, when pressed for information, often responded with the phrase: “I see nothing, I hear nothing, I know nothing.” Another misperception may result if a PM misreads the status of a project where a risk-trigger event has happened, but the impact of the problem hasn’t yet surfaced.

For the nimble project manager, there are a number of tools available to deal with the problem of misperceived status. On smaller projects, or in a low-ceremony culture, the best tool is what I call an “alligator” peer review for project managers. This type of review is also helpful in high-ceremony cultures, and on longer projects, if the alligator review is followed by a more formal project audit or project health check.

The alligator review was the result of a phone call from a coworker based in Florida with the large consulting firm we both worked for. He asked if I could come out for a week to see if he was missing anything on his project. He described the problem by saying that he was in a pitched battle with the alligators he knew about, but was getting worried that there were one or two lurking somewhere deep in the swamp, and they’d be the ones that finally “got” him. I jokingly told him I’d be happy to come out and count “gators” and, if I had time, I’d even tag them and name them for him.

A week later, I realized that my teasing response turned out to be the secret of a successful alligator review. Count the risks, problems and issues, then tag them and name them for easy identification and resolution. From the project management perspective, looking for unidentified risks in another PM’s project is the equivalent of looking for problems in another developer’s code.

Setting up an alligator review
The nimble project manager enlists the help of a fellow project manager to conduct the alligator review. This individual should be someone you respect and trust and a person who can be objective and will give, when required, brutally honest feedback. Over the length of a six-month project, the reviewer will need to commit a total of about one to two days assisting with the project review.

Conducting the reviews
For the project manager
For projects of six months or less:
This review focuses on confirming that the initial risks have all been identified and that mitigation or contingency plans are in place for these risks.
  • Schedule the review near the end of the requirements phase. Send the draft requirements document, the scope document, and the risk plan to the chosen reviewer.
  • Arrange a brief meeting with the team to introduce the reviewer, and ask them to help by making themselves available to answer questions during the day. The PM should clearly articulate that the focus of the review is on smoking out any undetected risks. The PM should reiterate that the review isn’t intended as an audit or a performance review so honest answers are acceptable and desirable.

For projects of more than six months:
An additional review, somewhere at about the midpoint of the development phase, provides the opportunity to once again identify risks. Every project manager knows that the specific risks on a project tend to change over time but it’s easy to lose sight of that in the middle of a fast-paced project. The midpoint review will follow the same general process with two additions:
  • If technology looks like a hidden risk factor, consider adding a technical reviewer in addition to the project management peer.
  • Make sure that all scope changes are available for review. If these scope changes haven’t been formally documented, even a simple after-the-fact list will be useful to the reviewer.

For the reviewer
  • The PM schedules a meeting for the reviewer with the senior project team to discuss the team’s perception of what’s happening on the project. The goal of these interviews is to allow the reviewer to independently evaluate comments from a wide range of people. The reviewer should ask about small worries or niggling doubts since these are often the early warning signs of problems about to happen. Additionally, the reviewer should be prepared to hear about big worries that the team thinks are being ignored.
  • The PM schedules a similar meeting between the reviewer and one or two members of the user community to discuss their perception of the project. These meetings are crucial for a review done at the end of the requirements phase. During the development phase review, they’re still desirable but not quite as critical.
  • The reviewer should prepare an e-mail outlining any additional risks or differences in recommended strategies and, if possible, arrange an in-person meeting to discuss her findings with the PM.

Possible problems with an alligator review
What happens when the review produces findings that the project manager disagrees with but that the reviewer insists must be acted upon now? Even though the results of an alligator review aren’t shared publicly, I personally believe that this is a point where the PM needs to consider the possibility that the results might be incorrect. The suggested solution to this issue is for the PM to change the project status to yellow. This creates an environment where the nimble project manager can ensure that he haven’t fallen victim to the “Sgt. Schultz syndrome”. Once the project is yellow, the nimble project manager can investigate the problem in more depth or ask for a more formal audit. 

It’s incumbent on both the PM and the reviewer to be sensitive to the political realities on a project. Sometimes risks are political hot potatoes and a reviewer should always respect the fact that a nimble PM might choose a path other than immediate escalation to avoid falling victim to a “shoot the messenger” mentality. In the case of my first alligator review, the PM chose not to do anything about my findings (the interfaces between two major code modules were so poorly written they could never work) and waited about four months to formally escalate and solve the problem. By then, he had accustomed management to accept a situation that they would have resisted four months prior.

Creating the right culture for alligator reviews
For an alligator or peer review to work well, there needs to be a strong culture of respect for one’s peers. In some companies, this simply happens naturally while in others it takes a little more work. In my next column, I’ll talk about how to build a community of practice and foster the environment where alligator reviews can flourish.

General rules for peer review
This type of review is strictly between the reviewer and the project manager. No report is ever given to the PMO (if there is one), to the client, or to the end user. If a documented review is required it should be done under the auspices of what has been called a health check or a project audit.

The reviewer should conduct the meeting using the skills of active listening. Active listening skills include the following:
  • Attending to and acknowledging the other person through eye contact and other nonverbal cues
  • Restating and paraphrasing to establish congruence of thought
  • Reflecting or mirroring to establish understanding of the emotional tone of a topic or issue from the perspective of the other person
  • Asking probing questions in a supportive manner that elicits more information or that attempts to clear up confusion
  • Summarizing and synthesizing what’s been heard in an accurate and insightful manner


Editor's Picks