This is such a familiar and tiresome topic in our profession, yet so important, that year after year we keep talking about the same thing and suffering the same consequences over and over again.
Are projects specified properly? Do they start with a sufficiently comprehensive set of requirements? It’s true that in agile software development, we take it for granted that requirements can change—because they do; it’s natural. But they change in response to deliveries, and that’s a good thing: it’s precisely what all the practices and principles of agile address so well.
However, the worst habit in our profession is not knowing how—or not wanting—to put in enough effort to create a proper document listing the requirements or specifications that explain what needs to be done. It’s common sense to make clear what the client wants, isn’t it? And yet…
I’m afraid that often the person responsible for gathering requirements doesn’t know how to do the job. But sometimes it’s simply laziness about talking to the client enough that prevents the project team from understanding more precisely what needs to be built.
There’s a universal law we should always keep in mind:
The more effort you put into specification, the less time you’ll spend developing the project.
It’s obvious—almost silly to say—but in the day-to-day whirlwind of work, meetings, visits, and so on, we often forget this principle.
It’s that simple.
I’m continually surprised that companies devoted entirely to developing and implementing software solutions fail to give this preliminary and essential work—the work needed to produce an accurate, approximate quote—the attention it deserves. Yes, I’m afraid I could tell stories that would make more than a few people pale.
A while ago, I ran a survey with the following question: “Are project timelines estimated correctly?”
Eighty-one percent of respondents selected: “No, estimates are usually short and extremely tight.” Great—just the kind of profession you’d recommend to your children…
How can we estimate timelines if we haven’t properly specified a large portion of what the client needs?
It’s true that after many years of developing products and projects, we can rely somewhat on intuition. But no business can survive on instinct alone, and it wouldn’t be professional to set a client’s price arbitrarily: “Well, let’s charge this one X, give or take.” No, that’s not professional at all. And yet, I’m afraid it often happens that way: by guesswork and in a hurry.
I’ve often discussed the natural consequences of working this way on this blog and in The Programmer’s Black Book: developers with no time to do their work properly and under pressure; angry clients because deadlines aren’t met or because they receive something other than what they asked for; companies losing money; and so on. I’ve also said that clients themselves often prevent you from doing the job properly and put obstacles in your way.
The solution is simple, but like all simple things, it takes discipline and resisting the temptation to take the easy way out: a project shouldn’t move into execution until most of it has been specified in a document. Most importantly, that document must be agreed upon with the client. It doesn’t have to contain formal software requirements; the specification can use the same language the client uses to describe and understand their business. The software requirements can be derived from that later, but this is already enough to produce a more accurate time estimate.
When you think about it, risk management is essential in a company. Isn’t it risky to carry out a project for less than the price you’ll charge for it?
I keep seeing this lack of rigor in specifications, and while I have doubts about many other things—in fact, I tend to question almost everything—no one can convince me otherwise on this point. A project’s successful execution depends enormously on how well it’s specified. It may sound like stating the obvious, but as we know from day-to-day experience, putting it into practice can be difficult. Separately, by applying sound development principles, we can make the project maintainable and able to evolve as new requirements arise.
Sometimes it’s the company’s own sales manager who wants to wrap things up (by passing the ball—or the hot potato—to someone else) and move on.
That’s how things are. Still, a good team or project manager shouldn’t agree to start a new project unless they have a clear understanding of most of the work involved. It’s like asking a builder to build us a house: “How should I build it?” “Well, you know, more or less…”