A month in the life of a Business Analyst

A month in the life of a Business Analyst

Case Study Overview.

Company 123 is migrating from a legacy ticketing system to ServiceNow enterprise (an off the shelf solution). Tayo is a Business Analyst who has been working on this project for some time now. His responsibility is to ensure that ServiceNow is able to cater for all functions which is currently being provided by the existing legacy system.

Tayo has done quite a lot of requirements gathering and process map however a stakeholder has raised one critical concern. The legacy system has a digital sticky note function which allows user groups to write down non confidential information about routines and activities for other users to see. The approved configuration of ServiceNow does not have this capability. The stakeholder has specified this requirement as a ''Must Have''

The Task - Week 1

Tayo is has been assigned as the Business Analyst to look into this problem and find a resolution to it. Tayo was trained by us, so he immediately understood the nature of his task. He immediately emails the stakeholder who raised this concern and scheduled an appointment in 2 days. During the meeting with the stakeholder, Tayo used a scenario-based approach to elicit requirements from this stakeholder. It turns out to be the case that this stakeholder could only provide requirements based on how her team uses the digital sticky note capability. Other teams also use the same function differently; however, all teams collaborate using it. This initially sounded a bit confusing to Tayo but he asked if the stakeholder could mention the other stakeholders who are involved in the use of the function.

Tayo went ahead to briefly speak with those stakeholders but most importantly he was able to agree a date for a workshop the following week.

Week 2

On the day of the workshop, Tayo took the ServiceNow administrator (Jimmy) with him whilst he chaired the workshop. He started by reciting his understanding of the problem based on what he has gathered previously from meeting with the stakeholders individually. The stakeholders were then able to elaborate further. Tayo asked the serviceNow administrator to define the art of the possible. In response, Jimmy presented a few options that can resolve some of the gaps but unfortunately, due to the personalized nature of the digital sticky note function, ServiceNow was unable to cater of all their needs.

Tayo thanked Jimmy and turned to the stakeholders asking how they feel about the areas which can now be covered by ServiceNow and whether they saw a way around the few remaining usecases that can't be covered by ServiceNow.

One of the stakeholders suggested maintaining a local excel sheet, another stakeholder described how they face faced a similar problem in his previous place of work and ended up creating a ''Teams'' channel to resolve that issue. Tayo allowed the stakeholders to drive the conversation which went on for a while. In the end, it appeared that the stakeholders were settling for the use of a ''Teams'' channel.

Tayo asked for 2 things:

• Can we pilot the idea (means trial of the agreed process) of this resolution across affected departments for the functions which ServiceNow is unable to cater for, however, the group can continue working as usual as regards functions which ServiceNow will be able to cater for upon go live.
• Can we reserve one hour in our diaries each week to meet and deliberate on the success of the pilot.

How do you bridge the gap

- The stakeholders agreed, they chose a date and the workshop ended. The stakeholders then took the resolution back to their individual teams and asked that they all start using a designated ''Teams'' channel for the specified tasks.

Week 3

Tayo decided to pay a visit to all the departments where this trial should now be taking place. He discovered that most departments were compliant, but a few other departments were still doing the old process. Tayo began to educate these few other departments and also escalated it to their managers. For those who already started following the new process, Tayo was keen to find out if they were facing any issues in this new process, luckily, all seemed to be going well. Tayo repeated the visits 2 other days during that week and during the scheduled weekly workshop with the stakeholders, they agreed that the process was working fine in their various departments.
They agreed to monitor it for one more week.

Week 4

Tayo observed the progress of this new process, and all seemed to be going well. During the next workshop, Tayo suggested that if the stakeholders were satisfied, they could call it a deal and sign off on it as a future state requirement. All stakeholders gave a verbal approval. Tayo also sent them individual emails afterwards so he could have the signoff in writing. Once he received the sign off in writing, he began to map out the future state process maps for the agreed new way of working. He then wrote user stories and collaborated with the configuration team to configure ServiceNow according to the user stories and acceptance criteria.
Tayo notified the training manager of the potential change and promised to shed more light once configuration was complete.

Now let's ask you 2 questions

• What type of stakeholders do you think Tayo convened during these workshops?
• What skills do you think Tayo deployed in managing this situation?
• Do you see yourself being in Tayo's shoes? if the answer is yes, book a call today and let's get you to Tayo's proficiency.

Conclusion

Business Analysis as the name and definition implies, isn't just about writing user stories. Unfortunately, there are lots of PR around training BAs to write user stories and follow through with the development of a software product. Trust me, whilst this is equally an important skill to have, Business Analysis is ways more about what Tayo did and as you can see from the case study, Tayo did write user stories but very importantly, the process which led to writing the user stories is what you MUST master as a Business Analyst.