This article originally appeared in the December 2002 issue of The Rational Edge E-zine on-line magazine, copyright 2002-2003 IBM and Max Wideman.

The Rational Unified Process (RUP) is a rigorous software development process advocated by the Rational Software Corporation.

The downloadable PDF file of the paper on this site is the one prepared by the Rational Edge editorial staff with the special assistance of Ms Marlene Ellin.

Published here June, 2003.

Introduction | Problems with the Traditional Acquisition Process | Keeping It Simple
What Does Contracting Involve? | The Vocabulary of Acquistion | PART II

Problems with the Traditional Acquisition Process

From a RUP perspective, the business of acquisition by contract (i.e., "contracting") introduces a whole new process unto itself, complete with roles and artifacts. This can be problematic for a typical software development organization because the traditional acquisition process is contract driven; and the specialists who direct it focus on activities, practices, and objectives that run counter to the best interests of successful software development.

What happens in a traditional acquisition process? Simply put, you figure out what you want, describe it in a Request for Proposal, solicit bids, pick a competent vendor with the lowest price and fastest delivery, enter into a standard legal contract, wait for the work to be finished, and come back when you can "pick up the keys to the front door." Unfortunately, as often as not, when you walk through that front door, the entrance hall is not what you expected, and it might lead directly to the back door!

Until recently, this was the process European countries[1] used to acquire large Defense Information Systems (DISs), and, as Pitette notes:

"... there are many sad stories to tell about large DIS projects procured under classic, strictly sequential, "big-bang" model (also termed "grand-design" or "one-shot") -- stories about late deliveries, cost overruns, and failures to meet users' real needs. The problems stem from the big bang's inherent inability to deal with a few stark realities."

These "realities" include the following:

  • You can't express all your needs up front. It is usually not feasible to define in detail (that is, before starting full-scale development) the operational capabilities and functional characteristics of the entire system.

  • Technology changes over time. Acquisition lifecycles for very large systems (such as DISs) span a long period of time, during which significant technology shifts may occur.

  • Large systems are also complex systems. This means it is difficult to cope with them adequately unless you have an approach for mastering complexity.

Actually, based on my experience in software development, the system does not have to be all that large, or the acquisition lifecycle all that long, to suffer from exactly the same difficulties. In fact, Pitette might have added:

  • The acquiring authority often fails to stay involved with the ongoing delivery of work. Typically, this is because fixed pricing discourages them from doing so. Conversely, some purchasers breach their contracts by "interfering" too much.

  • The acquiring authority is not prepared for the unwieldy changes that typify software projects.

  • The authority may fall short in managing and coordinating large, parallel acquisition efforts involving multiple hardware/software suppliers.

Despite all of these shortcomings, the big-bang contract model remains very popular with executive and senior managers on the acquisition side. Why? Because they have a responsibility to maintain the financial viability of their organization. This applies whether the enterprise is government, private sector, or even non-profit. In assessing the needs of their organization, and in prioritizing opportunities (even if some system upgrades are mandated by legislation), managers must know "how much" in order to budget, estimate return on investment, and select among competing needs. And for commercial organizations, the question of "how soon" is usually more important than for those in the public sector.

Unfortunately, senior managers often have little understanding of how software development is best conducted, and (I hesitate to suggest), software developers often have little understanding of senior management's needs. So, there is potential for a serious communication gap between these two groups within the acquiring organization and often between managers in the acquiring organization and developers on the supply side as well.

Introduction  Introduction

1. ISO/IEC 12207 International Standard, Section 3: "Definitions"
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page