Business Analyst Checkpoints: Checkpoint Beta

In the last discussion we talked about Checkpoint Alpha, an informal meeting between the business analyst and the problem owner or customer that establishes goals for the product, gets expectations out in the open and defines the criteria for product acceptance. Checkpoint Alpha is informal, because there is no agenda needed and there are no signatures marking the outcome, but it is a mandatory session for the business analyst’s success.

Checkpoint Beta is not mandatory. It is, however, extremely helpful for the business analyst. Checkpoint Beta is also an informal meeting, this time with the solution team. It is held prior to committing the solution to the final, formal solution document andobtaining final confirmation from the business community.

Checkpoint Beta is not mandatory because there might not be a team assigned to the solution. Some organizations assign the solution team after the requirements have been approved and perhaps even later. And, if you are working in a more collaborative manner, such as in an agile development approach, there is no need for a meeting since you will be getting consistent feedback.

The idea behind checkpoint Beta is to obtain some technical input as soon as you have a reasonable expectation of what the business solution might be, for technical feasibility if for nothing else. Sometimes what the business wants is based on what they have seen on the Internet, or at home, or even on an episode of Star Trek, and implementing the solution in that way may not be technologically feasible or advisable given the organization's technical environment and available resources.

If there is a project team assigned, check with the assigned team for technical feasibility, and also with the project manager to see if the solution is feasible within the project constraints of time and resources. Do this before getting final sign-off from the customer on the requirements and/or proposed solution.

Consulting with the assigned team is preferable, but even if you don’t have an assigned team, it still is a good idea to seek out someone in the technical area - a database administrator, a solutions architect, a systems analyst, or even a programmer - to ensure there is a valid, feasible technical approach to implement your proposed business solution.

You want Checkpoint Beta to be attendedby the project manager, systems analyst, database administrator, andanyone else who is involved in solution implementation. Select a time tohave the meeting where you know that the likelihood of significant changeto the business solution is small and the solution is relatively stable, at least for the time being. Keep the meeting informal and at a discussion level; there is no approval being sought, only advice and counsel. Thismeeting has three purposes:

1. Provide a heads-up for the solution team before the final approval isgiven.

2. Identify any feasibility issues that may be embedded in the solution.Technical feasibility is the primary concern.

3. Confirm with the project team and project manager that the solution willfit within the project constraints; since often the project deadline and budgethave already been defined.

There is another benefit of Checkpoint Beta. If you have not been working closely with the solution team which can happen when you are wandering around the business community gathering information away from the team, the Checkpoint Beta meeting gives you a chance to introduce your requirements style and approach to the team and, based on their reactions and contributions during the meeting, to learn a lot about the people who are going to implement your requirements.

This does not constitute a formal review; signatures are not necessary, nor will action necessarily be taken as a direct result.Also, it is not necessary to formally hand out the document to the solutionteam since it has not officially been approved. Do not bother with a Power-Point presentation. Keep it simple. Don’t go over the requirements in detail, but rather explain the approach you are taking and address any technical questions you have. This is an informal checkpoint in the process tomake sure you have not missed something or made an incorrect technical assumptionabout the proposed solution.

It is better to check first rather than to get the business solution signed off and then have to come back tail between legs and tell the customer that the solution they approved won't work.

Author: Steve Blais, PMP, has over 43 years’ experience in business analysis, project management, and software development and is the author of Business Analysis: Best Practices for Success from John Wiley publishers. He provides consulting services to companies developing or improving business analysis processes. He is on the committee for the IIBA’s BABOK Guide 3.0. Steve can be reached at [email protected]. His website is www.essenceoftheba.com.