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: