This site is intended to serve business analysts and this article will provide you with the helicopter view (i.e. very high level view) of business analysis, covering all the key areas very rapidly. You can then choose which areas you want to explore further.
If you want to know which articles already exist, just look at the posts on the right and the tags – that should give you a good idea of which areas have already been covered.
Alternatively, just drop me a line at alex@bamentor.com with the content you were looking for and I’ll see what I can do.
What is business analysis?
If you’re brand new to this and are thinking of taking up a career, I’d highly recommend you read this article – What is business analysis?. This is where I present a simple analogy of the analyst as interpreter between the business and IT as a means of explaining the BA’s role. Have a look and see if it helps you out.
In the beginning (why?)
A good place to start is where a business analyst is first called upon. The business always has to justify any expenditure in changing the business by understanding the cost and demonstrating the value or benefit that the desired change supplies – this is supplied by the Business Case.
An early decision is made at this point whether to proceed – if the cost outweighs the benefit, clearly there is no point in proceeding. Of course, at this stage, the costs aren’t really that well understood so a more detailed investigation is required. This comes in the form of a Feasibility Study which allows the business to invest a relatively modest sum to provide more reliable costs. There are many other aspects to the feasibility study regarding, for example, the impact on the organisation of the proposed change and how it would be introduced.
The Study will make a recommendation on whether to proceed and, if so, how to proceed with the proposed change. The appropriate parties within the business (typically at executive level) will decide whether to proceed based on this information.
The middle (let’s do it)
Once the project has been authorised to proceed then some nuts and bolts work is required. There will be some planning to decide how to proceed with the project. The project manager would have been appointed by this time and he will have overall responsibility for delivering the project. He will look to the business analyst (or lead business analyst) to provide the plan and approach on how to gather the requirements, document them and have them agreed with the stakeholders.
The initial task for the business analyst is to create a requirements plan which will determine the team required, the stakeholders , other involved parties and the approach to be taken. The business analyst’s responsibility though the remainder of the project is often referred to as requirements engineering.
In creating the plan, it is necessary to understand the parties involved in the business who have an interest in the project whether directly or indirectly. They may have an interest because:
- their day job will be impacted – maybe it will make them more productive
- they are responsible for managing cost and the ultimate success of the project – usually the business or executive sponsor
- they are managing the organisation risk with regard to regulatory compliance
- they will have to support the business change once the project has completed
- Analyse existing documents
This could be, for example, existing training materials, business processes or legal documents
- Interviewing users
This can be successful but requires a sensitive approach that is open and puts the user at ease
- Receiving user training
This is an interesting variation on the above which tends to put the user at their ease
- Observing users
- Prototyping
People always respond better to something that looks like a real system – they wil be more engaged than with documents.~
- Workshop (see Workshops – an Introduction)
This is a common technique which is necessary when there are a number of different views and there may need to be negotiation and compromise
- Questionnaire
Can be valuable in very specific circumstances
The business analyst must document the requirements and this can take several forms depending on the type of requirements:
Business operating model or business domain model
This represents a pure business view and is used to understand both the current state of the organisation and the how it will look after the project has been completed
- To Be and As is process models
- Organisational context
- Requirements catalogue
This shows the high level requirements of the business driven from the project objectives. It is not a simple exercise to ensure quality requirements (see Requirements engineering and quality)
Functional requirements
These are the specific requirements that relate to the behaviour of the proposed system:
- Use case model (see Use Cases – an Introduction)
Well etablished approach using a mixture of diagrams and narrative descriptions
- Storyboard (see Requirements Gathering alongside use cases for more on this)
Less formal approach using pictures, based on the idea from the film world
- Prototype
More engaging approach which delivers ‘mockup’ of system. Can vary from very approximate static diagrams through to fully interactive with representative data.
- State diagram
Very specific approach that adds value when an entity has a complex lifecycle e.g. Customer, Order
It will also be necessary to detail non-functional requirements which describe the characteristics or qualities of the resulting system (see Non-functional requirements).
If you would like to read more about use case modelling and how it fits in with business processes and context diagrams, see Use Cases - what comes before?
Data requirements
These show the entities and attributes of importance to the business. These can be overlooked and treated as ‘technical documents’ but they provide an important statement of the business and their requirements from a different viewpoint.
- Business object model
Shows business entities, their attributes and relationships
- Data dictionary
Shows more detail about attributes
Iterating
There are several methods for gathering requirements and, subsequently, documenting them but this should not be viewed as a linear process. In reality, the business analyst will pick and choose from the techniques and repeat the cycle of eliciting, documenting and reviewing requirements several times.
The focus must be on one particular area at a time as stakeholders will expect different levels of involvement depending on their degree of interest or the relevance of a specific area to them. Requirements management and planning should take account of this so that the level of stakeholder involvement can be communicated at the outset
Agreement
The gathering and documenting exercise will reach a point where agreement needs to be reached between all parties concerned. Typically, this will involve the creation of one or more documents which will be distributed for review before a final sign off workshop where the business analyst will facilitate a discussion between the stakeholders to resolve any outstanding concerns or disputes before agreeing the final set of requirements.
Depending on the project approach, this may happen several times, for each iteration where the project delivers an agreed system within each iteration which evolves towards the complete system (aka the Agile approach).
The heavy lifting
Once the requirements have been established, that’s when the project really ramps up as designers, builders, testers and 3rd parties are engaged to design, build and test what has been specified. Of course, this would have been started in parallel to requirements gathering but it can’t really take off until the requirements have been formally agreed.
This takes a lot of manpower and is where significant costs are incurred. The business analyst’s role during this phase is to be available to explain and clarify the requirements, ensure the requirements are traced through to design and build, support the testing or QA effort and assist in managing change.
The end (did we do it?)
Benefits realisation
Beyond the successful delivery of the project, there will be efforts to ensure that the benefits that were originally identified are delivered and the cost savings achieved.
Useful links
Most of this was my based on my experience but I used the Business Analysis Body of Knowledge (available here in draft or official version if you become a member) to provide some of the structure.
741 Responses to “The big picture”
Read below or add a comment...
Trackbacks