“You will be the on-site consultant for this project” are words that some cherish while others dread to hear. Nevertheless, for a Business Analyst, it is inevitable that sooner or later this opportunity presents itself. It is an accepted fact that today, the role of a Business Analyst has diversified to include, among other activities, document creation, facilitating meetings, approving plans, developing processes, building customer relations and even making lunch for the team.
But in-spite of the enhanced responsibilities, the inherent problems tormenting ERP implementation still exist. The stabilization time required for a major implementation is a concern. During this period, processes that were documented as ‘plans’ start taking shape, causing unfamiliarity and problems with the quality of work. Business performance is often claimed to take a dip as the system does not operate as it was hoped. Signs of customer frustration start creeping in where the customer feels that the solution doesn’t work as expected. Though the usual culprit is a lack of in-depth user training at the right time, often the underlying reasons might be a failure or oversight to partially understand the user requirements. So what can be done to avoid this?
Best practices to follow during Requirements Elicitation
Naturally, among the first things to do is to equip ourselves with all the available tools for requirements elicitation. Preparing the questionnaires, scheduling customer interviews, brainstorming sessions, gathering information on similar projects are amongst the usual practices. However a look at a few additional techniques that are probably overlooked would add value:
- Go through the Requests for Proposals (RFPs): This is one document that is usually neglected afteran initial glance. While it may not give a detailed account of the customer’s needs immediately, itpays in the long run to compare it against the application to determine the trend of the customer’s needs.
- Go through the Contract or Statement of Work (SOW): It is inevitable that there will be a contract with the customer that states in broad terms, the terms and conditions along with a Statement of Work that describes features & functions that shall be made available. While this cannot be readily translated as requirements, it can be used to define the boundaries within which the scope of developments must lie.
- Have a Brainstorming or JAD session with the offshore team / Other Project teams: Requirements in many projects are “Discovered” rather than “Uncovered”. State the obvious challenges and potential issues based on the Statement of Work and invite the discussions to flow through.Encouraging the group to come out with their ideas on solution leads to a plethora of ideas previously used. While not everything might be practical, it gives an idea on which requirement to be discarded first to accommodate your budget.
- Understand the roles of Customer representatives / Key users: Often the nominated master users are either the supervisors or people who are not directly involved in the day to day activities (They are the ones supposed to have the time..!). Thus people tend to specify a requirement based on what they know or think they know; rather than the actual business need. Though not wrong, it is important to get a different perspective independently from people who work hands on.
- Visit the actual workplace and follow the users as they go about their daily work: While this may not seem to be a comfortable idea, it is a helpful technique to validate the current processes being followed and could also provide valuable insights on certain overlooked facts. One should understand that people usually have a hard time explaining their daily routine in detail. At the same time, care should be taken not to make it a time consuming exercise since the Business Analyst has to be interested in only a specific subset of the end user’s job.
- Obtain in advance and go through the MPD/AMM/MOE: It definitely pays to get these documents in advance from the customers and to analyze them for schedules, intervals and special inspection checks. Such information forms the crux for migration and subsequent setup of data.
One good practice is to follow-up with a detailed, written account of what was discussed in the meeting. Whatever methods are used for elicitation, it is important to the success of the requirements gathering effort that the analyst understands the overall business picture and can relate how the specific project objectives support or fit in with the business.
