The 3 Day Business Analyst
When a business embarks on an IT project, the responsibility of the Business Analyst can be neatly summarised as ensuring the business knows what they want, know why they want it and know that they got it.
As a Business Analyst over many years, there have been, of course, many changes in the way IT projects have been delivered with corresponding changes in the way Business Analysts work.
These last few years have been different, the practices of the project team have not changed much but the Business people have changed. Many are very engaged with the way IT systems support their work, they use sophisticated IT systems both professionally and personally. They are comfortable with discussing interfaces, workflows, databases and integration.
This has been growing over the last few decades and I believe we are now at a tipping point with respect to the way the Business and Business Analysts work together.
Businesses can now work more efficiently with the Business Analyst resulting in increased business engagement with the project and decreased need for Business Analyst resourcing.
To put a number on it: I estimate that a project team which would have traditionally required a full time Business Analyst now only needs a 3 Day Business Analyst when working this way.
Why is this? In the past a Business Analyst would work as the bridge between two islands, "IT" and "the Business". Those two islands have now collided and everyone can work together much more easily.
While the Business Analyst was "bridging" IT and the Business they were often acting as the proxy of one for the other. This was necessary, back in the day, when Businesses treated an ICT project as a hands off affair and IT developers were not encouraged to talk to them. Today Businesses commit their people to the project team and developers want to talk to them. Just having a lot of conversations can be time wasting. Utilising a 3 Day Business Analyst to structure the flow of information keeps the conversations efficient.
It is now possible and certainly more efficient for businesses to write their own requirements and determine for themselves when they are met. It remains the work of the Business Analyst to guide them in organising those requirements and tests so they effectively and efficiently support the project.
A quick example.
Its not unusual to take a paragraph of raw requirement text from a business person and find that it is a well written mixture of goals, features, functionality and test scenarios. A Business Analyst can then demonstrate that 2 of the goals have no corresponding features or functionality and some of the stated functionality supports another goal and the test scenario requires associated unstated functionality.
This set of structured requirements are now completed when and if that information is needed by the project.
The same goes for testing. Business people write the best test scenarios and a BA can ensure that there is appropriate coverage and detail. User Acceptance Testing run by the Business itself has a greater impact on adoption. As before, increased Business engagement with a corresponding reduction in Business Analyst resourcing leads to better outcomes.