6. For example, T.H. Kwon and R.W. Zmud, “Unifying the Fragmented Models of Information Systems Implementation,” in R.J. Boland and R.A. Hirschheim (eds.), 1987, Critical Issues in Information Systems Research, New York: John Wiley & Sons.
7. Barry Boehm, 1989, Software Risk Management Tutorial, Washington, D.C: IEEE Computer Society Press; Barry Boehm, 1991, “Software Risk Management: Principles and Practices,” IEEE Software, vol. 8 (1) pp. 32–41.
8. Brooks, Note 1.
9. For example, Boehm, 1989, 1990, note 7.
10. Mark Keil, Paul Cule, Kalle Lyytinen, and Roy Schmidt, 1998, “A Framework for Identifying Software Project Risks,” Communications of the ACM, vol. 41
(11) pp. 76–83.
11. Watts S. Humphrey, 1995, A Discipline for Software Engineering, Reading, MA: Addison-Wesley.
12. Reimus, note 4.
13. Fred P. Brooks, Jr. 1995, The Mythical Man-Month: Essays on Software Engineering, Reading, MA: Addison-Wesley.
14. California, note 3.
Chapter 5: Six Myths about Managing Software Development in the New Millennium
Linda G. Hayes
OVERVIEW
With widespread frustration over slipping schedules or outright runaway development projects, the dawning of a new millennium is an auspicious time to call into question the most basic assumptions regarding management of software development and adopt a strategy that reflects reality. This chapter reviews and debunks these assumptions, outlines an alternate view that takes into account the quantum changes that have occurred in software development within the last decade, and positions managers to succeed into the future.
MYTH 1: REQUIREMENTS EXIST
That requirements exist is the fundamental assumption of all software development projects. At first they exist in the minds of the users, in documented form from which the design proceeds, and then form the basis for acceptance of the finished project.
As logical and hopeful as this may sound, it is generally not proven true. Although users know what they want, it is not unlike the Supreme Court’
s understanding of
pornography: they know it when they see it. Until then, requirements are inchoate: inarticulate needs that do not, of themselves, describe the features and functions that would satisfy them.
What is widely attributed to scope creep, or the continuous expansion of the project requirements, is really just the natural process of distilling user needs into objective expression. For example, a requirement for a banking application might be to maximize the profitability of each customer. Once understood, this requirement spawns new requirements: the need to maximize the number of services sold to a single customer, which leads to the need for a unified database of all customers and services, and relational access among them.
Once the implementation begins, these requirements metamorphose into yet more: users realize that what appear to be many separate customers and accounts are often managed by a single individual, such as a parent creating trust accounts for children, and the requirement arises to define and associate subaccounts, followed by the need to present consolidated statements and reports … and so forth, and so on.
Therefore, if the project manager assumes the requirements can be expressed coherently and completely before development commences, and the entire project plan and schedule is based on that assumption, subsequent changes wreak havoc.
Scope creep, then, is really the inevitable realization that requirements are living, growing things that are discovered instead of defined.
Reality: Seek Problems, Not Solutions
Instead of asking users to describe requirements and solutions, ask them to describe their problems. If this is a new system, find out why it is being created — what is being done today and how will it change with the system? If this is a rewrite of an existing system, ask what is wrong with the old one. What problems will be solved?
This is a radically different approach than asking for requirements. A commonly told illustration of this involves the building manager whose tenants complained about slow elevators. After rejecting a series of costly elevator upgrade or replacement scenarios, the manager hired a problem-solving expert.
This expert interrogated the manager. What was wrong with the elevators? The tenants, he said, were complaining about waiting for them. Why did that matter, the expert asked? Because if they are unhappy they may move out, the manager responded, and I may lose my job. The expert promised a solution.
The next day, mirrors were installed outside the elevators on all floors. The tenant complaints subsided. The expert explained: the tenants were complaining about waiting, not about the elevators. The solution was to make the wait more pleasant, and mirrors offer the most popular pastime of all: admiring ourselves. This solution, of course, cost a tiny fraction of the time and money to speed up the elevators.
The point is, if one focuses on the real problem, one will arrive at the best solution. If starting with a solution, the wrong problem may be solved.
MYTH 2: DESIGNS ARE DOCUMENTS
The next assumption proceeds from the first. If requirements can be captured and subdued into a static state, then the design can be based upon them and reduced to a written document from which development flows. This assumption fails not only because the first is flawed, but also for an independent reason. It is difficult, if not impossible, to adequately express functionality in words and pictures. Software is interactive; documents are not.
There are at least two levels of interactivity of a design. The first is external, at the user interface level: what the user sees and does. A perfectly plausible screen design on paper may prove to be impractical when created. What appear to be trivial matters, such as using the mouse to position focus on a field or object, may render the application awkward and unworkable to a high-speed data entry clerk, trained in touch-typing, whose fingers never leave the keyboard.
The second level of interactivity is internal: the hardware platform, operating system, development language, database, network topology, and other decisions that affect how processing occurs and data is managed. An otherwise elegant database design may fail due to response time of the underlying network access protocol, or sheer volume demands.
Reality: Go with the Flow
Instead of expressing the design as a series of static artifacts — data elements, screens, files, reports — describe it in terms of business processes. What will the user do with it?
Users do not think about customer information databases or order entry screens.
They think about adding a new customer as the result of an order, answering customer questions about their orders, shipping the orders and sending out invoices, and making sure invoices are paid. They think in terms of processes, information, and workflow: they know their job.
Understanding the system as a set of processes as a user experiences it, beginning to end, will lead to a much different design than approaching the subject as a set of disparate entities. It forces the consideration of the flow and purpose of information
— not how it is stored, but when and why it is used.
Another important aspect of what is done is, how many and how often? Will there be 100 customers or one million? What happens most frequently — entering new customers or checking on orders? Are dozens of orders received daily, or thousands?
These numbers will greatly influence the internal design of the system, including not just the amount of storage but the throughput rates. The external design is also affected: screens are designed to support the way they will be needed. Frequently needed information will be readily accessible, and high volume transactions streamlined for heads-down entry instead of heads-up aesthetics.
Do not ask the users what they want to see. Ask them what they need to do.
MYTH 3: DEVELOPMENT IS LINEAR
If the foundation of requirements was coherent and complete, and the structure of the design solid and stable, development would indeed be a simple, predictable matter. In the traditional, linear development life cycle, coding is a segment that begins after design and ends with test.
Yet everyone knows this is not how it is. Our budgets tell us so. Sixty to 80 percent of corporate IT budgets are consumed by maintenance, which is a euphemism for development on existing systems — systems that have already been “released,”
sometimes decades ago. There is not an application alive — that is, being used —
that does not experience constant development. Whether called modifications or enhancements, the fact is that 25 percent of even a so-called stable application undergoes revision each year.
This indicates that software systems reflect the business, and successful businesses are in a state of continuous change and improvement. Change can be a good thing, but only if it is planned.
Reality: The Schedule Rules
Once ready to start creating the system, set a schedule that provides for the earliest possible release of the least possible amount of functionality. In other words, deliver the system before it is ready. Do not come up with the design and then the schedule:
come up with the schedule first and design as you go. Do not target for error-free completion; attempt to have something that does something.