Business Analysis - A role frustrated
During 10 years in the business systems analysis game I've come across a multitude of business analysts with the above skill sets - yet you can count on one hand those who actually solved a problem and created real value through the use of methodology on an IT project. Despite the shouts of 'well you must have worked on over ambitious and ill defined projects for most of your career', research by the Gartner Group, Standish and management guru Peter Drucker implies that most business analysis, in the realm of enabling IT, fails to live up to it's promise.
Thus the question; how useful is a highly qualified "shaper plant" of a business analyst, given the failure of IT to deliver value? Like all phenomena involving a battlefield of human emotion, complex relationships and pressure to perform, the answer starts with a resounding 'it depends'.
The Sun Tzu ethos advocates that in a military situation success is dependant on arming an army with an insight into opportunities, threats, tools, alliances and behaviours that help a soldier eat, live and prosper on the battlefield before firing the first salvo. Surely a business analyst must follow a similar line of reflection before rushing in guns blazing with UML, 7s, swim lanes and Business Process Re-engineering?
So the answer; that a business analyst should not only question his or her personal ability to deliver value in a project but also ask if the environment is ready for the analyst to attempt to resolve organisational issues. If not, their injection is a recipe for frustration and a potential disaster.
Shaping the Environment
To raise the probability of business analysis playing a symbiotic role in the creation of sustainable value the analyst must first frame the environment in which they can add value by enabling IT. Richard Daft's paradigm for the changing nature of management highlights the opportunity and the necessity. (see figure 1 opposite.) Dafts' view of the corporate world of change helps illuminate the business analyst's experience around an IT project:
* Never having sufficient time to understand the problem.
* Not having adequate access to process owners to:
* tap into problem domain knowledge
* achieve consensus
* or to reach a decision.
* Business as usual and personal agendas have higher priority than the BA's Gantt line on the project plan.
Therein lies the problem - faced with such an uphill task what does the average business analyst do about it?
A Touch of Realism
Firstly, one must recognise methodologies are useless unless perceived by all others in the problem domain to be of some value.
Secondly, getting those involved to buy into the 'way of the business analyst' means offering an incentive. Ask yourself why a process owner would be bothered with all those white board moments and flip chart experiences in the company of a business analyst? Call me cynical but people put their own wants and needs first. Those IT project business objectives aligned to corporate goals and a net present value laid out in a signed off business case can have little real impact.
Thirdly, following a methodology does not guarantee success. A UML exercise coupled with DSDM controlled within a PRINCE 2 framework will work well on paper but guaranteed success with this approach comes with massive amounts of small print. Methodology assumes perfect information, perfect resources and that everybody behaves rationally in the process. Would we be so lucky!
Trying to build a productive relationship with a bunch of complete strangers with bad experiences of the unresponsive IT department and exposure to doctrinaire "methodology-at-all costs" consultants will always be difficult. The conflict between this realism and the world portrayed in some case studies and numerous business systems analysis seminars, leaves the analyst with no choice but to take the initiative. …