Training of Business Analysts - A major challenge

According to a study published in July 2014 and conducted jointly by McKinsey and Oxford University, large IT projects on average exceed budgets by 66% % and deadlines by 33%, not to mention the deficit in services provided; other sources give even more pessimistic statistics. Nearly 17% of the projects have such a dire fate that they may jeopardize the very existence of the company.

The causes are multiple (explosion of coordination costs, change management, silos, casting errors...) but the mediocrity of the 'specifications' (Business Analysis) is still cited as the main source of stagnation, since Barry Boehm (80's!) and corroborated very regularly by Gartner, Standish, IAG, PMI® .... "Project managers in PMI's 2014 Pulse of the Profession ® study said that poor Requirements Management is a major cause of project failure, second only to changing organization priorities... 37 percent of organizations report inaccurate requirements gathering as a primary reason for project failure".

The quality of analysis is undoubtedly the best lever for project success, but how can this be achieved? Through training (*) dedicated to business-analysts and all those involved in this process: sponsors, project managers, system-analysts... roles often confused in SMEs.
Can you imagine building a building from a simple sketch? The multiplier effect of errors in the specifications is obvious, since they will logically contaminate the entire value chain and lead to a new rotation of the project lifecycle, with the added bonus of delays and additional costs. As noted by the Gartner group, it is paradoxical to note the waste of resources devoted to project administration while analysis remains a poor relation.

The Business Analysis blooper.

- Lack of structure. Writing in a literary style, heavy, ambiguous, full of adverbs, useless sentences, redundancies, contradictions... requiring a complete rewriting to be processed by suppliers, with the risk of transposition errors and difficulties to then bring together the expression of needs and the description of the solution. So many time bombs.
- Unrealistic demands, without economic justification, ignoring the solutions already in place. It is not possible to automate or control everything because it can be very expensive in development, maintenance and operation.
- Non-formulated requirements. Evidences for some are not for others.
- Artistic vagueness in non-functional requirements, which leaves room for many misinterpretations and misjudgements. With the same functional scope, development costs can vary greatly depending on the weight given to specificities such as controls, capacity, time constraints, performance, security, interfaces, availability, adaptability, traceability, migrations...
- Wanting to re-informatise sick processes, without having previously sanitized them, (Lean Six Sigma) by removing toxic elements.
- Lack of complementarity between repositories, which will pose problems when, for example, a project manager has to structure a project by starting from the analyses.
- The analysis process is often approached in an empirical and assured way, either by the 'client', or by an analyst who discovers the field to be computerized: dilemma between substance (exhaustiveness) and form (structure, readability).

Fortunately, this activity is tending to become more professional under the aegis of the IIBA (created in 2003 in Canada) and the IQBBA; this is to be welcomed given the stakes and the sum of skills required: analytical, communication, managerial and ... even "commercial". Nevertheless, there is still some way to go to develop real 'methods'. The BABOK® of the IIBA is above all a toolbox, a checklist without really being a method and some people reproach it for being relatively cumbersome in terms of writing or a lack of maturity and complementarity with project management methods (PMBOK®, PRINCE2®...). Beware of fashions, translations, jargon and religious wars : "In 2013 there were preliminary discussions between IIBA and PMI based on a proposal put forward by PMI.... After several meetings, it became clear that IIBA and PMI did not share the same vision. After some discussion between PMI and IIBA, the IIBA Board determined that the proposal was not in the best interests of our members "....

Business Analysis: the fundamentals

The BA must allow a perfect understanding of the objectives and constraints and give a clear expression of the needs, both functional and non-functional, without necessarily proposing solutions from the outset. It must serve as a basis and framework for the following processes:
- Technical and functional analyses.
- Design of the solution.
- Test plan.
- Procedures, job descriptions, organization, training.
- Costing and budgeting.
- Modeling and construction of the information system.
- Priority setting, trade-offs.
- Project management: phasing (WBS) and casting ('stakeholders').
The word 'frame' implies a semantic and structural homogeneity: all documents produced from the BA must imperatively respect its structure and vocabulary, to facilitate the tasks of interpretation, structuring and validation. In order to avoid dangerous rewrites, the greatest possible symmetry between the design of the solution and the expression of the needs must be ensured, although the latter must be written in the required forms. A collection of specifications must also provide a maximum of elements allowing the optimization of the subordinate processes, by specifying in particular: the strategic objectives, the actors, the constraints, the operational perimeter, the rules of the game. The quality of the analyses is a guarantee of quality and an anti-ageing weapon for the software.

Role and profile of the Business Analyst (*)

Sherlock Holmes, Bill Gates, Descartes, Boileau,...
A profession that is determined and which essentially involves the analysis and formalization of requests for improvement of IT or organizational solutions, by proposing an implementation plan.
A critical role, requiring great versatility and which may be called upon to intervene in a macro or microscopic manner, sometimes within a broader framework of responsibilities. Profile of a robot:
- An analyst (!) able to formalize the needs and evaluate the maturity (*) of the processes concerned, in order to propose re-engineering if necessary. Knowing how to dissociate functional, technical, legal, security and operational needs...
- Synthesis spirit: aggregation capacity and modeling: process mapping, 'business rules'.
- Understanding of the business to be dealt with: experts expect to meet people who know how to anticipate their concerns.
- Detective skills. A curious, suspicious man, who knows how to identify key people and 'make them talk', if necessary by conducting workshops (Kaizen) offering additional guarantees in terms of completeness, consistency and objectivity... which can be further strengthened by cross-referencing with other sources or statistical measurements.
- Good communicator, relying on a 'plan', whether it be vocal, written or in a leadership role. He/she must be able to interact with most of the stakeholders: sponsor, project manager, experts, solution provider, etc.
- Versatility. The analyst must accompany the project throughout its life cycle and intervene to specify, arbitrate... or adapt the specifications to changes that occur after validation of the specifications. The world is changing.
- Pedagogue, knowing how to (make) respect a methodology or a referential compatible with the other methods used, upstream or downstream of the approach.
- Facilitator & Referee & Filter. Users' expectations are sometimes futuristic: it is necessary to assess their feasibility and sometimes eliminate them from the outset so as not to pollute the decision-making debate.
- Architect. Even if this is not its primary vocation, the BA must propose a conceptual vision of the expected solution and it is obviously necessary to reach a consensus on its outline: a prototype is often of great help.

The Tower of Babel of standards, references and methods

An abundance of standards, methods, reference systems, more or less mature, some of them in disuse or carried by the EEC, the USA, Canada, Switzerland, Great Britain... A "Tower of Babel" raising the question of stability, durability and interoperability between these different tools.

- Structuring standards to frame services: CMMI, ITIL®, COBIT, ISO 20000 / 27000 - 38500 - 9001, IT-CMF, P3O
- Modeling techniques. UML, ArchiMate, TOGAF, Merise.
- Project management methods and standards: PRINCE2®, PMBOK (PMI), ICB, ISO 21500, P3M3, Scrum, HERMES.
- A repository for steering "Business Analysis": BABOK developed by the IIBA.
- Process reengineering methods: Lean / Six Sigma

This classification is somewhat arbitrary and focuses on the main characteristics: there are areas of overlap, which are sometimes sources of confusion and friction and, fortunately, for some, there are gateways, which are a guarantee of interoperability and professional development. For example, the PMI announces for 2015 an extension of the PMBOK dealing specifically with the BA. Scrum is presented as an "agile" method covering at the same time analysis, development and project management, an approach presented as more flexible and perhaps adapted to the treatment of tactical objectives, but with an unlikely management of costs, deadlines and quality of the finished product.

Standards are the subject of struggles for influence between certification bodies acting at national, European or international level. These struggles are based on economic stakes and unfortunately they are an obstacle to the emergence of the 'dominant' standard. "In 2013 there were preliminary discussions between IIBA and PMI based on a proposal put forward by PMI...After several meetings, it became clear that IIBA and PMI did not share the same vision. After some discussion between PMI and IIBA, the IIBA Board determined that the proposal was not in the best interests of our members"...
For many companies and individuals, the deployment of these methods has the main objective of obtaining a certification, a quality label opening access to a market.

Recommendations for Analyst Training

The competence of the Analysts is a very strong lever of strategic performance; this competence is mainly based on two pillars: business expertise and mastery of an analysis method. By respecting the following principles:
- Maintain a permanent focus on business objectives.
- The expression of needs must propose a first outline of the project, established according to criteria of coherence and profitability, avoiding the trap of pharaonic projects, dangerous if the company does not have the required maturity.
- Haste is no speed. Perhaps it is urgent to wait. The choice of methods and reference systems is crucial and requires in-depth reflection to guarantee ROI and sustainability in the search for continuous improvement. It is also a question of avoiding creating silos by making certain departments prisoners of their excellence.
- The Pareto Law (the 80/20) also applies in this area. Avoid choosing an oversized method and never forget that a repository that is not maintained, dies.
- The 'job' skills can be provided by the school curriculum, an operational experience, an internship...". Learning by doing".
- Any expert is likely to be required to produce analyses and in many cases the learning curve is shorter from the trades to the BA than the other way around. Increasingly complex processes, time and cost pressures also argue for accelerated training: it is generally easier to 'convert' a business expert into an Analyst than the other way round.

Bernard Timmermans

(*) These subjects are the subject of consulting and training services provided by the Sàrl strategic-pilot.com. A new BA training available Q4/2014. Reactions and questions: info[at]strategic-pilot.com for the attention of Bernard Timmermans.