I am a new PM at a new company. I will be traveling to meet with our customer next week for a requirements gathering meeting. I will be accompanied by a design architect. My company's done business with this customer before but this is a new application for us. I don't want to let anything fall through the cracks. Can anyone suggest any best practices, checklists or templates?
Thanks,
Brian Saving Changes...
Sort By:
Darren KosaPlanning & Controls ContractorHampshire, United Kingdom
Hi Brian,
Not to put too much pressure on you, but it’s imperative that you gain a thorough understanding of what the customer needs and wants (explicit as well as implied) and what they don’t want. You’re focus should not only be on the technical solution but also their business environment / drivers / issues / etc.
Tom Barnett wrote a very good article last year “Did You Say What I Think You Said?”. Have a look and see if it helps. There are also reams of useful information / checklists on gantthead that cover requirements management / gathering, just search for 'requirements' and you’ll probably get more than you’ll need.
Good hunting and don't forget the derived requirements as well!!
If you have time to read some books, take a look at Karl Wiegers' stuff on requirements management. He has some great books on the topic:
* Software Requirements, 2nd Ed.
* More About Software Requirements
You will never find a quick fix for requirements that is truly effective, but these are great books. They not only address how to gather requirements and interviewing techniques, but also managing the requirements through the whole development lifecycle. Traceability of requirements is particularly difficult, and you should start thinking about that right now, not later.
You may also want to look up the IIBA, a professional society for business analysts. I am not a member, but I have heard good things about the group from friends who are business analysts.
If you have the budget, I strongly recommend considering hiring someone to be a dedicated business analyst, either as an employee or as a contractor. If the project is highly critical, it is worthwhile to have someone with experience in this area. You can pick up some good tips in a week, but you will never be able to master the discipline that quickly. Saving Changes...
Richard HowProgramme Management Consultant| How Associates LtdHarthill, South Yorkshire, United Kingdom
the biggest tip I can give you is assume nothing. Walk through what they want to do end to end note specific requirements on flip charts , white boards or whatever is your preference. Always have a list of items that are specifically out of scope, never assume they do or dont want something. eg if designing a mobile phone you may assume the client already has a sim card they may assume you are suppling one as the phone wont work without one. That simple assumption means you deliver a product they cannot use.
On many of the projects I have worked on the out of scope list has been as important as the requirements list.
Once you believe you have gathered all the requirements get them documented and if possible circulated to a wider audience than the attendees of the requirements meeting. These extra people will often highlight huge gaps in the document because you have made assumptions based on conversations in the meeting.
my last tip would be always walk through the system requirements in a logical fashion, start with what goes in track through all the things they want to do with it and then what comes out and what it is used for, that way hopefully you wont miss anything. Saving Changes...
I suggest starting with the aim and objectives first. Then define the scope and next move into requirements. Doing this will save a whole lot of time as you can use the scope to determine what requirements you do and don't need to discuss. It's no use discussing everything on the wishlist only to find out they don't have that sort of money or require something within x months.
When you are ready to gather requirements, start with the processes that will be used for the solution. These cover both customer processes and operational or business processes.
The customer processes include what the customer does eg. browses a site or add an item to a cart or calls into a call centre.
The operational processes include what is needed to support what the customers is doing or has done. eg, pick and pack there order, update the system and ship it out.
Make sure you start with how the processes working perfectly and then go back and add in all the exceptions. eg, what happends if the items requested are out of stock, their credit card is declined or the customer service person can't find the order etc.
From here you will be able to define requirements that support each item in the process flows.
This should provide clear alignment across the board in getting a solid set of requirements that are traceable and testable.
"Life is but a walking shadow,
a poor player that struts and
frets his hour upon the stage
and then is heard of no more.
It is a tale told by an idiot,
full of sound and fury,
signifying nothing."
