Business analysts should be corporate assets
Business analysis in local organisations is typically at maturity level zero.
A project manager's first task after being appointed to an IT development is to seek out a business analyst to gather requirements. After that, it's on to the development and then the implementation. It's the way it's done. It's the way it's always been done.
But business analysts are not used optimally if they are only used to "gather" requirements. In fact, the International Institute of Business Analysts has dropped the word "gathering" from its vocabulary and replaced it with "elicit".
A large local bank I worked with has business analysts who belong to the different business units. Then they have technology teams with systems analysts who create the specifications that developers use.
Systems analysts bin the Yellow Pages
What was happening was that the business analysts were talking to the users and defining the requirements which they would then translate into a Word document as fat as the Yellow Pages. The systems analysts would get it, blink twice and throw it in the bin as this document is simply impossible to translate into the technical definitions they are required to produce. They couldn't understand it and it was too lengthy for them to wade through.
Then the systems analysts would redo it all themselves but, since they're not allowed to talk to the users as that is the job of the business analyst, they'd base the analysis on their domain knowledge and a lot of guesswork. This was actually taking place, in SA, at a large bank.
It's not an isolated incident - it happens in many large organisations that are still struggling to optimise the role of the business analyst. No wonder such a high percentage of software developed is never used and littered with bugs.
Business analysis in South African organisations is typically at maturity level zero. Business analysts should have an entirely different role in a project that's going to be successful. They elicit requirements - they don't gather them. Good business analysts will ask the right questions at the right time and document the answers in a succinct unambiguous way, a way that is understood by business. These questions elicit the correct information from business people and elevate an organisation's analysis role to maturity level one.
In most of those cases the first problem is that businesses and project managers who use business analysts just to gather requirements don't understand how to make the most of them. The second problem is that the business analysts who want to gather requirements don't understand their own role and are often hampered by not having appropriate skills.
Give the business analysts the correct skills and understanding of their role and the scenario changes. Not only do projects have a far greater chance of success, but the business gains a valuable resource that matures over time.
The maturation process
No wonder such a high percentage of software developed is never used and littered with bugs.Robin Grace is principal consultant for business analysis at IndigoCube.
A business analyst's proper role is to take the business case to the technology developers. They do that through models - graphic representations of what businesses need and what technology can do for them. Businesses suddenly realise many more benefits when that happens. And they've only reached maturity level one.
But why do graphic representations help? Visualisation of the value chain is a critical element of success. It helps business stakeholders understand their operations. It removes ambiguity. Bad business analysts get it wrong but good business analysts deliver representations that speak to business people and software developers alike. With a minor massage, even other parts of businesses can use the graphics to represent, for example, an order clerk's role in the business, understand what skills that person must have to fulfil their role, how the process can be more efficient and where any potential pitfalls exist.
These graphic representations are the foundation for describing the "how" of technology around a business process - how technology will be used to fulfil a business need. It's what's most commonly misinterpreted as requirements gathering.
And when business users see the results of this approach by a good business analyst who understands their role, then they'll request that business analysts join all of their project teams in the future.
It's a fundamental shift from standard practice - now the business analyst is appointed at the same time as a project manager if not before. The business analyst is involved right through the process in the role of the business, technology go-between, instead of just gathering requirements and moving on.
Business people really get excited when they take the business analyst's representations, the diagrams, and say: "If we play with these a little we can see where the bottlenecks are." That elevates the business analyst's role in the organisation. They can be used to solve business problems at a departmental, divisional or business unit level, which makes maturity level two business analysts - no longer just IT resources but - enterprise resources.
Define the outcome, not the approach
Business analysts who progress beyond those roles and work with processes that cross divisional boundaries begin to understand the value chain across organisations. Understanding the impact processes have in horizontal flows through a business makes business analysts a strategic resource at executive management's command.
But business analysts are only going to progress through the project, enterprise and strategic phases, and become valuable corporate assets, if they are skilled and have the correct toolsets. And they also need businesses to use them correctly.
Too many organisations operate the old way, telling business analysts what antiquated methods to use to define requirements. They should be telling business analysts to define requirements and saying: "This is the business outcome I'm looking for."
The business analyst in turn should be adequately skilled to analyse and document this requirement using the appropriate methods and techniques to enable the organisation to produce an optimal solution. Then real business benefit starts to be derived from the role of the business analysts.
* Robin Grace is principal consultant for business analysis at IndigoCube.
Principal consultant, IndigoCube.
Robin Grace is principal consultant at IndigoCube. He entered the IT industry via the Van Zyl and Pritchard Cobol Course in 1979, rising through the normal IT ranks to the position of systems analyst.
He has been involved with methods and methodologies ever since reading up on James Martin's Bubble Diagrams for Data Modelling. Grace has used, consulted on and taught on many methods since then, worked for Comcon as method manager and spent many years working for Mike Bergen & Associates as a consultant, involved with information engineering among its various clients.
He believes the importance of business analysis is under-recognised in the industry. He has been exposed to methods as diverse as catalysis to information engineering, and more recently UML and BPM.
Robin Grace is principal consultant at IndigoCube. He entered the IT industry via the Van Zyl and Pritchard Cobol Course in 1979, rising through the normal IT ranks to the position of systems analyst. He has been involved with methods and methodologies ever since reading up on James Martin's Bubble Diagrams for Data Modelling. Grace has used, consulted on and taught on many methods since then, worked for Comcon as method manager and spent many years working for Mike Bergen & Associates as a consultant, involved with information engineering among its various clients. He believes the importance of business analysis is under-recognised in the industry. He has been exposed to methods as diverse as catalysis to information engineering, and more recently UML and BPM.