I often see project teams, as they define the requirements for the project, use the words “want” and “need” to sort essential requirements from nonessential. The needs are the essential requirements, critical to project success, and the wants are non-essential. If we find out that we can’t satisfy all of the requirements, we’ll jettison some of the wants and focus on the needs.

This simple distinction between wants and needs has the advantage of allowing speedy triage. We gain that speed by trusting the unexamined and risky assumption that needs are more important than wants.

But hold on… The risky assumption that needs are more important than wants? Needs are more important than wants. Aren’t they?

Sort of. Most of the time. Often enough to lull us into believing that “needs versus wants” is a good way to sort requirements.

Labeling requirements simply as wants or needs hides at least as much information as it expresses. Each requirement, whether we call it a need or a want, is a value. Like any value, a requirement gains its importance through a rich web of beliefs and values called a Value Hierarchy. When we quickly label requirements as wants or needs, and quickly sort the requirements under the assumption that needs are obviously more important than wants, we leave unexplored the rich web of beliefs and values that motivates the requirements in the first place. If we act on requirements without testing the underlying beliefs and values, we increase our danger of solving the wrong problem, and of wasting precious time, money, and attention.

What leads us to think of needs as more important than wants? To explain that, I’ll need to describe how I think about wants and needs.

In their noun forms, the words want and value mean the same thing: a condition that we desire. Wants, then, are organized into Value Hierarchies — each want becomes a want precisely because we believe it leads to some other condition that we desire even more. Each want is a means to an end.

I see needs as special kinds of desired conditions — that is, as special kinds of wants. Like other wants, each need is a means to some more important end. What distinguishes needs from other wants is that a need implies necessity, our belief that the means is necessary if we are to achieve the end. If I want to attend a conference in Boston, I need to go to Boston. Given my desire to attend the conference, going to Boston becomes a need.

Not all wants are needs. If I want to go to Boston, I might choose buy an airplane ticket. But I don’t need to buy a plane ticket. I could instead travel to Boston by car or by train. Buying a ticket is a possible means to the end, but not a necessary means. So buying a plane ticket is a want, but not a need.

A need, then, is made up of three elements:

• A deeper value.
• Our belief that satisfying the need will satisfy the deeper value, or contribute to satisfying it.
• Our belief that we can satisfy the deeper value only by satisfying the need.

It’s the third element, the element of necessity, that distinguishes needs from other wants. And it’s that additional element that leads us to consider needs more important than other wants.

So now I’ve shown that needs are more important than wants, right? Well, yes, with important conditions: A need is more important than a want if the value underlying the need is more important than the value underlying the want, and if the beliefs underlying the need are reliable. Those conditions are important. If we lull ourselves into believing that all needs are (obviously) more important than wants, we forget to test the underlying values and beliefs. And sometimes those values and beliefs don’t hold up under scrutiny.

If we’re going to claim that this requirement is more important than that one, we owe it to ourselves to explicitly test the values and beliefs by which we assign the requirements their importance.

What can happen if we choose to leave those beliefs and values tacit? Here’s an example of a time when I focused so much on something I thought I needed that I didn’t bother to ask myself what problem I was solving.

I was writing a conference paper about resistance, and I kept referring to “the person you are asking to change.” I got tired of writing that, and it seemed like an awkward phrase to repeat so often. I tried the word “client,” but that didn’t seem quite right. So I wrote to a group of writer friends, and said, “I need a better word.” They offered lots of ideas, but I wasn’t entirely happy with any of them. (I was happy that nobody suggested the word “target,” a metaphor that I do not want to promote.)

Finally, Jerry Weinberg said, “What’s wrong with ‘person’?”

I tried “person,” and it fit nicely in some places, and awkwardly in others. I was stumped. So I asked myself, “What is wrong with ‘person’? What am I trying to do here? What problem am I trying to solve with a better word?”

As I looked closer at what I was writing, I noticed that the reason I was repeating “the person you are asking to change” so often was that I was trying to avoid the awkward “him or her.” Aha! My real goal was to find words that were both gender-inclusive and graceful. By focusing so intently on my “need” for a better word, I had distracted myself from discovering my real goal, the deeper value. Once I realized that my real goal was to find graceful gender-inclusive terms, I solve the problem easily.

I think you’ll agree that this example is relatively harmless. I wasted a few hours of my time, and perhaps a few hours of my friends’ time. Not a major disaster.

