Requirements Gathering: Asking the Right Questions

Posted in: Blog, Project Delivery | Jan 16, 2013 at 8:36 AM

No comments

INTRODUCTION

I’ve talked a lot about starting a project with gathering requirements. In fact, in my series: How to Deliver a Successful Project, gathering requirements is THE key to a successful project. The problem that I’ve often experienced though, the requirements gathering session itself can turn into a boring, going-around-the-circle sort of session. In this article I would like to share with you few tips that can help you executing an efficient, straight-to-the-point requirements gathering session which in the end resulting in an understanding which you can then map to a Business Requirements document.

Now, imagine a scenario. A client (let’s say the name is ABC) just called you because they have heard about your company and how your company has delivered an excellent work for an another client which happened to be ABC’s supplier. ABC is now interested in talking to you for a new solution to the problem/inefficiency that they are currently facing. You and them set up a time to meet and here it was, you and their IT manager sat together to discuss about what it is that ABC is looking for.

So here are few tips that I normally take during a requirements gathering:

Don’t start by jumping straight into the questions about work

There is always a temptation of jumping straight into asking about the work itself. But I’ve learnt that this is a great opportunity to build a relationship with the client. I always start with, “Well, how’s things? What’s your role in the company? How long have you been here?, etc”. The key is to be a good listener. You’ll never know if he/she is currently under pressure and needs someone who can listen?

Ask about the goal of the engagement

Then ask about the end game ie. the goal of the engagement. My question is something like, “What is it that I can help you with?”. This will guide him to tell you what sort of solution they will need. The answer is normally something like, “Well, we need a website” or “We need a portal to share documents”, etc.

Be a good listener, stick to the point 

There is always a temptation of pouring into your client of what you know eg. “Oh if you need a portal then we’ll have the latest news on the homepage, then rotating banner, then this and that”. From my experience, the requirements gathering session is all about the client and not you.

You may argue that by introducing all these extra functionalities, they may help the client. But my question to you is, is that really what they want though? If we are not careful, the session can turn into an going-around-the-circle thing because you are moving the goal post further away. Stick to the point, that is: “what the client wants”.

What if the client doesn’t know exactly what they want? Well from my experience, unless he/she is crazy, he wouldn’t say to you, “You know what…I just want you to come in and meet with us. We still don’t know yet what we are going to talk about but just come in first and talk”. It’s just crazy to invite a consultant to meet and yet being totally blank. When someone invites me in 100% of the time they already know what they want. They just often don’t know how to get there.

My requirements gathering session never goes over 1 hour. Any meeting that goes more than 1 hour will turn into a boring meeting.

Talk about your solution and what it requires and ask what the client can provide

For example, if the answer is, “We need a website”, then your next question is, “Ah, we have a CMS solution that allows you to update content, upload images images, etc yourself”. But I then need to discuss with you the sitemap of the site. What about the branding and design? Have you got it? Also, do you have an environment to support ie. the web server and the database server? How about hosting? etc etc.

If they can’t provide you with answers that can satisfy your solution’s requirements (eg. sitemap for website, metadata for SharePoint, etc) then you unfortunately have to go back on an another day to discuss about it. Give them few questions to take home which you need the answers for.

The key is to keep following up with the client. Make your client feel as if you are prioritising their need. Follow them up in few days time and don’t leave them in limbo.

Fill in the gap

You are the expert who knows about the solution you are offering and you know what is required to make sure that the application is running correctly. Therefore, you then need to fill in the gap. For example, if the client says, “Well we haven’t got any server to host SharePoint”. Then your next statement will be, “So we’ll need a SharePoint Server to be setup. We can assist you with that. We have an industry best practice guidance that we normally follow”.

Confirm scope and deliverables

Now that you have understood what is required and what is missing (ie. the gap), you can now confirm the scope. At this point I would normally say something like, “OK so what I’ve got so far, you need a website but you also haven’t had the environment to host it on. So what we need to do first is to configure the environment.”

“What I normally suggest is to build a UAT and Production environment so that if there are changes that need to be made to the Production environment, they can first be tested. So, based on this I will divide the engagement into 2 phases: The first one is the configuration of the environments and the second is the actual work of building the website itself. Is that OK?”.

“So I’m going to get back to my office now and document all these in a Business Requirements document and a Proposal (that contains the effort required ie. how long it’s going to take) then I’ll submit to you for review. The engagement starts when you sign that document. Is that OK?”.

A lot of the times, at this point, the client will ask, “So how long is it going to take roughly?”. Your answer should be, “Well, again I need to analyse all these in details and get back to you with a proper quote. But if you ask for a ballpark, it is going to be about at least 80 hours worth of work”.

It has always been my principal to NEVER promise any dates or effort unless I am sure of it. That word “at least” indicates that the estimate may and will change. The very last thing you want is for the client to take your word for it and write down what you said. Now that he’s got a record, you will be in trouble. That is why I never promise any exact dates or effort during this session!

What I can promise however is the date when I’m going to get back to them with the Business Requirements and Proposal document.

Draw business requirements and proposal and get back to the client timely

Now that I have already got all the information I can go back to my office start developing Business Requirements and Proposal document.

Download the template for FREE!

Make sure you deliver these documents by the  promised date. I have been in an IT consulting company before where the director was always late (sometimes by a month) in returning these documents. This will only make you look unprofessional and not prioritising the client.

CONCLUSION

A requirements gathering session should not be difficult as long as you ask the right questions. It should never go for more than an hour.

No Comments Yet.