Checkpoints Alpha and Beta prompt business analysts to verify where they are in the process and get feedback from first the problem owner or business sponsor (checkpoint alpha) and then the solution team (checkpoint beta). The checkpoints help increase understanding, communication and collaboration. The checkpoints are optional in that if you have the information and are collaborating successfully these checkpoints will simply be additional meetings without much additional value.
However, Checkpoint Charlie is another story. Whether linear or agile development approaches are being used, we need to have a specific required point in time where the solution being implemented is checked against the original problem before it gets too far downstream.
A business analyst manager had this to say: ‘‘there is significant communication up and down the chain in which the business analysts are not involved. It seems like this with every project. We prepare a business requirements document reflecting what the users want and then the developers do their own thing, disregarding our document. And they don’t tell us. They are all discussing it but once they get the document, we’re out of the picture. And the business expects us to deliver what they saw and approved in our document.’’
Here is an example of what that business analyst manager is talking about.
A few years ago I was developing a business analyst process for a consulting firm maintaining a system for the US Department of Defense. The contract called for quarterly releases. The process in place had the business analysts defining the changes and modifications that the users requested, passing the approved changed requirements on to the development team which built the software for release. In this particular case, there were a number of changes due to some new regulations and policies. The business analysts worked with the users to specify new user interfaces to accommodate the new functionality. The changes were approved and passed on to the development team. The development team some of whom were on the team that originally built the software being used decided that the interface was not efficient and didn’t match the standard they had created so they changed the interface, some of the flow and some of the functionality. When the release went to final acceptance test with the users, the users were outraged that they were not looking at the user interfaces that they had signed off on. And the business analysts were caught blind-sided in that they were not apprised of the changes. The developers had been right in that the user interface and functionality appeared to be better, but the users were unpleasantly surprised and the went up the ranks and back down again requiring a special release a month later with reparations made. Most likely had there been some point at which the developers let the business analysts know about the changes the developers were making, and the business analysts brought those changes to the users, the changes would have been accepted and all would have been well.
Their process now has a formal mandatory meeting held when the design is complete: the third of the three checkpoints, Checkpoint Charlie. The goal of the checkpoint Charlie meeting is to make sure the business analyst understands the implementation approach being taken and agrees that the approach solves the business problem. The meeting is also for the business analyst to capture the changed or new requirements that have resulted from the detailed technical review of the solution document while the analyst was not in contact with the development team.
This is a good way to make sure nothing slips through the cracks.
The technical lead on the solution team presents the technical design to explain how the design solves the problem. In attendance are all parties with input to or requiring information from the technical design, including other technical team members, business analysts working on related projects or work requests, and any other member of the project team. Management is not typically included in the checkpoint Charlie meeting. The business analyst corrects all requirements in the solution document with the valid changes identified by the solution team. Should a change make a significant difference to the solution, the business analyst presents the changes to the business for approval.
In agile development methods a formal Checkpoint Charlie at the end of a design phase is not necessary. The developers and product owner have a review session at the end of each sprint or iteration which is a good substitute for Checkpoint Charlie. Even so, the product backlog has tobe groomed and reprioritized and some description of what is going to be delivered has to be maintained for such incidentals as user manuals, helpdesk guides, and online help information. Many of the agile review sessions I have witnessed do not include anyone updating the description of the final delivery or release to match the actual product.
So whether agile or linear, formal requirements document or stack of user story cards, once the business (or its representative) agrees to a proposed solution, they don’t like to be surprised with changes that vary from their expectations. The business analysts know the business’ expectations and, if the business analysts know the changes that are going to be made, they can manage those expectations. As someone once said, people are not resistant to change; they are resistant to being changed.
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.
Article image © puckillustrations - Fotolia.com