But what if something similar happens on your projects, on your requirements? What if the deeper need behind some “critical” requirement turns out not to be very important after all? What if the requirement will not really satisfy the underlying need? What if there are better ways to satisfy the underlying need? What if you discover these problems only after you spend precious time, money, and attention to implement the requirement?

Don’t let your need to quickly sort requirements distract you from understanding the requirements more fully. Take the time — especially for the requirements that you are sure are “needs” — to test your underlying beliefs and values. What underlying value motivates this requirement? Will implementing this requirement really satisfy the underlying value? What makes us think so? Is this requirement necessary, or might there be simpler, less costly ways to satisfy the underlying need?

Laurent Bossavit’s recent blog entry about stability got me thinking, as his incipient thoughts always do.

What makes stability an issue? Under what conditions would we pay any attention at all to stability? When we care about something that may be threatened by a force acting on it. If we care about a thing, and there are no forces acting to change it, we don’t need to worry about stability. And there’s little point maintaining the stability of something we don’t care about. Stability is an issue only when we care about something that is threatened.

How can we maintain stability? I can think of three general strategies: adapt, isolate, and absorb.

The first strategy is to
adapt the thing you want to stabilize, to modify it so that it now benefits from the forces that previously threatened it. For example, when the United States experienced oil crises in 1973 and 1979, U. S. automobile manufacturers began making smaller, lighter cars with more fuel efficient engines. And when Japanese companies began to export inexpensive, high quality cars to the United States, U. S. manufacturers began to sell foreign-made automobiles under American companies’ brand names.

The second strategy is to
isolate the thing, to separate it from the forces that threaten it. For example, the paint on your car separates the metal from the wind, rain, and salt that can corrode it.

The third strategy is to
absorb the threatening forces, to convert them into a form that is either less harmful or more useful. Then either incorporate the new form or dissipate it. Absorbing is a combination of adapting and isolating. You adapt to the environment so as to better convert or direct the threatening force. And you direct or convert the force so as to separate it from the thing you are trying to stabilize. For example, the shock absorbers and the tires on your car absorb mechanical motion. They convert mechanical motion into heat, a more readily disposable form, then dissipate the heat. For another example, your automobile insurance converts sudden, large expenses that could threaten your financial stability into smaller, more predictable expenses.

Note that each strategy for maintaining stability requires change. In order to keep the important thing stable, we must be willing to change something else, something that is less important. When you buy automobile insurance, you give up something less important, your available funds, in order to maintain something more important, your overall financial stability.

Here’s a question that now intrigues me: How do we decide which strategy or combination of strategies to employ to keep some precious thing stable? Do we adapt to changes when we can, and isolate ourselves only from forces to which we cannot adapt? Or are there some forces that we will try first to isolate ourselves from, and adapt only if isolation fails? What about the nature or value of the thing we’re trying to keep stable? How does that influence our choice of strategy?

One more question: Are there other common strategies for maintaining stability that are not accounted for by adapting, isolating. or absorbing?

Laurent Bossavit asks a great question, “What is the purpose of planning?”. He then gives examples of two of the most common purposes: to facilitate completing the project by some significant date or event, or to facilitate predicting the budget. I like Laurent’s question, and encourage you to ask it before (or during, or after) you engage in any significant planning.

“What is the purpose of planning?” is a form of The Value Question. However you answer the question, whatever your purpose for planning, your answer expresses a belief that planning will achieve that purpose. I want to explore that belief by asking another question: How will planning achieve that purpose? How, for example, will planning help you to complete the project by a significant date? How will planning help you to predict the budget?

Planning helps you do those things by making explicit your thoughts about what resources you will apply and what will happen as a result. Planning exposes your commitments, expectations, and assumptions, and allows you and other people to explore them, to test them, to assess your confidence in them.

Whether your expressed purpose for planning is to help you meet a committed date, or to predict your budget, or some other purpose, planning always has this intermediate purpose: to communicate our present commitments, expectations, and assumptions about the project.

One implication of this purpose is that though planning seems to be about the future, it is, ultimately, entirely about the present, about what we are expecting, assuming, and committing to right now.

Experiment: The next time you plan, make this intermediate purpose explicit: to communicate and examine our present commitments, expectations, and assumptions about the project.

Experiment: If planning is entirely about the present, about the commitments, expectations, and assumptions you hold right now, what information becomes more important to your planning? What information becomes less important?

Experiment: If planning is entirely about the present, how does that affect the way you treat the plan as the project progresses?

