Analysts are often asked to stay away from “solutioning”. Sadly, that is often understood as staying away from the solution. An instructive story happened to me earlier in my business analysis career. We had just completed a very intense requirements analysis phase that took several months. Between fifteen and twenty stakeholders were involved in a marathon of many all-day analysis workshops, with a hundred-page requirements document for user interface alone, several hundred requirements captured in a spreadsheet, many diagrams and decision tables and more… In other words, a new complex system was being built.
Once the final signature dried off on the requirements document, the dedicated design and development team took over. They were all seasoned and expensive consultants contracted for the sole purpose of delivering this system. Much to my surprise, I, the business analyst who had worked on requirements, was instructed not to communicate with the development team in any way. As the company was paying consultants a lot of money to get the job done, they were to receive their instructions from and report to a single person, so that they don’t receive conflicting information.
As I had other assignments, I was only left to wonder what was happening to the development of the system we all visualized and conceived in dozens and dozens of heated and animated meetings.
The consultants kept it to themselves and were rarely seen in the office. They have provided their timelines and were working towards them in their own world.
Can you guess what happened next? When the designated contact person went on vacation, one of the consultants approached me with a question. He acknowledged that there was a whole section of requirements that they had completely ignored to that point as they were not sure what was needed… From then on, things unravelled – the development was way behind, certain components were not addressed and gaps in understanding were significant. In the end, the project took another year to complete, this time with active business analyst participation.
The experience of the vast majority of software development projects is that many things can and will go wrong during design and development:
Misunderstanding or misinterpretation can take the solution in a different direction.
Gaps may and will be discovered.
Human beings will decide what to do with the gaps, how to interpret ambiguities and how to get missing information that was not apparent during analysis.
Delivery teams will have personnel rotation which may lead to a different interpretation of the same requirements.
Non-technology components of the solution can get missed.
I can continue with the examples, but the point should be clear: business analysis is not “done” when business requirements are signed off.
Throughout the lifecycle of a solution, the business analyst continues to play a role to ensure that the solution, once implemented, will indeed satisfy business needs and resolve business problems that it was expected to resolve. For the duration of the project, the analyst remains the spokesperson for the business requirements.
After the bulk of the initial analysis work is completed, there are several other important objectives and reasons for the analyst to stay actively involved in the project:
1. Recognize, analyze and manage new requirements.
The analyst is usually the first to discover, assess and communicate the impacts of business change. Often these changes result in new requirements or requirements changes. Regardless of how each project or organization deals with the changes during active projects, the task of assessing and addressing requirements changes is an important role that the business analyst fulfills.
2. Ensure the solution, as developed, aligns with business requirements
As technology stakeholders review the requirements and design a solution, the business analyst’s close involvement helps ensure that the requirements are understood and interpreted correctly. You would be surprised how something that you thought was crystal clear could be interpreted differently by technical people looking at the same thing from their perspective.
The business analyst’s contribution is important to the design, provides additional background, and addresses any requirements gaps discovered during that stage. At the same time, participation in the design effort is a fantastic learning opportunity for a business analyst – don’t decline a chance to observe and participate in the design activities.
3. Oversee the design of non-technology components of the solution
While solution architects and software development teams are accountable for the technology components, a business analyst must ensure a complete solution to a business problem that addresses all requirements layers:
The non-technology components of the solution such as changes to processes, artifacts, organizational structure and even to the movement of physical objects and real estate, play a significant role in the successful implementation of the business change. Often referred to as “change management tasks”, “transition plan” or “implementation components”, these solution components are necessary for the implementation of a viable solution.
Non-technology components include:
- Business process changes required to adopt and incorporate the solution or change
- Communicating and promoting the new technology solution, focusing on user adoption
- User training and documentation, including creating new and updating existing user manuals, job aids and training materials
- Planning for sufficient production support, including training support teams and agreeing on the support process
- Changes to marketing materials, communication targeted at external clients and customers
- Internal communication materials to explain and broadcast changes to employees
A project manager may be the one tracking these implementation tasks, but a business analyst is the most suitable person for ensuring their quality, owing to their insight into the business problem.
4. Capture and transfer the knowledge
During the project, a business analyst often has the most complete picture of what the project is trying to achieve and why, on a quite detailed level. This priceless knowledge must be captured and shared with others to ensure the solution is understood, adopted and supported by other stakeholders. A business analyst can contribute to:
- Transfer the knowledge of requirements and the solution to the training, operational support and business stakeholders
- Ensure continuity of the baseline requirements documentation
- Update the organizational knowledge base to reflect the changes introduced by the project
- Train and mentor other business analysts
- Monitor questions, issues and problems once the solution is operational – assess the quality of requirements, capture gaps and lessons learned to address in the next iterations of the solution lifecycle
Stay engaged throughout the whole solution lifecycle. Real requirements validation will continue after the requirements are signed off, and the real measure of success of your work comes from the stakeholder satisfaction with the implemented solution.
Want to succeed in business analysis? Apply the twelve principles of the business analyst mindset. Sign up for the Why Change newsletter for more resources and to receive your free copy of the BA mindset poster.
Explore the #ba_mindset in other formats: books, videos, or courses. Or contact Yulia for individual coaching, speaking, or helping your organization mature its business analysis function.
3 comments