Developer

Don't let the requirements gathering process imply deliverables

Projects often fail because of the way you ask customers what they want you to deliver. Find out when to keep your mouth shut and what questions to ask customers when you do speak up in order to make the project a success.

After reading Paul Glen's good article "Project managers: Stop 'gathering' IT requirements," I took a trip down memory lane and thought back to all of the projects I have been on where the delivered product did not meet the customer's expectations. Sadly, it was too long of a trip. One thing that most of the projects had in common was a "requirements gathering" process. The problem with "gathering requirements" goes far beyond the difficulty in doing so accurately, as Mr. Glen's article discusses. A major part of the problem is that the very act of "gathering requirements" implies a list of deliverables.

We are all familiar with the phrase "over-promised and under-delivered," which is an accurate summary of many failed projects. In IT, we are always trying to do the opposite: under-promise and over-deliver. So how do our customers come to believe that we promised something that we did not? Simple: It is in the way we ask them what we want.

Think back to some of your failed projects. How many of them started with a bang? Maybe a little pizza party to kick off the project? Afterwards, the BAs, the PMs, and some of the developers "gather requirements" from the customers and end users, asking questions that amount to, "What do you want?" And in the spirit of being cooperative IT people (not the evil IT people who throw up barriers to the customers), we were all ears, very attentive, nodding our heads, and taking notes. Maybe we even got a little carried away and came up with some ideas, springboarding off of what the customer says, like, "Wow, that's a great idea, and once we have that data, we can produce some really slick reports!" We sure were nice folks during that process, weren't we? So friendly and so willing to offer up good ideas.

Let's take a look at it from the customer's perspective, using Christmas presents as a metaphor. Imagine being 8 years old again, and your parents ask you what you want Santa Claus to bring you. "I just want a toy fire truck, and if Santa doesn't bring anything else, I would be happy with that!" you tell them. Your mom says, "A fire truck? If you get a fire truck, you would definitely need a firedog to go with it!" Dad is getting excited too. He says, "I bet I could build a great firehouse out of some lumber too!" Now your motor is really going, so you say, "That sounds great, and instead of a toy firedog, could it be a real puppy?" Mom and dad, caught up in the spirit of wanting to please their child, nod their heads "yes." Now it is Christmas morning, and not only do you expect a toy fire truck under the tree, but you are eagerly anticipating a handmade firehouse and a Dalmatian puppy too. When all you get is a fire truck, you get mad. Mom and dad ask you what is wrong, and when you tell them, they say, "But you said that you would be happy with a fire truck!"

This is why "gathering requirements" can be so deadly to a project. The very process itself carries implicit promises of the work that will actually be done. After all, isn't it fair that if the customer has clearly stated what they want that they should get it? That sure is how it is in the customer's mind, at least.

There is a way around this. It requires the BAs to actually analyze the business, the PMs to actually manage the project, and the developers to keep their mouths firmly shut during the customer facing part of the process. The way it works is you do not ask, "What do you want?" or even "What do you need?" Instead, you ask, "How do you currently perform the tasks that you are doing now?" Another good question is, "What makes no sense about the way you do things now, and what works well?" "Can you provide us with a flowchart of this process?" is extremely helpful too; you will find that many customers do not even know their own process, which is one major source of last-minute changes and post-delivery disappointment.

After asking these kinds of questions, the IT team heads back to their desks and comes up with a project spec that does what the customer needs it to do — within the realm of what is actually able to be delivered with the resources available (time, manpower, budget, etc.). At that point, you bring it to the customer and ask, "Does this meet your needs?"

I have done this on a number of projects, and the difference is night and day. The customers are usually delighted with the results. After all, you listened closely to what they needed and provided something that met their needs. Along the way, you may have added some extra goodies that they didn't expect or even think of. Best of all, no deliverables were even hinted at (let alone implied or promised) until the spec was shown to them, and the spec was drawn up taking into account the business constraints. I have never disappointed a customer using this technique, and I hope that it is useful for you as well.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides.

———————————————————————————————————————————-

Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!

About

Justin James is the Lead Architect for Conigent.

Editor's Picks