Over the years, I’ve come to the conclusion that one of the most destructive notions circulating inside technical groups involves “gathering requirements”. So now that our success rate for IT projects has risen to the still-dismal level of about 25 per cent, perhaps we should question some of this time-honoured wisdom.
As I travel to consulting and speaking engagements, I often ask, “What are the main causes of project failure?” And invariably one of the first answers is something like: “There’s a failure to gather good requirements.”
The problem with gathering requirements is right there in the word gathering. What images does it conjure? For me, it’s an image of a harvest, of a group of people standing among endless rows of vines picking ripened grapes and carefully placing the bunches in a bin. For others, it might be an image of a child collecting seashells on the beach or of a group of people huddled together at a town meeting. What’s common in all these images of gathering is that there’s something out there to be collected like crops, shells or people, and that those things are already whole and complete. Of course, this is ridiculous. Requirements don’t exist out in the ether just waiting to be discovered. They aren’t out there whole and finished. Clients and users aren’t playing an expensive game of hide-and-seek with us. Usually, the clients’ pockets are empty. Most of the time, they don’t exactly know what they require. And even if they do, it’s in the form of incomplete and inconsistent ideas that can be only partially articulated. Projects rarely start out with clear objectives or requirements; they begin in confusion and ambiguity.
The other problem with gathering requirements is that it suggests subservience or disinterested passivity on the part of the IT group. It gives the impression that the job of a technical team is to take orders like a waiter who couldn’t care less what you eat and then deliver the cooked meal. Technical teams with this attitude rarely deliver high-quality service.
So what’s the alternative? Obviously, projects need solid requirements on which to build technology.
We should think of a set of requirements as being like a multilateral treaty among a group of nations. Representatives of nations negotiate treaties by seeking out points of agreement, acknowledging constraints, compromising and trading off. The forging of a treaty is an active and difficult process of creation. No one would suggest that you “gather paragraphs” to write a treaty.
So we must negotiate requirements among the many stakeholders whose positions and interests need to be acknowledged. There are the business interests of executives who fund projects, of course. There are the utility needs of the users who will work with the systems every day. There are also the technical needs of those who build, deploy and support those systems. The list can go on and on.
Successful projects begin not with a harvest, but with a difficult set of discussions on what should be done. If you stop trying to gather requirements and start negotiating them, your projects will yield richer crops.
Paul Glen is the author of Leading Geeks: How to Manage and Lead the People Who Deliver Technology (Jossey-Bass Pfeiffer, 2002) and principal of C2 Consulting