Once upon a time, I worked in the IT department of a large company, leading a cross-organizational process development team to define, promote, and support a standard software development process to be used by most IT projects. Like many organizations’ standard development processes, ours was large — it defined about 30 roles, 40 deliverables, and 50 activities organized into seven phases. In trying to make the process comprehensive, we had made it cumbersome.

Project teams complained that the process got in the way, and slowed the projects down. Every few months, one process development team member or another would bring those complaints to our monthly meetings. The first four times this happened, we tried to address the complaints by reviewing the standard process to determine which activities we could remove. Whenever someone recommended an activity that we could remove, someone else immediately explained why we could not safely remove it. We never removed a single activity.

The fifth time someone raised the project teams’ complaints, I decided to try a new approach, an experiment: Rather than starting with our comprehensive process and whittling it down to size, why not work in the other direction?

So I offered a proposal. “I propose that we adopt The Null Process, a brand new process that I’ve invented. The Null Process has no deliverables, no activities, no phases, and no roles. It isn’t possible to define a less burdensome process. The Null Process completely resolves the project teams’ complaints.”

“Now…” I said, “What would keep us from adopting The Null Process? What’s missing? What do we absolutely need that The Null Process lacks?”

My experiment flopped. After a few minutes of silence, someone said, “We absolutely need everything that’s in our standard process. The Null Process lacks all of it.” The rest of the team quickly agreed.

I wasn’t able to make The Null Process work that day. Still, I’m fond of it, and hold out hope that I can use it in the future. The idea of starting from The Null Process and adding only what’s necessary is, I think, a fine one. But I failed to establish a context for the conversation about what’s missing. Next time, before asking “what’s missing,” I’ll ask the team to do some stakeholder analysis. Who are we intending to serve with this process? What needs do we intend to serve for those people? Then we can evaluate how well The Null Process serves those stakeholders, and add only those process elements that are necessary to serve their needs.

Consider replacing each of your processes with The Null Process. I offer it to you royalty free! Adopt a more complex process only if you can identify stakeholders and needs that The Null Process does not satisfy.

Experiment: Establish clear goals for each of your processes. Ask Who will this process serve? and What needs will this process serve for those people?

Experiment: Justify each element of your processes — each role, each activity, each deliverable — by asking Who does this element serve? and What needs does this element serve for those people?

Many software quality attributes are largely about time. People’s time. This is especially true for business systems.

For example, it’s easy to see that response time is about time. What about other quality attributes, such as ease of use or maintainability or availability? To see how these attributes relate to time, we can ask two questions:

• What makes this attribute important?
• How would I observe this attribute?

Grab your favorite software quality taxonomy and play along, testing each attribute with the questions above. If you don’t have a favorite, use one of mine:

• The Software Engineering Institute’s “Quality Attributes” technical report.
• Chapter 19 of Tom Gilb’s
  Principles of Software Engineering Management
  .

For example, how would you observe usability? If you wanted to know whether your software were easy to use, what would you look for? I would watch people using the software, and measure how long it took them to do some task that was important in their work. The key phrase “how long it took them” tells me that usability is at least partly about time.

What makes usability important? When software is hard to use, I have to think more to figure out how to accomplish my goal. I make guesses, and try things. Some things work and some do not. When my attempts don’t work, I have to back them out and try something else. Lots of extra thinking. Lots of extra mouse clicks.

So what? Thinking isn’t hard in a physical sense. Neither is clicking a mouse (up to a point—repetitive stress can do real damage). What makes thinking and clicking “hard” is the time it takes. I prefer easy-to-use software because it helps me do my work faster. Usability is important to me because it saves my time.

Though there is more to usability than this (see Constantine and Lockwood’s
Software for Use
), time is a key element of ease-of-use. The same is true for many other quality attributes. Maintainability, for example, is largely about how much effort (people-time) it takes to repair a defect. Extensibility is about how much effort it takes to add a feature. Portability is about how much effort it takes to move the system to a new environment. What about availability? When a system that I need is not available, it takes longer to do the job.

As with usability, though there is more to these quality attributes than people’s time, time is a key element of each.

I need to remember this when I am negotiating the requirements for a software system, and prioritizing these quality attributes against each other or against schedule and cost. When I trade off one quality attribute for another, and the attribute strongly affects people’s time,
I am trading off one person’s time for another’s.

Whose time are your quality tradeoffs affecting?