Business Requirements Interviews – So much more than a conversation

When kicking off any kind of project, be it implementing an intranet or revamping a business process, the most important stage of the entire project cycle is the business requirements stage. And one of the most productive and useful research methods is the business requirements interview.

Your intranet is good, but you think it could be great with a few changes. But what changes? What improvements and modifications would turn your company’s intranet from an information resource to an essential business tool?

I can’t tell you how many client conversations have started with the statement “We want to improve our intranet.” But when I probe as to which area(s) of their current site needs improvement – all I get is dead-air. They recognise that something is missing, but they just can’t seem to put their finger on what exactly it is that is not there. Or, they have a silo perspective – it is a systems issue, or there is a lack of “insert department name here” specific content. Very rarely do clients have an overall perspective of what each area of their organisation thinks is missing, or needs improvement.

This is when you grab your sleuthing hat and head out into your own corporate maze and do some

. This is how you will unearth what needs to be done to flip your intranet over from being an occasional reference source to indispensable corporate resource.

Setting off down the right path

When kicking off any kind of project, be it implementing an intranet or revamping a business process, the most important stage of the entire project cycle is the business requirements stage. And one of the most productive and useful research methods is the business requirements interview.

Business requirements interviews determine the specifics:

• what the project must ultimately achieve,

• whether those requirements can be met, and

• provide a gap analysis to determine the difference between performance and requirements, (satisfaction versus importance rating).

No doubt that finding the answers to these, and other questions, is important – but it may not be the toughest part of the business requirements collection task. Because before you ask the question, you have to think up the right question. Then you have to find the right people to pose those questions to. This is often where the better part of the work is needed to establish what your business requirements actually are.

Where to start

Questions such as: “Who are the company’s SMEs (subject matter experts)?”, and “What are the organisation’s different stakeholder groups?” – are a good place to start when gathering business requirements.

An old adage dictates that there are usually three sides to a story; his, hers and the truth. Well, when it comes to getting the business story straight there are also usually three sides to the story: the technical side, the business side and management’s side. But unlike the “he said – she said” debates, these three points of view are all valid, and together usually triangulate to find the best case solution for all involved.

If it is a business problem, why go to IT? And conversely, if the project at hand is one based in technology, what could the communications team possible have to contribute? And management, well we all know that all they ever do is tell us is to cut costs and find ways to increase our ROI!

As the analyst, your job is to peel away the layers of techno-speak and jargon from each of these groups to find the underlying common message or problem that needs to be addressed. As well, by dialoguing with representatives from each of these and other areas, we are better able to identify and pull best practices from each. That is why it is vital to the success of any business or technology based project to talk to those outside of the direct scope of work to ensure opportunities for improvement, efficiencies and even increased ROI, are not missed.

A little prep work goes a long way.

Knowing your audience and their area of interest within the business goes a long way to facilitating a fruitful conversation.

1. Learn a bit about those you are talking to and their business before your meeting.
2. Meet with interviewees on their own turf, face-to-face whenever possible.

• This is particularly important when eliciting business requirements and/or expectations from managers or executives. These interviewees will be more candid and forthcoming, and you are more likely to get the true requirements when in private environment.

• Also, keep other interviewees’ opinions to yourself. You are more likely to get at the truth if each interviewee delivers their opinion in an "uncontaminated" state.

1. Send out an email confirming the time and place – include an outline of topics to be covered to all participants.
2. Questions prepared in advance are a great guide for the conversation and as fallback device to ensure key points are covered before ending the session, but responses should guide the flow of the conversation whenever possible.

­Stay focused on the goals of the interview, and steer conversations back on track if you stray too far from core issues.

­Keep to a relatively high level in the interview's early stages. Don't follow an early comment to a very low level of detail, only to run out of time and discover that you haven't discussed three other major areas of responsibility with important requirements for the DW/BI effort.

What to do with all this information

Now that you have information from all aspects of the business it is time to turn on your fact-filter and decipher what is truly key to the task at hand. This is often a good time to turn to the data collected from management and executives, and why it is often prudent to perform this set of interviews last with added questions meant to qualify data collected from other sources. These individuals are often the ones who can see through the clutter, recognize the potential barriers to success and provide guidance to ensure the project deliverables are in line with the overall business plan of the organization.

By focusing on the business requirements, not user requirements during this analysis stage you will be able to identify solid recommendations for the course of the project, and perhaps even pinpoint a few 'quick wins' that can be executed early in the implementation to set the stage for success.