At first glance it may seem that there is little difference between a BA and a Bridger.
First off, it is important to realise that there is more than one flavour of BA and end also more than one flavour of Bridger so every opinion is completely valid. Additionally it is likely that a Bridger will also be an experienced BA or Product manager and some BAs will, knowingly or not, be Bridgers.
In principal I do think it is easy enough to draw some clear comparisons that differentiate the Bridger form the BA.
- The profession of BA within the world of IT systems and process automation has evolved almost entirely form the IT profession as opposed to from the Business . Even with a large number of Universities now producing Business Analysts, this has changed little and the curriculum is heavily flavoured with IT as opposed to business. These BAs are really much closer to requirement engineers than Business Analysts in my view.
- The BA almost always operates as part of an IT lead project and under the leadership of a Project manager employed by the IT department or indeed by the external system supplier.
- The BA is invariably an analyst by nature, extremely oriented towards process, mathematics and systems as opposed to being business savvy, intuitive or people oriented.
- The Bridger is an experienced business person with a business training and an ability to empathise with business managers, to understand and champion their concerns and to help them find business solutions.
- The Bridger is a people person with experience and knowledge of human motivation and the fundamentals of behavioural change within an organisation and as such is able to define solutions with an eye to their impacts at an organisational level and the likelihood of their enthusiastic and successful adoption
- The Bridger also has training in IT and sufficient understanding of what is possible to be able to translate between the language of systems and the language of Business.
So when should you use a Bridger instead of a BA?
When you are approaching a project that you intuitively expect to meet with a level of resistance within the business, it is critical that you choose someone with a heightened awareness of change management issues. Much of the potential risk can be eliminated at the business process or requirements engineering stages as opposed to surfacing on launch day. Requirements engineering can and should be used as a tool to communicate the rationale and potential impacts of change and to build in a degree of acceptance early on.
When you have complex business problems to solve that require more than just basic process engineering to resolve it and requires the continual engagement of senior stakeholders both as contributors and accepters.
When you have a history of conflicts between IT and the business in terms of IT investments it can be beneficial to have an arbitrator and fixer who can understand both sides of the argument, present them effectively to the other side and gain critical agreements that allow for progress to be made.
When you want to understand how technology can deliver competitive advantage as opposed to which is the marginally better technical architecture.