Business System Design


Peri What does a project do? You might think of it as a drill-down process that begins with an idea, a vague wish, or, very often, a session of bitching and moaning; it ends with millions of bytes of source and object code, computers, work to be done, jobs and paychecks, and, hopefully, some result that is better or faster than it was or sometimes even completely new.


So how does make this transformation? How does it go from being a gleam in some department manager's eye to an installed system? The way it's supposed to happen is that at every stage along the way the work from the previous stage is sub-divided into more steps and made more detailed. If the computer system is supposed to tie your shoe, the first breakdown of that general idea might divide the problem into three steps, "You stick your foot into the computer, it ties your shoe, and then you pull your foot out." The second breakdown might examine the questions of how, exactly, do you stick your foot into the computer, which shoelace should it grab first, and what happens if you're wearing your bunny slippers instead of your shoes. The second breakdown might increase the process to ten steps. The third to fifty. And so on. Eventually, when the level of detail in the written document reaches a certain stage, a programmer turns it into a computer program which is really nothing more than a final, desparately anal level of detail in a language the computer can understand.


Bill performed the first breakdown with his presentation to the Capital Expenditures Committee. True, he doesn't have a clue about data processing and isn't even remotely objective about the costs and the prospects of success, but that's the beginning none the less. And in spite of the fact that his presentation was an ethereal vapor that would be right at home in outer space, the budget for the new project is set in stone.

The next step is the Business System Design. If you're thinking that should really be the first thing that happens, you're right! The way it should work is that Bill should get funding for the Business System Design only, not the whole project, and make his presentation based on the results of that study. It never happens that way. The main reason is that companies like to know at the beginning of the year what their budget is going to be for the rest of the year, and projects with a maybe-yes, maybe-no aspect and undefined funding don't fit in with that desired level of certainty. Management also doesn't really understand the breakdown idea. Forget the BSD, let's get right into the coding, would be their attitude.


So the person doing the BSD comes into the project with a load of baggage that has to be juggled successfully for the project to continue.