• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Peer Reviews for Business Analysts

We perform peer reviews on our projects to ensure better deliverable quality. They also provide a very nice mentoring tool to help each other grow. In general though, as business analysts, even if it’s not a required part of your process, you should periodically have someone take a look at your work as an opportunity to see if you could be doing anything better.

Before I talk about how we do them, when asked to do one, remember peer reviews are not used as a tool to get back at someone you are ticked at (which is so unlikely because we know business analysts are the friendliest of friendly people!). And on the other side, they are not something for which to get extremely defensive about but rather a tool to listen and take the feedback about your work.

Peer reviews should consider two types of reviews: form and content, the most important being content. Peer reviewing deliverable’s form is looking for things like whether a template is used and used correctly and whether correct grammar is used. Reviewing content is looking for any gaps in the deliverable such as missing requirements and whether the content that is there makes sense.

It’s useful if peer reviews can be done by someone who is on the project with context to get more in depth review. But it’s also very useful to have someone review your work who is not familiar with the project to validate that obvious things are not overlooked by those in the weeds every day. Most projects cannot afford to have both done all the time, so consider alternating between types of reviewers.

Logistically plan for your peer reviews:

  1. Plan ahead!
  2. Ask someone to do the review
  3. Give them adequate time and a deadline
  4. Keep it time-boxed from 1-2 hours so they find it easy to jump in and do
  5. Get them your deliverable in a timely fashion

We use mini checklists to guide our peer reviews, with about 2-5 reminders of things to review for. There are mini checklists for each type of deliverable we produce. For example, we produce system context diagrams, so we have a mini checklist for those that includes:

  1. Is the template used correctly
  2. Does the diagram seem correct (any incorrect links)
  3. Are there any missing systems or types of systems that you would expect to see

You can do your peer reviews in other ways too, for example, you could use no checklists and have people use their good judgment about what to look for. Or you could give them a long checklist to look at, just know it’ll take more time to complete. You can make them required or you can have people seek them out whenever they desire. But as a business analyst, whether you have a formal process or not, I strongly encourage you to find someone to review your stuff – and offer to peer review theirs in exchange.

No comments yet.

Leave a Reply

Your email address will not be published. Required fields are marked *