The tightrope to e-business project success

Abstract

Even though U.S. businesses spend half of their business equipment budgets on IT, only one out of six software projects is successful. Annually, this adds up to about $75 billion a year in failed projects, $22 billion in cost overruns, and another $175 million for systems that deliver less than they claim [9]. The elusivity of success is rooted in organizations’ inability to manage—or even recognize—the unexpected. Inattention to the emergent gap between what’s delivered and what’s finally needed, not technical incompetence, is what stumps even the best of intentions. Code, however good, cannot compensate for poor conceptualization. A new philosophy that views software as a medium in which knowledge is embedded rather than a product is emerging in some circles of the software community [2, 8]. Proponents of this view encourage embedding accurate knowledge into the design of a system over trying to manage requirements. Software project execution is like walking a tightrope from idea to implementation. It takes just the right balance between methodology and imagination, and following rules and knowing when to break them. Either excess slack or inflexibility guarantee a fall. We conducted a field study to assess the merits of this view and determine whether embedding knowledge in software design influences how well a project adapts to changing technology, unstable business needs, and customers who cannot seem to make up their mind. We found strong support for this emerging perspective: project teams that excel at knowledge integration best manage the unexpected to successfully execute innovation-intensive software projects. This article discusses the implications of our findings for software practice. From Engineering Imagination to Imagination Engineering The most difficult part of building a new system is determining what to build. Determining that is clearly a process of reducing ignorance about customer needs, technology, and a project’s business context [3]. A system is the byproduct of such knowledge. When that knowledge itself is incomplete, a project is built on an architecture of misunderstood business needs.