Abstract
Like all professions, business analysis has its golden rules – rules that are fundamental to the design of successful business systems. They might seem like common sense but it’s surprising how often we forget them and get ourselves into hot water. Here’s a short list of some of the more relevant ones…
The sooner you find a problem, the cheaper it is to fix
Get the specifications right
Recognise the total cost of a system
Don’t design the solution before you’ve analysed the problem
What applies to small systems doesn’t apply to large ones
Don’t allocate conflicting roles in a project to the same person
Now let’s have a look at what they mean, together with some real life examples witnessed by the author.
Background
You might feel that working with IT systems demands a constant refresh of skills and knowledge. Companies want efficiencies and reduced costs through new procedures such as Six Sigma, ITIL, COBIT. They must also accommodate new laws such as Sarbanes-Oxley plus IT governance and privacy legislation. People working directly with technology need vendor certification, be it Microsoft, Sun
Microsystems, SAP, CISCO, Oracle…etc. In project management there are certification bodies – AIPM, PMI – plus industry accepted methodologies such as
PRINCE2. Even the business analysis profession now has its own qualifications –
CBAP and QBAP (see the glossary for what all these acronyms mean).
With business and technology changing at breathtaking speed, the choices with accreditation and certification can be bewildering. How we apply this knowledge however still relies on fundamental principles which don’t change quite as fast, if at all.
What are the characteristics of a fundamental principle – a golden rule? Usually it’s a rule that can be applied whatever the business system or application, whatever the software or hardware platform. Consider the following and see how many apply in your environment.
IRM Training - White Paper
© 2008 IRM Training Pty Ltd www.irm.com.au 2
1) The sooner you find a problem, the cheaper it is to fix
Barry Boehm1 (noted software engineer and creator of the spiral development model) was one of the first people to consider how to estimate IT projects and where resources must be concentrated to achieve success. He showed that the cost of removing a fault in a system rose exponentially throughout the systems development life cycle. The following graph (courtesy IEEE Computer Society) illustrates the huge jump in costs the further along the development cycle that you go.
Boehm’s research showed that for very dollar spent correcting a fault in the requirements phase:
• $3.27 would be spent correcting it in the design phase
• $7.03 would be spent correcting it in the coding phase
• $51.33 would be spent correcting it in the testing phase
• $101.45 would be spent once the system went live
What does this mean for a business analyst? Let’s suppose you’ve got problem on your current project. You’re in the requirements gathering phase and one of the requirements just doesn’t make sense. To remedy this you need to organise an additional 2-hour workshop with stakeholders and managers to discuss and clarify the requirement. Let’s say the cost to the company of this workshop is
$1,000 in people’s time.
Now let’s suppose you didn’t spot the problem with this requirement until the design phase had started. Suddenly, the cost to your company of fixing it jumps to 3.27 times what it would have cost to fix it in the previous phase. ($3,200 in round figures). If you didn’t spot the problem until the coding phase the cost increases 7.03 times ($7,000) and if you didn’t fix the problem until testing it would be 51.33 times the initial cost. By the time your system is in production and under maintenance the cost of fixing your problem (which might originally only have cost you $1,000) has now mushroomed to $101,000 or 101.45 times the original cost.
1 Barry