Business Analyst Checkpoints: Checkpoint Alpha

A checkpoint is a juncture in the process where information is gathered to assess the health and direction of the process. The results of this information gathering can range from outright cancellation to refunding or a complete change or direction.

There are three basic checkpoints the business analyst can facilitate to help ensure that he or she is on the right track. Two are informal, merely a get-together with other parties to review the situation and not fraught with the imprimatur of approval. The other is a more formal presentation. I’ll address each of the three checkpoints in this series.

The first checkpoint is called Checkpoint Alpha and is an informal meeting between the business analyst (or project manager in lieu of the business analyst) and the problem owner. The problem owner might be the customer or the sponsor or your primary point of contact, or all three. The problem owner is the person who needs to have the problem solved and has the authority to seek a solution. As such, the problem owned can answer the three questions that you pose during Checkpoint Alpha.

1. Is this (still) the problem you want to solve? (Confirm the problem statement.)

2. What does it look like when the problem is solved? (Obtain the vision.)

3. How will you know when you have solved the problem? Or what do you need to see to believe you have solved the problem? (Get the conditions of acceptance)

Each question is designed to elicit primary and secondary information. And each question leads naturally to the next. In other words, the questions should be asked in the order presented.

Is this (still) the problem you want to solve?

The checkpoint starts with a simple question: Is this a problem you want solved?

The “still” in parenthesis implies that it is possible to ask this question at any time during the project. It is a good question to ask when some stakeholder brings up a change or enhancement that will endanger the project’s success. And it is a good checkpoint when the solution team or the stakeholders start to drift away from the initial intent during a long project.

There can be three possible answers to this question:

1. ‘‘Yes, solve it under any circumstance.’’ (When the problem must be solved regardless of cost, such as regulatory compliance or risk to organization reputation.)

2. ‘‘No, we don’t want to solve it.’’ (The response when the problem is not what the problem owner thought it was, or things have changed since the initial problem was defined.)

3. Some form of ‘‘It depends.’’ (Which means ‘‘we want to solve it provided it makes financial sense: the benefits are greater than the costs.’’)

A ‘‘No’’ answer means that you stop at this point and save the organization the money of doing a project that does not need to be done. You can put this effort in the success column.

An ‘‘It depends’’ answer requires additional work on your part to define the cost/benefit or return on investment (ROI), or even the feasibility of solving the problem. This requires another Checkpoint Alpha once the determination has been made that the benefits of solving the problem are worth the cost.

A ‘‘Yes’’ answer, either now or after performing the financial analysis, moves us on to the next question.

What do you see when the problem is solved? What is your vision of the solution?

There is always a vision attached to any problem. When you realize you have a problem, you also know what it means for the problem to be solved. The vision does not describe how the problem is going to be solved. As Karl Wiegers says, “the vision describes what the world looks like when the problem is solved” and as such describes the results of solving the problem, or the expectations the business has for the solution.

The vision defines the result in the organization that the product is supposed to bring about and as such is described with a scenario. “I see the account representatives…”, “There are thirty percent new customers as a result of this new website and…” Reality is not a factor in the vision nor are metrics. The vision is not specifically measured against as are requirements. What the vision gives us is what is in the problem owner’s mind when talking about the solution.

The ostensible reason for the question is to establish a common target for all parties: business stakeholders, the solution team and management. There is an underlying reason for the vision statement: expectations. A question I get over and over is “How do we manage customer expectations?” That is usually a euphemism for “the customer just surprised us with new requirements; how do we say no?”

You cannot manage what you do not know. By asking for problem and vision you are exposing expectations that you can then manage. I’ll talk of managing expectations in a later posting. The point here is that with a little analysis you can discern many of the underlying expectations the problem owner and business stakeholders have of the product right from the start or at least from the point that Checkpoint Alpha is conducted.

How will you know we have solved your problem?

Once you have the vision, we need something a little more specific than the generic vision. We need to know what the problem owner will be specifically looking for when we say that the job is done and the problem solved. What we are looking for is he acceptance criteria. We don’t want to ask directly because the problem owner will not generally be able to speak in terms of “acceptance criteria”. He will be able to describe what needs to be done to prove that the problem is solved. Thus the question: how will you know that we have solved your problem?

The real question is “What do you need to see to believe that we have solved your problem?” Not only does the answer confirm the vision, it specifies the acceptance tests that need to be set up to provide the proof of solution and exposes even more expectations. As an added bonus, the statement of what the problem owner needs to see sets up an agreement, if not a contract: ‘‘You do these things, and I’ll will sign off that the problem has been solved.’’

A cautionary note when asking for what amount to be the acceptance criteria: the problem owner may be reluctant to state the specific evidence needed to believe the problem is solved. The problem owner may be unwilling to detail the criteria for fear that you will only deliver the bare minimum to provide satisfaction. The problem owner may even say they don’t know. The truth is that we will always know what it takes to prove to us a problem is solved. The problem is our old car is not working well and costs too much in monthly maintenance. We know the problem is solved when we have a new car that works fine without monthly maintenance costs. So be persistent and apply your excellent business analyst communication skills to elicit the answer to the question.

The three simple questions of Checkpoint Alpha provide a wealth of information for the business analyst and the solution team: the confirmed problem statement stating where we are now; the vision stating where we want to be; and the acceptance criteria which will be used to measure the success of the product. And perhaps even more importantly the underlying expectations of the product that sometimes do not reveal themselves until just before delivery. This is a good return for a fifteen to thirty minute investment of time.

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.