4 Methods of Elicitation (Gathering Information)
There are a number of elicitation methods described here. You don’t have to limit yourself to just one method, and you don’t have to limit yourself to only the ones mentioned here. These are all just suggestions and styles. The only real rule is: Use whatever works.
4.1. Existing Business Process Documentation (if you’re lucky)
If you’re particularly luck, meaning if management is particularly good at their job, then there will be existing business process documentation, and any existing computer code will be well documented, externally (as in design artifacts such as specifications, designs, as-built documentation, and manuals) and internally (as in meaningful comments and names). Always ask for these documents first, because it can save you an immense amount of time. But, beware, it may be out of date or incomplete.
4.2. Discussion Groups
Discussion groups are generally considered a very informal way to get things done. It can help to have muffins and tea available, or something similar to break the ice. Everyone should generally be encouraged to speak up, without taking turns if the group is well behaved in that manner. Just the same, at least one person should be taking notes, and the sessions should be recorded when feasible.
4.3. Interviews
Interviews are the more formal approach. It can be one on one (the typical method), or there can be multiple interviewers or multiple interviewees at one time. In a more formal interview, you’ll generally have some questions written down or in mind before the interview starts. Again, keeping notes and/or recording is best. One on one interviews are also appropriate if and when you don’t want one person’s answers to your questions tainting what another might say.
4.4. Try it on Sample Groups
Very often, you or someone else will come up with an idea and think “let’s put this in the project”. Is it a good idea or a bad idea? One way to find out is to produce a prototype of the thing. Maybe a picture. Maybe something that sort-of works. Maybe a few versions of something that actually does work. A development organization can try various concepts on groups of people and see how they work out. If you’re trying something on a customer group, the question is usually “do they like it?”. If you’re trying something on an internal group, the question is usually “is it more accurate?” or “is it faster to use?”.
4.5. Tribal Knowledge
Business processes should be documented, but often they’re not. Certain people know things. People tell others how to get things done, but never seem to get around to writing them down. Or, the knowledge might be written down somewhere, but knowledge of where is little known, and only by word of mouth. Those are the cases that are called “tribal knowledge”. It will often be your job to be the “archeologist” or the “anthropologies”. Be aware that there may be multiple “tribes”, in that one group may not know how the other group gets things done, and that these “tribes” may in some manner be in competition with one another, even if they work for the same company.
In such cases, optimally your work product will be both documentation of the existing policies & procedures, and of the new requirements. You may be able to find out who knows what, and be able to get them to document it, or you may have to do a lot of detective work on your own. The “tribe” may be cooperative, but they may also be very protective of their secrets.
4.6. Questionnaires
The simplest form of questionnaire simply asks “What do you think we need?”, More pointed (and useful) questionnaires will ask some “closed” questions, such as a question that has a numeric answer, questions with yes/no answers, and questions with multiple-choice answers, but also open-ended questions, such as “What else do we need?”, “Is there anything we should avoid?”, “Is there anything that’s obsolete that should be removed?”, and “Are there any business processes you’d like to be streamlined?”.
4.7. Observation
Direct observation of what’s going on is often the best way to gather information when the job is to streamline or automate current processes. Below, we detail some observation methods.
4.7.1. Individuals’ Work
One of the best paths to process improvement and requirements gathering is to observe someone work, as closely as possible. Doing so will allow you to see what really happens, not what the worker remembers happening. Direct observation also allows you to do timing, and to ask why certain things are happening or why they are being done. You will often see that a person is going through too many steps to do something. These sorts of scenarios happens a lot:
The worker does some task (which they asked you to automate), and then does some second task (which they may or may not have asked you to automate. If you ask how often Task B follows Task A, the answer is “always”. In this sort of case, you want to automate the combined AB task as a single thing, typically.
Someone will pull data from System A and enter it into System B. This is a special case of the above. These two systems should have an automatic way of handling things.
Sometimes you may see some sort of work being done with no apparent purpose. If the reason for some task or action is not obvious, ask why. If the answer seems hard to believe, check it out; you may just find that one or more steps is completely useless, and amounts purely to “tribal custom”, “inertia”, or “historical relics”. Although in this case you don’t get to document any requirements, bear in mind that as a business analyst, this sort of process improvement (elimination of work), goes straight to the company’s bottom line.
It is even possible that you will find out that words that you thought meant one thing can mean another. In the worst case scenario, one worker had said in an interview that she had cut and pasted certain data from three spreadsheets onto a new spreadsheet on a monthly basis. Upon observation, she was seen to do this cutting and pasting with actual scissors and paste.
4.7.2. Listen to the Coworkers Talk
If the company has an open seating arrangement, you’ll hear some chatter between the workers. Listen to that chatter. If they’re asking each other questions, then they need those answers. If they’re asking each other to do things, then they need to have the ability to do those things, or they need a situation in which those things are done automatically, or in which they don’t need to be done at all.
4.8. Do the Job
Taking over someone’s job, for a day, or even for a few hours, or just being trained to do their job, can give you a great insight into the job. For instance, for one business analyst and code analyst role at Northrup, the new analysts were first trained how to rivet and how to QA (perform quality assurance on) the riveting job.
4.9. Process Improvement
The best you can do as a business analyst is to simplify the processes the business goes through. If you can cut out steps, make the process faster, cheaper, more reliable, or in some way better, with or without that affecting the requirements document, do it.
4.9.1. Ask Why
If you’re not 100% sure why something is happening or whether that thing should happen, ask why. If you’re not 100% certain that the answer is correct, ask someone else too.
4.9.2. Cutting out Steps
Look for steps that can be left out or combined. This can happen three ways. First, if the result of a step is not used, or is not useful, get rid of the step. You may even find that you’ll cut out two or more steps with one action. For instance, if you cut out a step that produces a useless report, you also cut out the distribution and reading of the report. Second, if a step can be simplified, then you’re ahead. If two or more steps can be combined, then you’re effectively one or more steps ahead in the process. Cutting steps out may take modifications to the procedure manuals (and/or web-sites or SharePoint documentation), telling people what you’ve discovered, and/or retraining people. Combining or altering steps, of course, means that requirements — additions and/or changes — will go into the requirements document.
4.9.3. Special Case: Excel
In the business world, Microsoft Excel seems to be a special case. The program is great at what it’s designed to do, but people seem to find a lot of uses for Excel that it’s not good at. Any time an Excel sheet comes out of a program, be suspicious. Here are a number of ways in which Excel is abused:
Sometimes Excel is used as a transfer mechanism. People download their data from System A into Excel, and then upload that same data to System B. In all such cases, even and especially if some data transformation is being done, all such data movement and transformation should be automatic, either on manual demand (such as from a button or menu item), or scheduled (optimal when possible, since scheduled items happen exactly when they’re supposed to, whether remembered or not).
Often someone will pull (download) data into or as an Excel file, and then add calculations into that spreadsheet. If that person is doing one-up work (work that will only be done once), then that person is using Excel as designed. But, if the process is going to be repeated, then the work should be moved into the applications layer or into the database layer, as appropriate.
Reports generated by a computer system should be generated in a read-only manner. There is a big tendency in some organizations to pull a report in Excel format, and then to manipulate the data. Generally, in this sort of situation, the report is output as an Excel file, complete with active formulas. People will then adjust numbers, and the totals and other calculations are automatically adjusted by Excel. There are two problems in this scenario. First, the reports themselves become unreliable, in that it becomes hard to tell if the report was generated by the system or by hand (and even one cell changed by hand makes the entire report count as having been done by hand). Second, likely data that should have been entered into the system is not entered into the system, and the system continues to have errant or inadequate data. For instance, someone requests the annual profit and loss statement (P&L). It is generated as an Excel spreadsheet, complete with totalling formulas. The person then notices that an entry was omitted, and inserts a line and adds that entry. The final report is correct (hopefully), but the data in the system is still incomplete, and now at variance with the report delivered. The best practice here is to output the reports in the least editable manner available, such as PDF (or for organizations still using it, paper). In the PDF (Adobe’s Portable Document Format) scenario, the person who notices that an entry was missing is forced to do the right thing, which is to enter the correct data and then rerun the report.
Another suspicious item is any instance that involves VBA (Microsoft’s Visual Basic for Applications) macros or any other type of macros or plug-ins being used in any type of data-containing file, especially Excel files and Microsoft Access files. The best paradigm for handling data is the Model-View-Controller (MVC) paradigm, in which the model (the data and the metadata, usually contained in the database system), the view (the report or the data entry facility [screen or form]), and the controller (the program [desktop or web]) are kept separate. Putting VBA code into data files often means that when data and/or programs are updated, they no longer match.
Sometimes Excel forms are used as offline data entry forms. Although there are cases when this is the best way to go, those cases are few and far between. Any time you see an offline form in use, ask whether the form could be better done as a paper form, a web page, or a data entry screen in a desktop application.
The bottom line is that any time you see a report being generated in Excel or any other editable format, be very suspicious.
4.9.4. Adding Automatic APIs
An API is an Application Programming Interface. What that means has changed over time. Originally, it meant either how the desktop application interacts with the user, or how a subroutine package can be called and what data it delivers. As of this writing, “API” most often means the manner in which HTTP-based (Hyper-Text Transfer Protocol) distributed applications communicate with each other. It can also mean other socket-based protocols — including custom protocols — used for the same purpose. “API” can also refer to file formats.
If an application is going to be written by two or more companies, or even by two somehow-separated groups within the same company (such as having the project split between two groups who will each work on their own and integrate their deliveries later), then an API must be developed between the two components. This might happen once the project is in the coding phase, but can happen as early as the original requirements definition phase. Sometimes a new project will use existing APIs from existing external projects. For instance, an eCommerce application might use an existing API from a payments processor and a fulfillment center’s system.
To an extent, paper documents can be treated as an API. Various sorts of automatic document scan, recognition, and data entry programs can be written in a number of systems, most notably Kofax and Google Vision. Electronic documents in various formats (meaning both various document extension types and various lay-outs) can be used, too. Often, programs have screens that list various things, and have a button to enter a list of those things as a spreadsheet document. If and when appropriate, include such a button. But, if you can have a button at a higher level that just reads a document and figures out what to do with it, consider that.
In a matter relating to “figures out what to do”, always be prepared to think outside the box. For instance, one company had a rather tight options entry dialog screen for a report in which there were about 40 controls already. These included things like overall report format, paper size, number of columns, sort order, symbols to be used or not, suppliers to be exclusively used or excluded, contract types to be exclusively used or excluded, geographic area, types of services, languages, and others. Several new controls had to be added. In “in the box” thinking involved deciding how to cram the new controls into the window, or adding a “Next” button that would lead to more controls, or dividing the dialog into tabs, and moving some of the controls to the new tab. But the out of the box method was to get rid of all of the controls, and to have just one text entry area with the label “What do you need?”. An example report request for the final text entry area would be “I need a list of all general practice dentists in California and Nevada that speak Spanish, with handicap symbols, valid for July of 2021”.
4.10. “JAD Sessions”
A JAD Session (Joint Application Development) is really just a more formalized form of a meeting or discussion. There are specifically defined roles and responsibilities. The person who puts the meeting together, prepares for it, sets its agenda, moderates it, and hopefully solves any conflict is called the “facilitator”. The facilitator send the invitations (or in some companies, summonses). The facilitator also prepares the agenda of the key points to be covered. One or more of the attendees is the person or people who own the underlying need. This may be the customer, internal funder, champion, or project manager. Next, we have the expert participants. These people will typically be subject matter experts in some form, either because they know a lot of key facts, because they’re highly skilled and experienced, or maybe just because they’ve seen firsthand and often the nature of the problem to be solved. Last, we have the role called the “scribe”, which sounds like the secretary, but is actually the person who documents the requirements that come out in the meeting, and writes the specifications. During the meeting, or JAD Session, requirements will come out, but there will often be issues that come up that need further investigation. The scribe documents these too, and the facilitator will schedule new sessions with their own agendas to deal with those issues. In this manner, inputs are taken, and at the same time, approval is usually given.
The process tends to work for two reasons. One, being a formalized session, with just about everyone in attendance, people don’t get lost in side-tracking because of the formal agenda and moderation. Second, the placebo effect is helpful. When the attendees are “just chatting”, they feel a lesser stake, but when they’re in a “JAD Session”, well, now things are happening at a high level. The downside is that with mandatory attendance of a lot of people, JAD Sessions are expensive.
4.11. Demeanor: Asking, Demanding, and “Good Cop Bad Cop”
Generally, in a business setting, everyone is happy to communicate with the business analysts, either because it’s their job to do the bidding of the business, or because they realize that in cooperation with the business analysts, they’re going to get what they want. Not a bad assumption, since both tend to be true. However, you’ll get the occasional person who won’t cooperate. There are typically a number of common reasons for this, including forgetfulness, being too busy, not feeling like it, or fear that they’re going to be automated out of a job. That last one can be a real concern, since at some companies, that’s what happens. If you have any control over that sort of situation, the kindest approach (and safest not to cause an organized labor action, or worse, a disorganized labor action) is to make sure that any reduction in staff or reduction in force (RIF) is done solely through attrition or reassignment.
When someone is not cooperating with you or your team, there are several approaches to the situation. One is to just invite again. Another is to order compliance. In some organizations, ordering compliance is the way to go (the military, for instance). In other organizations people will stare at you blankly, or worse, if you give them an order. Asking nicely, up to begging/pleading can work. Sometimes what does the job is explaining how you’re here to help them directly helps. But, one technique that can be used is to have one pushy person, and one kind person. The pushy person more or less demands an answer, and the kind person then asks separately and politely. The person reticent to talk will often confide in the kind person, rather than stay quiet. Use this technique only as a last resort.
You’ll find that in most situations, the name you use should fit into the culture of the team, either as a team member, or as an authority figure. For instance, Robert Smith, PhD. might be introduced as “Bob”, “Robert”, “Robert Smith”, “Mr. Smith”, or “Dr. Smith”, depending on the culture present and relationship desired.
4.12. Wiki? Google Docs?
There is much talk about using wikis (wikiwiki is Hawaiian for “community”). Like Wikipedia, any wiki is a collection of pages that refer to each other in no particular order. That makes a wiki great for looking things up, but terrible for attempting to read something from start to finish. Also, in a typical wiki, there are no provisions for pending changes, nor for one person to be in control. Sheldon cautions you against using wikis for any sort of specification document, and encourage you to use them for manuals (although no more encouragement than using standard documents for manuals).
Google Docs, on the other hand, are great for working on requirements specifications. Let’s say that two people are in charge of the document, ten people are allowed to write comments into the document, and a hundred are allowed to read it. One of those two people can establish the document, and send an Edit invitation to the other editor, send Comment invitations to the other ten people, and send Read invitations to the rest. A Google Document can have multiple editors, commenters, and readers all at the same time. The editors would be adding their own text, and reacting to the comments. Typically, each comment will be a request for a change (explicitly or implicitly). The change request will be accepted and used, or rejected with another comment. When the change is accepted and used, the comment is typically marked as Resolved, and when the originator of the comment sees the rejection reason, that person will often mark the comment as Resolved, but maybe argue the point further.
Documents should have versioning information. In PDF and paper documents, those are typically in a table of versions, and change bars are used to show the latest set of changes. Google Docs’ Track Changes function allows for the same thing. Best practice would be to have official versions as of a certain date and time, and to have a “live” version which has not yet received a version number.
4.13. How Things Can Go Wrong
Things get missed. Bad data gets delivered. Neither one of these can be considered a failure on its own. They’re just correctible risks. You’re virtually never going to get 100% of the information on the first pass, and you’re virtually never going to get 100% reliable information. Just be aware that this happens, and keep track of confidence level: Certain, Probably, Likely, Scientific Wild Guess (SWAG), or Wild Guess (WAG).
4.14. Discussion Questions
- Do you think that there is one of these techniques that is likely to work better than others? Which?
- Have you used any of these? Do you have a favorite?
- Have any of these been used on you? Did you feel more comfortable in one manner than another?
