Introduction
A Standish CHAOS Chronicles report states that only 28 per cent of software projects were expected to finish on time and on budget. Only 52 per cent of completed projects met their proposed functionality.
Based on a study of more than 13,000 U.S. projects, the Standish Group reported that successful projects made up 'just over a third or 34 percent of all projects...'
Estimates of the lost value for these projects in 2002 was $38 billion, with another $17 billion in cost overruns, for a total project waste of $55 billion against $255 billion total in project spending.
Unfortunately, poor project performance has become a way of life. Failure statistics like those above have ceased to even shock us. Most organisations have come to accept project failure - along with a loss of money, time and functionality - as a given.
With constantly improving technology, exponential resources and a concrete project management methodology, how does this continue to happen? It's time for our questioning to go beyond, 'Are projects failing?' Now it's time to ask why.
Why are projects failing?
In an online poll of 2,000 business professionals, it asked the question, 'What are the key challenges in translating user needs into systems specifications for mission critical projects?'
If a project fails, it's often assumed to be the project manager's fault. More and more, however, research is showing that this is not the case.
In the survey mentioned later on , an overwhelming 50 per cent of respondents cited poor requirements definition as their biggest challenge, thus raising a new question.
When projects fail, most organisations are quick to blame the project manager. But what about the business analysts? What role do they play? More importantly, what role should they play?
The role of the Business Analyst
In many organisations, the competencies necessary for a successful business analyst simply haven't been differentiated from those of a subject matter expert (SME) or a project manager. And yet each of these three positions have very distinct responsibilities during the project life cycle.
It's no wonder so many projects are failing. How can a business analyst - or anyone in any job - be expected to perform at a top level when his or her required competencies have not been clearly defined?
The answer is simple: They can't. Yet organisations worldwide are operating without defined competencies for their business analysts.
For many organisations, in fact, even the title of the person performing 'business analysis duties' can vary widely. According to a recent poll, there are several titles used for those performing the 'business analyst' role.
We know what business analysts do - essentially. At the most basic level, a business analyst acts as a translator or liaison between the customer or user and the IT person or group attempting to meet this user's needs. But what about the specifics?
According to the International Institute of Business Analysis, business analysts are 'responsible for identifying the business needs of their clients and stakeholders, to determine solutions to business problems.'
As a translator, he or she 'elicits, analyses, validates and documents business, organisational and/or operational requirements' (www.iiba.com).
Additionally, what processes are business analysts using to elicit, analyse, validate and document these requirements? Most organisations do not have set processes in place. And if they do, one needs to ask, 'What competencies does a business analyst need to accomplish these tasks successfully?'
Defining competencies
There are generally two distinct types of competencies. Both categories should describe employees' behaviours - descriptions of how they might be expected to perform given a particular task at hand.
First, there are those competencies that address organisational success. Such competencies are common across many jobs and demonstrate the key behaviours required for success regardless of position within the organisation.
For example, leadership, communication skills, vision, innovation and collaboration might be considered organisational competencies. All employees, regardless of function or role, must be accomplished in these areas in order to contribute to the success of the overall organisation.
Second, there are those competencies that address success for a certain job. Functional competencies refer to an individual's ability to perform a given set of activities based on their particular job.
These functional competencies are specific and necessary to an individual's success. For instance, functional competencies for a network administrator might include the ability to install a new server or troubleshoot network performance issues. These competencies are required for successful performance.
Setting concrete competencies
To combat this substantial issue of the undefined business analysis role, eight essential competencies have been determined.
Additionally, to aid in the organisational implementation of these competencies, this paper introduces the 'Business Analyst Competency Model'.
This model, which breaks down each competency as conceptual, logical, physical or contextual, takes into consideration all tasks and activities performed by a business analyst.
The model takes a fairly traditional approach, basing divisions on research conducted in countless organisations.
The competency model is a practical and straightforward aid to apply solid guidelines for the business analysts in your organisation - at all levels. The model is, fundamentally, a description of a competent business analyst.
The eight competencies include:
- Eliciting Requirements
- Creating the Business Requirements Document (BRD)
- Structured Analysis
- Object-oriented Analysis
- Testing
- End-user Support
- IT Fluency
- Business Process Re-engineering
In this article, we will examine the first three competencies - eliciting requirements, creating the BRD and structured analysis. By definition, a competency is made up of three components: knowledge, skill and ability.
Knowledge considers 'what is being measured?' Skill looks at 'how is it done?' Ability, lastly, examines 'to what degree can it be done?' Each of the competencies outlined below is broken down into these three components.
Clearly there are different responsibilities during each stage of a business analyst's career. For each competency, the specific tasks a competent business analyst should perform at the senior, intermediate and junior levels are designated.
We have defined typical levels of ability as follows:
- Senior level: Can do complex versions of task(s) at hand with minimal coaching
- Intermediate level: Can do simple versions of task(s) at hand with some coaching
- Junior level: Can perform tasks with help
Additionally, it is important to take into consideration the level of ability to which each business analyst performs. Very often it is assumed that all business analysts - junior, intermediate or senior - should be performing at 100 per cent accuracy.
Very rarely is this the case. To combat this misconception, we have included an 'ability' column for each competency. This simply sets a guideline for those in each role to strive for in terms of accuracy.
Competency #1: Eliciting requirements
On the most basic level, we know that a big part of a business analyst's job is to gather and document user requirements. Requirements can be conditions, functionality, products or services for internal or external use.
They are needed by a user or client to solve a business problem or achieve a business activity, and they are tied to the needs of business, rather than the constraints imposed by technology.
This means that the business analyst's job has more to do with identifying the desired results than the actions or resources required to reach these results - that's someone else’s job.
The purpose of gathering requirements is to provide an understanding of the problem or opportunity before trying to propose the solution.
The techniques necessary to capture requirements are often referred to as elicitation. Depending on the level of competency an individual demonstrates, the types of techniques should be considered carefully when applying them to any given situation.
Competency #2: Creating the Business Requirements Document
A business requirements document (BRD) is an exhaustive written study of all facets of regulatory, business, user, functional or non-functional requirements and provides insight into both the as-is and to-be states of the business area.
It is a detailed profile of primary and secondary user communities. It comes directly from the requirements the business analyst has already gathered. It only makes sense, then, that the BRD should be written by the business analyst.
After the document is completed, the business analyst and the client or user meet for a formal review and for approval of the BRD. The document is then shared with the rest of the development team, including the project manager.
In creating the BRD, it is very likely that a senior business analyst would be largely responsible for defining not only the various sources for requirements, but also the placement and relevancy of these requirements.
For example, senior business analysts may identify such items as the project charter and vision, business case, requirements work plan, vendor request documents and, potentially, business contract documents.
They may also work with the project manager to define the project and product scope. Any requested changes to any area of the BRD - before or after work has begun - must be carefully reviewed by the senior business analyst.
An intermediate business analyst, however, might work with the client or user, discussing changes necessary to gain approval.
When it comes to the BRD, the junior business analyst is expected to assist the intermediate and senior business analysts with the organisation and the actual documentation.
Competency #3: Structured analysis
Structured analysis refers to the art of modelling. In business analysis, modelling is used to support and enhance text-based requirements, help identify and validate requirements, document and communicate requirements and, finally, organise information into coherent ideas.
The most common types of business analysis models include business models, process models, data models and workflow models.
When it comes to the modelling competency, junior business analysts should be able to easily identify a variety of modelling techniques. They should also be able to create simple models based on information given to them by their intermediate or senior counterparts.
For example, a junior business analyst might be expected to create such diagrams as organisational charts or business interaction models. An intermediate business analyst may begin to develop such models as entity relationship diagrams, functional decomposition diagrams and the ever popular use case models.
The senior business analyst takes the models from the junior and intermediate business analysts and examines the as-is state in order to create the ideal to-be state.
When looking at models created by the intermediate business analyst, the senior team member is looking to find problems and opportunities that will change the process or the deliverable.
Developing the eight competencies to improve your organisation
In the beginning of this paper, we discussed the key challenges organisations face in translating user needs into systems specifications.
Any of these challenges can ultimately lead to project failure. A basic understanding of all eight competencies, however, is required before your business analysts become more capable in well-defined roles.
Though comprehensive, the competency model alone is not enough to improve business analysis practices within your organisation.
Implementing these competencies as organisational guidelines is essential. Once this is accomplished, organisations must then develop the competencies in their individual business analysts.
The first step in ensuring that your organisation's business analysts have the knowledge, skills and abilities necessary for success is to develop job functions and detailed descriptions based on this competency model.
After these have been determined and approved, it's essential that organisations 'take inventory' of the competencies their business analysts already possess.
There are specific assessments to test these competencies. Such tools will establish the knowledge level of individuals in each competency area and of the team as a whole.
If knowledge isn't baselined, improvement will be virtually impossible to track. The competency model is an ideal reference point for such an assessment.
After you have established the business analysis knowledge and ability levels within your organisation, you must implement training to improve any competencies that may be lacking.
The competency model can also serve as a validation tool for such training. It can be used to ensure that the performance improvement program is comprehensive, and that no behaviours or competencies are missed.
However, until business analysis competencies are dramatically improved within organisations, we will continue to see the same problems we've grown so accustomed to seeing.
Keeping in mind the eight competencies, as well as all of the people, processes, tools and technology available to your organisation, will put you on the path to better business analysis and, ultimately, more successful projects.
