Oh dear, we've really lost our knack of defining business needs. We've invented all sorts of ways of trying to avoid this task as we've made it almost too hard to do.

Back in the 1970s business needs were defined by business people. There was no such thing as an "IT profession". Business people were taught analysis and system specification skills and they defined the business' needs.

Then we reversed the situation. We invented "systems analysts" who knew little about the business and we tried to teach them how to extract the needs from the business.

Then, to solve the problem of miscommunication when the systems analyst passed the specification to the programmer, we made things worse by creating "analyst programmers" who had even less business acumen and understanding!

As this approach was not found to be working well, we then invented new ways to get at those business needs — rapid application development, joint application design (now there's a thought!), prototyping and others. These all had limited success.

Then we were 'saved' by software packages. After several unsuccessful attempts to identify business needs and translate them into (somewhat rudimentary) packages, a new mantra was born, "Change your business to fit the software". This approach traded off perceived technical risk for increased business risk.

Why was this approach so readily accepted? There are several reasons including:

• the business was less comfortable with technical risk than business risk (insofar as they even considered the latter)
  
  
• it allowed the software implementers/consultants to give you what they knew how to deliver, and they were not exposed by trying to work out how to make the system work for you
  
  
• it was accompanied by this notion of "world's best practice" that people saw as coming free in the new system and that was definitely better than they could come up with themselves (we've proved this notion wrong repeatedly)
  
  
• there was a purposeful confusion between 'configuration' and 'customization'. Packages are set up to be configured and this does not constrain future upgrades. Most packages also allow some customizations to be 'attached' to the core code (without changing it). These options were, however, buried under the picture of core code customization to scare the business off defining their own needs.
  
  
• and, of course, the fact that we were still lousy at defining business needs. Matching to a pre-defined solution, avoiding the need to really define our needs, became "Why won't this (the software solution) work for you?" and "Which of these features (goodies) would you like?" — lolly shopping that caused many a budget overrun.