Business Technology

Implementing business technology to serve strategic goals and objectives.

Ultimately, a company’s business technology infrastructure either supports or impedes its strategic goals and objectives – and if it supports them, it rarely does so by accident. There are simply too many ways that business technology can evolve; only a few of those potential outcomes are likely to provide the best possible support for any given business strategy.  Either the evolution of a company’s business technology (especially the evolution of its major software applications) must be designed with the company’s actual – and possibly unique – strategic objectives clearly in sight, or business technology as implemented will eventually conflict with those objectives.

Much is known about the process of software acquisition and implementation.  Much of the best work in this area (which we heartily endorse) is concerned with the structure of successful implementation projects, emphasizing the themes of risk management and requirements analysis.  Much has been made of the alarmingly high failure rate experienced by major software implementations. In particular, there has been an entirely proper emphasis (in our view) on the critical importance of grounding implementation projects in sound requirements analysis: the correlation between loose requirements gathering and implementation project failure has been demonstrated many times over (though it can’t be stated often enough, in view of the continued prevalence of failure).

What hasn’t been made clear is twofold: the necessity for a company’s strategic goals and objectives to be seen as system requirements, and the practical means for doing that.  This is our primary focus. 

Anyone who doubts the critical role of requirements analysis in initiatives to acquire and implement business technology (say, an ERP, CRM or SCM product) isn’t likely to be reading this.  In our view, failure in major software implementation has two general sources, which we think contribute about equally to the overall rate of failure.  The first is the well-remarked but still quite common failure to institute well-understood techniques of risk management into the project structure itself.  The second, not so well discussed, is the common discord between system requirements as stated and the actual measures by which success will ultimately be judged. We concentrate on three aspects of this:

• The mechanics of effectively translating strategic goals and objectives into usable, concrete statements of requirements.
• Stating requirements so thoroughly and concretely that no one could imagine that they were being fulfilled during implementation, only to discover later that they were not.
• Extending and evolving the statement of requirements beyond initial implementation, into the lengthy period of maturation, maintenance and incremental change that lies between major system changeovers.

To learn more about this, visit our library of articles on these subjects or contact us directly.