Bad Ass BA; Peer Review. Part 1.

Co-authored by Rebecca Burgess

Rubber Stamp or an Objective Quality Check?

When I ask for a “peer review” of a requirements document, I’m expecting a quality assurance check before the requirements document is presented to the Stakeholders. Some people think, “Oh, you’re my friend. I could never criticize your work.” But if you just rubber stamp (approve without a critical review) my work, you aren’t really my friend at all. If my friend/peer/co-worker/fellow BA doesn’t “take out a red pen” (or turn on track changes) and come back with lots of comments and questions, I worry. You would tell your friend that she had spinach on her teeth before letting her go back to the office after lunch, wouldn’t you? By the same reasoning, wouldn’t you do a careful review of her requirements document before it goes to the customer for review and approval?

There are a number of levels at which a document should be reviewed. In general, they are:

• Business Case Synchronicity Check
• Requirements Document Sanity Check
• Requirements Statements Content Check
• Requirements Document Housekeeping Check

These checks are filters; that is, if the document doesn’t pass the Business Case Synchronicity Check, you will stop the review. Only if the document and the business case are in sync, will you check for sanity, then if both of those checks pass, review the content quality of the requirements statements. Finally, do a housekeeping check on the version of the document that is ready to go to the Customer.

By checking the requirements document at each of these levels, you will be doing your peer a favor, and help her/him produce the highest quality document possible. We will detail the purpose and method for each check in articles over the next three months.

Why Peer Review?

Why bother with peer reviews in the first place? Here are a few concise reasons to use this powerful tool:

Improve the quality of the document being reviewed – More eyes are better.

Identify and correct project problems, errors, and omissions as early in the project cycle as possible – Early fixes are cheaper, by orders of magnitude.

Learn from colleagues’ insights and errors – If they can’t be a good example, they can be a horrible warning.

Broaden your knowledge of other areas of the business – The more you know about the business, the easier it is to move up to that “enterprise analyst” position.

Ask the stupid questions – see Bad-Ass BA Lessons. Part 2.

What excuses do people use to avoid peer review and how can you counter those excuses? There are many excuses, but these are the most common:

It’s scary! They won’t say this out loud, but it’s true. You must separate your self esteem from the evaluation of your work by learning to accept criticism as constructive and valued, rather than destructive and to be avoided at all cost.

It takes time! Yes, but the payback is substantial, both in minimizing the impact of errors, and in maturing the BAs on the team.

We are already behind schedule! Would you rather let the customer catch the errors? Or worse yet, miss the errors?

I don’t know anything about that project! So you’ll limit your review to the more general, BA-level comments; that’s still valuable. Also see “Broaden your knowledge” in the reasons to do peer reviews, above.

It’s hard to do! True. And these articles will make it easier, so read on….

Business Case Synchronicity Check

The requirements document needs to sync up with the business case. Really, it does. We need to check benefits, ROI claims, reporting on ROI, success criteria, and the means to validate success.

Incidentally, for this article, the business case is assumed to contain a statement of the problem that needs to be solved, who the problem impacts, and the benefits, goals, and success criteria expected to be achieved, both financial and non-financial. For more information about business cases, see Building the Business Case and/or the Enterprise Analysis section of the BA BOK.

Check the box next to the item if you can answer ‘yes’ for the document you are reviewing.

Part 1. Business Case Synchronicity

Is the business case document referenced in the requirements document? Can you access the business case document from the reference (or could the business case be a figment of someone’s imagination)?

Is a stakeholder list available? Do the individuals listed in the approvals section of the requirements document cover all the stakeholders?

Are the project benefits also benefits to the business? If the business sees no benefit, why is the project being undertaken?

Are the goals and/or success criteria from the business case represented by requirements (and can the requirements be traced back to the business case information)? For each benefit/goal/success criteria, has a method for measuring the achievement of that benefit been described in the associated requirement, and does that measurement method make sense? Are there clear requirements to provide any new data needed to measure the success of this project? If the metric for the benefit/goal/success criteria is already implemented, has that benefit been baselined (measured in the recent past) and is the baseline data referenced in the appropriate requirement(s)? Is there a target value and/or range for the benefit metric?

Is there a description of how and when the users expect to demonstrate achievement of the financial benefits resulting from the solution (after delivery of the project)? Are the ROI claims (expected return on investment over a period of time) supported by requirements that describe how the business will periodically report on their progress towards achieving the ROI?

Based on the business case, do you believe that all of the critical business needs are represented by the body of requirements?

If one or more of these items is not checked, there is some risk that the requirements document does not match the business case. Your peer review mission is to convey these errors and omissions in a constructive manner. If you are expected to return written feedback, take time to explain what is wrong or missing, and provide examples if possible. If you will be participating in a peer review meeting, make notes of what you want to say so that you don’t sound too negative.

Have you convinced yourself that the requirements document and business case are in sync? No? Then the review of the requirements document should stop right now. The business case needs to be updated and everybody needs to agree that the business case is still valid. Once the documents are in sync, you can proceed to the sanity check, which will be covered in Part 2.

This article is part 1 of a 4-part series. The four sections are:

• Business Case Synchronicity
• Requirements Document Sanity (October, 2009)
• Requirements Statements Content Check (November, 2009)
• Requirements Document Housekeeping Check (December, 2009)

Don’t forget to leave your comments below

---

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion motorcycle riding at balsamfir.com. She can be reached at [email protected].

Rebecca Burgess is the Business Process Methodology Analyst in the Commerce Lifecycle Transformation Office at Symantec and a Certified Six Sigma Black Belt. After many years of uncovering problems and determining root causes in software, she is now applying her BA skills to strategic process design and improvement. She can be reached at [email protected].