This is the second of a two-part look at a “Day in the Life” of a Business Analyst (BA). During the first half of our “day”, the BA met with principal stakeholders multiple times to understand the problem, document the As Is and To Be, and perform a gap analysis between the two that will form the basis for the solution. The BA speculates that this will involve a combination of changes to people, process, and tools but the next step is to list and prioritize what the solution must include.
12:00 noon – 1:00 p.m.: Requirements Documentation.
This is a comprehensive list of what is needed to solve a business problem. It can include changes in organization, process, or tools, or any combination of the three. If new technology is involved, the solution requirements will dig down into the details of technical requirements such as how fast the system will respond, how many users it must support, etc., so bringing a technology expert onto the team at this point is a good idea. Use Cases or User Stories will be written, depending on how the project is being managed, i.e., if the Project Manager is using a waterfall model, Use Cases are typical, whereas in Agile methodologies, User Stories are more common. Process models, both the As-Is and the To-Be, should be included, along with the results of the gap analysis. All requirements are numbered, grouped, and prioritized. This requires feedback from the team and the sponsor. Remember that your requirements will need to be tracked and traced until after the implementation of the change. Be mindful of organizing them so that you can verify that they are being met throughout the development, especially if new technology will be rolled out. In addition, you will need to establish metrics for the primary functional requirements so that you can continually measure the success of the change once it is implemented.
1:00 – 2:00 p.m.: Change Preparation.
The BA has been working with the Business Architect or – even better – the Change Manager to prepare the organization for this change. Together, they’ve made sure that the core stakeholders understand what is changing, the benefits of the change(s), and how the planned changes will address current pain points. They’ve listened to concerns expressed by those who seem resistant, and addressed or acknowledged them. The sponsor agreed to the communication strategy and, where broad communications are required, the corporate communications manager.Methods to notify and involve the larger organization will depend on the scope of the change and who will feel the change. Communications might include staff meetings that cascade through all management levels; emails; intranet announcements; collaboration software; open Q&A sessions; and/or structured training sessions. If external customers are affected, the marketing organization will be involved. The BA will establish a feedback mechanism for each of these channels, to get a pulse from the organization on how the change is being viewed.
2:00 – 3:00 p.m.: Implementation Preparation.
By now the sponsor and leadership have agreed on a governance model for the change and now’s the time for that team to review the project and give a go/no-go decision. The Project Manager and BA will present outstanding technical, organizational, or process issues that haven’t yet been resolved, and any risks remaining. There will be recommendations and plans to either mitigate or accept them. If new software was necessary, it’s been configured and tested to ensure requirements were understood and met, and UAT has taken place. The To-Be process is about to become the As-Is, so a final check is done to ensure that everyone has been trained on it end to end. Any organizational changes that were needed have been implemented and the people understand their roles, responsibilities, and relationships with their teams.Post-implementation support has been established and communicated, addressing who will respond to issues once the project team disbands, as well as who has ongoing ownership and governance for the new process. If the change is large or dramatic, consider a short-term command center where people can get immediate help for unplanned issues that arise.
3:00 – 4:00 p.m.: Launch.
Take a very deep breath, let it out slowly, and – well – unleash the hounds. For the next hour (day/week/month), deal with Murphy’s Law in all its glory. Since the change was so well planned and orchestrated, this should be a piece of cake – but it won’t be, because it never is. So keep taking those cleansing breaths and realize that, had your planning been less rigorous, it could have been worse.
4:00 – 5:00 p.m.: Measure and Report.
Gather initial metrics on how things are going. How many trouble calls did the support center get in the first weeks/months of the change? What is the pulse of the stakeholders, and what needs to be done to increase their comfort level? (How do you know? Hint: Survey Says…). What are the objective decreases in elapsed time, cycle time, or errors within the process, and what productivity increases can be reported? Gather all of these into a standard report and present it to the leadership. Hand off ongoing reporting to whoever has ownership of the process, so the improvements can be tracked over time, and anomalies can be spotted if something goes awry.
5:00 – 6:00 p.m.: Celebrate Success.
Gather the core team and the implementation participants for a celebration – you did it!
As should be clear, a Business Analyst needs to know a lot more than how to write good requirements.They need a solid understanding of process, change, business architecture, customer satisfaction, facilitation, governance, ongoing daily operations, technology, and soft skills. I wonder if there’s a single place someone could get all that training? Maybe that’s a conversation for another time -right now our BA is ready to call it a day!
