Business Analysis - Seperating Analysis fron Design
Separating Analysis from Design (decide what's needed before
deciding how to implement it)
Written by Brian Cooney, adapted for the web by Phil Dean.
Successful projects solve business problems
Looking at what business objectives you are trying to satisfy
before leaping into the technology enables you to use the
technology wisely, manage scope and cut costs, producing systems
which work for your clients.
It's easy to concentrate on the technical features of any
project and lose sight of the reason for its existence. Every
project exists to solve a problem. Either what you have doesn't
work well enough and needs improving, or you need to invent
something totally new. After all, "If it ain't broke, don't fix
it."
Too often the pressures of deadlines and budgets lead us to
bypass the important process of analysing business needs, and we
leap straight into the technology. But how often do we find that
the system doesn't do exactly what's required. Users are obliged
to use workarounds, reducing some of the benefits we were
supposed to provide which also affects our credibility. How
often do we need to invest extra time and expense in providing
Version 2 (and 3 and 4 and ...), when some careful work might
have exposed the real needs earlier?
The classic waterfall lifecycle
There are many variations on the System Development Life Cycle
(SDLC) and the following may not be exactly the terminology
which your methodology uses. The content of the phases is
certainly simplified in this table, but projects follow the
following phases:
(if the above image is not visible, you can view it here
http://www.irm.com.au/images/waterfallcycle.jpg or
you can download this article free of charge complete with
illustrations from
http://www.irm.com.au/businessanalysispapers.htm)
The output from each phase is the input to the next. Garbage in,
garbage out. Or to put it a little more elegantly, you can't
make a silk purse from a sow's ear. You can't implement a good
operational system without a good tested system, you can't build
a good system without good technical specifications and you
can't design a good system without a good business specification.
Ensure that talented people are used early in your project, to
ensure that you can achieve a good output at the end. Don't fool
yourself into thinking you are doing anybody any favours by
bypassing business analysis and moving straight to design, or by
combining the two. If the deadline is tight, negotiate a phased
implementation. If the budget is tight, remove some
functionality.
Many surveys, including the work of Boehm, have shown
consistently that the increase in cost of repairing errors
increases exponentially the later that repair takes place in the
SDLC. An error which costs a dollar to repair during the
Initiate phase will cost $10 to fix if it is left until
Analysis, $100 at Design, and $1000 if nothing is done until
Implementation. Yet how often do we say "We'll be able to fix
that in the code"?
Software tools can't think for you
Would Shakespeare have been a better writer if he had a word
processor? Any tool will believe what you tell it. There are
some terrific tools around which will take the mindless hack
work out of your job so that you can concentrate on doing what
you do best. But don't think that if you have the best tool
possible your systems will be the best possible. If you don't
believe me, grab your favourite word processor and write a
sonnet which people will be delighted to quote 400 years from
now.
You still need to do your own thinking. That's what business
analysis is all about.
Separate business analysis from technical design
Business analysis is about thinking what your solution should
do, while design is about how to make it happen using the
technology available. Bearing this in mind will make it easier
to avoid blending these two phases. What and How.
This will help you to build more robust systems.
What your business does doesn't change as much as how it gets
done. Technology changes more quickly than business needs.
Companies restructure. But what they do hasn't changed, just
which individual does it. Business analysis gives a logical view
of process and data needs and is not bound by physical
implementation.
IT specialists and business users regularly complain about their
misunderstandings. Of course they don't understand each other.
The technical people are concerned with making best use of their
technology, the users are concerned with achieving their
business goals. Business analysis should neatly bridge the gap.
The Terms of Reference produced during the Initiate phase should
include, unambiguously, the Problem to be solved, the Objective
to be achieved in order to solve that problem, Constraints and
Scope.
The purpose of Business analysis is to: