However, we are not a consulting firm in the traditional sense because we are not about creating client dependencies on billable hours. Our experience with over 500 enterprise software implementation projects since the 1970’s and the associated symptoms, reasons and causes for the failures that occurred in those projects brought to the realization that a radically different approach from traditional requirements gathering methods had to be invented. We learned that failures usually occur in software acquisition and implementation projects because companies usually don’t know what they’re asking for when they set out to acquire a new piece of business software. If you ask most people in business how acquiring business software is different from acquiring the rest of the many things their companies make and buy, pretty soon they’ll mention that in some ways software is invisible. It can be hard even to see it and to distinguish it from other software, but it is even harder to inspect it, the way they’d automatically inspect a new lamp or desk or truck or pallet of ball bearings when they first receive those things. This difficulty is so obvious that it tends to mask an even more difficult problem: the fact that companies often set out to commission or buy new business software that they’re unable to describe very well. Companies usually leave it up to the experience of software sellers, solution providers or consultants to tell them how their business should operate and work or they use a fragmented approach themselves. Without a document that describes how a business operates and works, business transaction by business transaction, it’s almost impossible for a company to know precisely what an enterprise software system must do or allow to be done if their business is to run as it should. When we at Adaptive Growth say (as we often do) that most companies don’t really understand themselves, what we mean is that they can rarely describe the company in terms that will give software technology providers an accurate picture of how a new software system will be expected to fit into their company as a whole. Until a company learns how to do that, the usability and fitness of the software it acquires will tend to be hit or miss. Companies don’t know what they’re asking for because they don’t have an approach they can use themselves to describe to themselves how their business operates and works in terms that a consultant or software seller can understand.