Every project begins the same way, a loosely defined requirement provided to a team. The team may be Information Technology or Employee Relations, or Operations or any other department. What happens next though, is the first opportunity for success or failure of the project or initiative. Requirements gathering. This process can either be frustrating for all involved or productive and rewarding. It can either be the first point at which the project failed or the start of its excellence. How can we make sure it is the latter? By mastering the art and the science of requirements gathering.
Requirements gathering cannot be reduced just to a science. It necessitates artful communication skills (in particular empathetic listening), excellent technical understanding, non-threatening demeanor and skill in asking the right questions. So how does one begin the art?
First, requirements are best gathered in as personal a setting as possible. Discuss requirements in person with as few people present as possible (use discernment you also want everyone necessary to be present). Additionally, circumstances may prevent meeting in person, however doing so is the best possible standard. While your aim is business, it is best to put the person(s) you are working with at ease. This is important because the probing questions you will need to ask may reveal things that they have not considered. They may not have thought through all the implications of the request. Many a requestor has been embarrassed, or even angered at such an exposure. This is why creating an environment of trust is so critical. I often start off by saying it is my job to “lift the rock and note all of the critters living beneath”. Any effort to put your customer at ease will be worth the investment. Ultimately you and your customer have the same goal to make sure that the business gets what it needs as quickly and cost effectively as possible. Inevitably, if you and your customer see each other as adversaries and not partners, the chances of reaching your shared goals go down significantly. And what is more, while you may get the desired results despite an adversarial approach, you want to achieve great results, because of your efforts not in spite of them.
Next, now that you have set the right setting and tone for requirements gathering you must set expectations. Be sure that your client knows what they can expect from you, but also what they can’t expect. This is especially important if you have proficiency in the area where they need help, but not responsibility and/or authority. This may seem obvious, but often while requirements are being reviewed or approved, the client may be fuming because there appears to be no progress on their endeavor. Make clear that you are there to determine exactly what they need. Try to reassure them that everyone in their position will have some things that they haven’t thought of. Your job is to make sure that collectively you capture what is needed and not necessarily just what they said initially. You will of course need to insert any additional expectations specific to your organization such as whether they can expect documentation back from you, someone else, etc. If they should expect documentation as a result of your meeting, let them know at this point. At the conclusion of the meeting provide an ECD for the deliverable or next step. If possible or appropriate, explain the next steps that come after you have finished your part of the effort. This is an investment as much for you client as for your teammates to whom you will be handing off a prepared client.
You may have noticed that I’ve used the terms requestor, client and customer interchangeably. This is important as the way you view your partner(s) in requirements gathering will affect the output. For example, let’s imagine that you are an HVAC contractor and a customer requests a new HVAC system be installed in their 100 year old home. Surely you would not deliver an HVAC system that has power, a fuel source, and no duct work. No one would be satisfied with that kind of service. Similarly, you don’t want “obvious” connection points in the business to be missed because it wasn’t precisely what the requestor asked for. Keeping the “customer” mindset will help you remember that no matter how difficult the person or team requesting assistance may be, it is your job to be the “bigger person”, it’s your job to “take the hit for the team”. In time, this approach will pay off and will help you and your team to build a reputation for excellent delivery, and from a bigger picture perspective, will contribute to your organization getting big wins.
Armed with all that preliminary work, comes the more technical aspect of the process. Though your primary concern needs to be keeping your client on the same page with you, you cannot neglect the technical aspect of your job. The first thing to determine is what the client is asking for. Resist the urge to branch out into other areas too quickly. Instead, focus strictly on what they say they need. Notice a brief scenario below
At a medical supply company, the RAQA department needs to halt production whenever a particular error is detected for a customer who has had a recent complaint. In this scenario, our Quality teammate is named Bill and our requirements gatherer is named Mary.
Mary: Now that we have established the expectations Bill, could you explain briefly what you are looking for?
Bill: Well, City Central Hospital has issued several complaints recently for particulates found in their product. I need to be able to stop the production line as soon as such an error is detected.
Mary: Ok. How is this detected on the production line?
Bill: Several ways, it may be noticed by an individual operator, or by the line inspector who reviews each item before it is wrapped and sealed.
Mary: What should happen once the line is stopped?
Bill: Well, I need to be notified immediately.
Mary: Ok, I’ve got that down, how do you want to be notified?
Bill: Via email
Mary: Is there anything else that needs to happen
Mary: How will the line be cleared to start again
As you can see in the above example, Mary’s non-threatening questions have helped her begin to frame what Bill really needs. This will allow her to get to the heart and write a reasonably complete specification. We will touch on why we describe the specification as only reasonably complete shortly. Another word of caution, don’t be afraid to ask “dumb” questions. It is better to ask a question you “should” know the answer to than to make a wrong assumption unnecessarily. Additionally, if you prove yourself to be comfortable asking a “dumb” question, your client will likely be more open as well.
Do not be satisfied with just surface answers. Dig down deep into the details until you have a clear mental picture of what the client wants. Remember, your job at this point is not to shoot down unrealistic expectations or to design a solution. This is the first reason why we should only expect a reasonably complete requirement as an output from your original requirements discussion. Subsequent discussions will help to flesh out the details and may temper unrealistic expectations.
As tempting as it might be, do not assume you are finished at the conclusion of the requirements gathering meeting. Very often, once you put the requirements on paper elements that you or the client did not realize were needed will be missing. Alternatively, putting the requirements on paper may reveal additional questions you need answers to in order to pass along a completed specification for the design/execution steps of the process. Finally, the client may not understand the way requirements are written in order to approve them. I write one version of a requirements with the technical team that follows me as the audience. As a result, there may be technical terms, assumptions, etc. that will be unfamiliar or even confusing to the client. To prevent confusion at this critical juncture, I provide the requirements document in writing to the client and then schedule a brief meeting to review and discuss any questions. If this meeting goes perfectly, you will walk away with a signed off requirement. (Without a sign off, it as if you have done nothing. Make sure you get official buy in with a sign off.) If it doesn’t go perfectly, and most won’t, revise the document in the meeting or afterward and repeat the process as many times as needed in order to get a final specification.
The foregoing is of course written from a software development perspective, but the principles can be applied to many different work streams. Like any art, there are many potential approaches, this one works for me, but like any artist, be hungry to learn new techniques!
NOTE: While I did not cover the design process, it may on more than one occasion lead back to the requirements process if portions of the requirement are not approved or are technically not feasible.