We Don’t Need Business Analysts (do we?)

We Don’t Need Business Analysts (do we?)

In the heart of the old city, stood an old brick mortar bank, the Unhappy Bank. The management decided that it was about time to digitally transform the bank. Within its walls, a team of developers worked tirelessly on a new project, determined to revolutionize the banking industry. However, there was one crucial difference between this project and any other: there were no business analysts involved.

The stakeholders, confident in their own expertise, had decided to dispense with the traditional business analysis process. After all, they knew what they wanted, and they were confident that the developers could deliver.

The stakeholders gathered to document their own needs, rather than the bank’s business needs and objectives. They focused on how their existing systems worked and what they believed could be improved, without considering the broader picture. The result was that the business environment was not fully understood and there was no holistic view.

The current state of the IT systems was not documented, and some stakeholders were either missing or had a narrow view of their work. As a result, some systems and processes were overlooked.

Since the stakeholders were not aligned with the bank’s objectives, they were unsure of the impact of the project and how to measure it. What would constitute a successful project? And how could they measure success?

When they finally had a list of business changes, hell broke loose. The stakeholders considered their changes as the most important and they should be given top priority. They disagreed and could not agree on the final list of prioritised business changes.

Once the stakeholders finally had a list of business changes, a heated debate broke out. Everyone considered their own changes to be the most important and deserving of top priority. They disagreed and could not come to a consensus on the final list of prioritised business changes.

Once the stakeholders had finally agreed on a list of business changes, they needed to document it. However, they did not use any standard modeling methods, and the resulting documents were confusing.

The final step was to create a requirements and specifications document. This document was essential for developers to start implementation and for testers to start putting together their test scripts. However, the resulting document was large and poorly organized, without any owners of the requirements, cross-references, or version control. As a result, the document kept changing even during implementation, with additional requirements being added all the time.

The project dragged on and on, and management was furious. The project’s delay and cost overruns would have had a negative impact on the bank’s bottom line. Additionally, the project’s failure would have damaged the bank’s reputation and made it more difficult to attract and retain customers. The management demanded to know why the risk of a failed project had not been raised earlier. Someone finally mentioned that risk and impact analysis is usually done by business analysts, and the project did not have any. Management decided to hit the pause button and bring in business analysts.