Articles
Business Analysis Basics
04.12.06
With plenty of talk in the industry about the growing importance of the business analyst, it’s worth taking a step back and understanding exactly what the analyst does. Most employers hire a BA to do three things:
- Engage with clients, stakeholders, project sponsors
- Analyse problems and create solutions
- Document solutions as a specification
Lets have a look at what’s involved in each step...
Engage with clients
Before a client bares their soul and tells you their business problems (i.e. objectives) they need to know it’s worth their time. In other words they need to believe that you can help them. To do this you have to establish a relationship. This doesn’t mean a family holiday together or inviting them over for a barbie - but it does mean demonstrating professionalism and the use of sound techniques (not guesswork) to tackle their problems. You’ll be documenting objectives, scope, constraints and sponsors in a Terms of Reference and documenting their business needs as a Business Requirements Specification. These are standard templates which give clients re-assurance that this has been done before, particularly if your organisations uses them for all projects.
Ultimately you have to establish trust with your client. Their belief that you can get the job done is far better than any expense account or entertainment allowance.
Analyse client problems and create solutions
Unless you understand your client’s problem, they’re not going to believe that you can come up with a solution. So how do you demonstrate understanding of a business area when the person in front of you has been doing it for years and knows you will never understand it as well as them. Well probably you can’t. But you can show them that by using a structured approach to analysing and solving problems, you are using proven techniques which have solved tens of thousands of business problems in organisations throughout the world.
Much as clients can become passionate and immersed in their area of work - seeing it as unique or ground breaking – the reality is that elsewhere in the world, others are probably doing very similar work. Most problems have been encountered before. Ultimately there is always a solution to your client’s problem – even if the only viable one means going back to the Terms of Reference and redefining the project’s objectives. And don’t think that you need to be a creative genius to solve problems – more problems are solved every day through hard work than through flashes of inspiration. One of our favourite quotes from one of the world’s great creatives:
Great things are not done by impulse, but by a series of small things brought together.
Vincent Van Gogh (1853-1890)
Document solutions as a specification
So now you’ve bonded with your client, analysed their problems and designed a solution which they can understand and agree to fund. How do you build it? Well luckily you’ve got a number of choices depending on your organisation. You may have an in-house development team or a trusted external supplier. You may use an off-shore company or go out to tender. All you need for a quote is a specification which is accurate, unambiguous, comprehensive and doesn’t pre-suppose any particular software or hardware – after all you’ve already specified your technology constraints in the form of non-functional requirements.
The document is commonly called a Logical Model (or Functional Specification), and the documentation standards come in a variety of shapes and sizes. They can range form a highly prescriptive and highly detailed document – good for tenders, mainframe systems and outsourcing – through to minimalist documents which just aim to capture concepts. The later are good for exploratory projects where the final solution is not known and may require several iterations before it emerges.
In the end the project will dictate the level of documentation which works best but be sure you understand what you leave out as well as what you’re including.
As many of you know, the analyst’s job doesn’t end there. They can be called on to write business cases, manage the project, write and conduct acceptance testing…..etc. However lets stick to the basics for now.
As mentioned at the start of this article, there’s plenty of talk in the industry about business analyst’s skills. The following skills have been refined by IRM in over 20 years of business analyst training and have been packaged into three course covering the fundamentals of business analysis.
|
Requirements Gathering & Specification (RGS)
|
Engage with clients
|
scope project, set boundaries, agree system targets
write a Terms of Reference (Project Charter)
plan and conduct stakeholder interviews
establish functional & non-functional requirements
analyse and prioritise the client's requirements
validate for completeness & accuracy
document a Business Requirements specification
present recommendations to stakeholders
|
|
Analysing & Solving Problems (ASP)
|
Analyse client problems and create solutions
|
use standardised methodology for identifying and defining problems
apply techniques for analysing problems, their root cause and impact
use creative & lateral thinking techniques to identify solutions
assess solutions based on risk, impact and feasibility
select and justify the recommended solution
|
|
Business Analysis (BA)
|
Document solutions as a specification
|
describe typical development lifecycles
describe milestones and the checkpoint process
model existing systems
produce data and process models of proposed systems
define supporting data in a data dictionary
specify process logic (business rules)
apply essential modelling to current/future systems
document business requirements as a functional specification
|
We’re not saying these are "gospel" – but they have worked for thousands of analysts across hundreds of companies.
return to white paper & articles menu
|
|