Apps

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.

15 comments
chris
chris

and vice versa. The kinds of things you talked about in the article is really closer to a feature list. I know I'm being a bit..."specific", but as a programmer, you learn how important that can be :-)

rthb
rthb

how to quote a price for time and resource in doing a spec?

mikifinaz1
mikifinaz1

Get a list of deliverables. Tight and black and white

Justin James
Justin James

In my mind, one of the biggest dangers is making promises (direct or implied) to the customer before you have actually written a spec. What do you do to keep this from happening? J.Ja

Justin James
Justin James

But users don't know the difference. They think that just because they said, "it needs to do XYZ" that it *will*, and it will be seamless, intuitive, robust, scalable, and transpaent. And a Web service that they can tell their other vendors to hook into. And make funnel cake & sausage dogs so you can pretend the state fair is in town all year long. :) J.Ja

Justin James
Justin James

Something like 70% of IT projects are behind schedule, not what the customer wanted, or over budget. Clearly, getting these things right is still a mystery. :) Personally, on a medium project (say, something that would take a 3 - 5 person team 6 months or less to complete), I can guestimate to within a few weeks, as long as some flexibility on deliverables is allowed. On a small project (just myself, 6 weeks or less in duration) I can nail it to about 5% on time. Both of these scenarios involve the customer accepting my timeline with no consideration for their needs or wants, which means that I can put enough padding in to ensure that we hit the mark, assuming that no one gets hit by a bus. As soon as the customer demands input into the timelines, I can't estimate a thing. What's my secret? Being around long enough to get a "feel" for what kinds of features will take how much time. I can get a lot more accurate if we are already familiar with the data model, and even more accurate if we already have data-to-objects stuff in place or a data layer already written. There are no rules on this, other than experience. J.Ja

chris
chris

but when you are out in the marketplace, you gotta stay customer oriented and not drakonian.

Justin James
Justin James

... by the time you get an accurate list of deliverables, it is usually too late. Customers so rarely know what they actually want, let alone what they actually need... J.Ja

chris
chris

The only way, in today's faster paced cycles is to remain flexible about the whole thing. Lot of dry run testing (workflow stuff) where you explain specifically what this thing does and also what it does NOT do. I find the not do part far more effective in getting a good response. EG: So, you're telling me you want this button to do 'X'. That means that this will happen AND this is not going to happen, correct? They always go "hmmmmm".

flmagman
flmagman

Justin, this sounds as if you are just replacing an existing process, or automating it, and not coming up with some new requirement where the customer definitely says, 'this is what I need it to do, in addition to what we already do.' In that case, I sometimes find the customer hasn't completely thought the process through, and it helps to ask questions on how they intend to use the data or the results, since from an IT perspective I can bring up problems or possible roadblocks ahead of time. Some time during this process the dreaded question may come out, 'What do you actually need?'

Justin James
Justin James

I am becoming more and more of a convert to Agile. A lot of the Agile stuff I hear is overhyped nonsense, but the core concept is solid. I've never been able to get a truly "complete" and accurate spec for any project that was longer than a week or two in duration anyways, so what makes me think that I can figure it all out before hand and spend 18 months coding to that? J.Ja

Justin James
Justin James

There are extraordinarily few software projects that are not automating an existing process. :) You are right about the questions to ask. Customers have *never* fully thought out questions. I love Visio diagrams from the customers that show a "cradle to grave" process flow, and have huge gaps or "islands" that cannot be reached from anywhere. J.Ja

Tig2
Tig2

I get the business to sign off on the Change process at the start of the project. In bright purple ink. Then I hold them to it. One of the other things that they have to agree to is that they will not interact with my team without me present. If they won't sign off on that (again in purple ink) I won't take the project. If I am the PM, requests flow through me. It is my responsibility to keep the team on track and I can't do that if business is busily de-railing the effort.

Justin James
Justin James

I've written that into specs myself, usually as a comment that indicates a lack of information. I've tried making the change order process so painful that no one asks for changes, instead, they just change the change process... :) J.Ja

Tig2
Tig2

*then magic happens* And yes, I have actually seen that commented into the code. I level set at the beginning of the requirements discussion that our first sessions are about understanding what they think they want, the next are about what can be done, and the third are about what we will DO. Until that third meeting where the requirements are signed by the business, there is only pie in the sky. I also set the expectation that any Change Order will be estimated as separate work. That keeps us all thinking at granular levels because I don't like Change Orders. If business is also thinking that, we get better requirements. Finally, in the requirements phase, I make certain that I am talking to the end users to insure I understand how they interact with whatever the current tool or process is and to understand what their real needs are versus what business thinks they are. Can I make this work every single time? Alas, no. But it gets me closer to delivering what is needed as opposed to what is asked for.

Editor's Picks