Don’t be a Business Analyst Bully!
I was involved in a conversation a few weeks ago with a group of business analysts. The topic was around how to get reviewers of requirements to be engaged and get the necessary sign-off. I noticed two schools of thought emerged. One was an advocate approach and the second was a bully approach. The advocate approach was geared towards truly receiving buy-in, where the bully approach consisted of assuming buy-in and using pressure to get sign-off.
Although similar to a bully on the school yard making you give up your lunch money or face being beaten up, the bully BA approach consisted of fear tactics. The ideas suggested consisted of sending a document out for review and if there were no questions by a certain date that meant approval. Silence was an approval. The bully approach also consisted of escalating to the reviewer’s management if sign-off was coming too slowly. What good comes from the bully approach? In my opinion…nothing. All it does is push off the inevitable which is the stakeholders’ finding issues in UAT or in the production environment. The stakeholders do not take accountability when the bully approach is used.
If stakeholders were comfortable with the requirements presented for sign-off there would be no issue obtaining sign-off. The main reason reviewers don’t want to sign-off on requirements is because they don’t know for sure what was captured will meet their need. Therefore, they don’t want to be held accountable. Forcing them to sign-off just moves back the time when they’ll see the solution and really be able to give their input and approve. If that time is in UAT, it’s too late.
What value is there in getting buy-in on written requirements, both textual and models? For the development and QA teams there is definite value. Things like use cases are used as the basis for test cases. The requirements give the development team necessary information to design a solution. But, do they really help the business stakeholder get a crystal clear picture of what that solution will look like? It helps somewhat, but it does not give the stakeholder the comfort they need to sign-off. Think about a home builder giving you a list of requirements for your new home. They may include details like three bedrooms, two baths, a two car garage, finished basement with a media room, etc. Even if they gave you extreme details related to each room, you would still not feel comfortable signing off and letting them build your home. You would want to see pictures.
Pictures were the essence of the advocate approach discussed. Along with the textual requirements and models you need to add pictures and possibly a way for the stakeholders to touch and feel a potential solution. These pictures can be anything from hand drawn prototypes on a piece of paper to a working simulation. These pictures give your stakeholders a much better idea that the solution team is headed in the right direction.
I want to share how I used prototypes in the past to give my stakeholders the comfort level they needed to obtain signing off on requirements. The examples I want to share are related to process change and data integration. I assume many of you have done prototypes of user interfaces and are hopefully incorporating them in your daily work.
Process Change
I worked on a project where we analyzed the business areas process for managing inventory. During our analysis the consensus was the system supporting the process could work with the updated process. So no system changes were being planned as part of the solution. Before we finalized requirements and moved forward with the solution we set up a prototype or simulation. We set-up a test environment for the application and sequestered a conference room where we simulated the new process. We went through every scenario and saw the new process in action. Two things happened. One we realized the application did need some slight modifications and, with those modifications the process would work and meet the goals of the project. After this simulation the stakeholders felt comfortable signing off on the requirements giving us the go-ahead to design and implement the solution.
Data Integration
Another initiative I worked on included updating the method used for data transfer between two systems. In this case there were no changes to the source or target system. The goal was to improve the speed and accuracy of the data transfer between the two systems. A large textual doc was created with data mapping and rules. This was perfect for the development team and overwhelming for the user community.
In this case we created screen shots for each scenario triggering the data transfer. For each scenario we had a screen shot of the source system triggering the transfer and a screen shot of the target system once the transfer was complete. This allowed the user community to see the cause and effect which gave them the comfort to sign-off.
There are many options available to you to help with prototyping and simulation from free solutions to various levels of fee based solutions. If you want to be an advocate you need to be creative and give your business stakeholders reason to feel comfortable with the solution requirements.
Don’t be a bully!
Kupe
Don’t forget to leave your comments below