Business Systems Analysis - Analysis Phase
Information-gathering at the inception of a project
I consider the use of interviews to be the most important fact-finding method, backed up by the collection of business documents, for fact finding on a development project. I prefer interviewing fewer people with an hour for the interview, and only interview one person in each role. My reasoning is that, in interviewing more than one in a role, the information would become redundant (and therefore a waste of time). Often, only the manager or the person “buying” the service (that is, the one whose budget gets most impacted) will offer to do a Needs Assessment interview – this is totally unacceptable because the manager does not fully understand the needs of the end user. Ask the manager for permission to interview the most experienced and/or ‘largest’ user in each role.
For instance, if the project is a payroll package for a retail chain you would want to speak to
The manager/owner/requestor – find out what s/he is looking for, the budget, and the reason for the inception of the project. Who handles the W-2s and how? Do employees get a shift differential?
Timekeeper - how are they amassing the employee weekly time information; if this information comes in electronically, can the new system import/convert the data? If the employee’s recording of his/her time and the timekeeper’s entry of the employees’ time is all manual, consider computerizing one or both sets of information as a high-end solution.
Person cutting checks – how are they getting and storing the timekeeping, W-4, and tax information? What specific problems are they encountering, such as sorting recipients by branch, separating out checks to be mailed and check stubs to be mailed (for direct deposit accounts) and sorting those all by zip code? How is all this information being sent to the bank? Format?
An employee – how does s/he track his/her time? Any complaints about this method?
If at all possible you want your system to be able to interface with any existing electronic systems, both for feasibility and the possibility of replacing the existing systems in the future.
The problems with interviewees are very real. If the person does a manual, clerical job, s/he is going to fear electronic replacement. This person is going to be very self-protective and might even mis-inform the interviewer to make the latter look incompetent. To get cooperation, keep assuring the person that you will not replace him/her; instead you will ease his/her workload – people in this type of a situation invariably complain of an overload of work and/or a fear the s/he is too accustomed to the “old” method and won’t be able to learn a new one.
If interviewees give you the ‘should’ scenario instead of the reality scenario, is this really bad? You will be building in just the corrections that are needed. Ask questions were you suspect there’s a specific lack of information. Encourage “complaining” – it is there that you will learn the weaknesses of the old system (hardware, software and wetware) and what you can offer as a cure.
An interviewee not being able to describe his/her work is very common, especially in a company which grew from a small mom-and-pop organization to a good-sized corporation. These folks learn their tasks, but not the terminology or standard methods. As an example, a person can have 10 years’ experience building and managing projects, but they don’t know what an SDLC is because they never went to school for Project Management – they just did it. You end up hearing descriptions of a specific task, rather than the actual information flow. For example, at Bristol-Myers I was trying to map the process by which the site network was managed. I got a glowing description of a recent problem with a single workstation and how it was eventually discovered to be the NIC (which was a different department’s purview). What I needed to know was for which situations would a technician contact the site Network people and what was the flow of information from there?
There is a specific problem in systems analysis – the people who get into this line of work often have a good technical background but are weak in “people skills” and judgement. These are two very important skills. If you are in this position, take advantage of any management courses available to you – it will only make you look better to your employer. If you find you don’t really like the people-part of the job (and many technical people don’t) consider being part of the development team instead of the client-interface team.
I have worked for two different very large corporations in the same field – one has a team that does nothing but document the processes in use in all departments (and publish it on the intranet); the other doesn’t even have a P&P (Processes and Procedures Manual) for the IT people. Needless to say, the former is more successful.
All business forms are of great value – not only what they fill out for input, but also every report/invoice/whatever that goes out. Whenever I’m doing a Needs Assessment I request sample copies of everything they mention and try to anticipate others they forgot. You can always weed out those you won’t need. And refinement of the data, to avoid duplication, is easier done this way. Sometimes they are inputting or outputting the same data, just using different names for it, so they don't realize it’s the same. What you don’t want is to discover after the delivery that the data for a regular report is NOT there; you can build the report later if needed…but adding fields and inputting missing data is tough and expensive. Whenever an input field does not appear to be used for output, question whether it’s a necessary field (it may be something they intend to evaluate in the future.)
I am not a big advocate of questionnaires. Even if they are electronic, maybe 25% respond. Non-response is very important – there is usually a very good reason for it. Online forms are great; people usually think it’s safer, and no one will be reading the responses personally, so they are more likely to fill them out – and truthfully (after all, one couldn’t tell who it is by the handwriting). Use their intranet. Questions on the level of satisfaction are a bear – every try to decide if you are ‘somewhat satisfied, as opposed to ‘satisfied’? Avoid the subjective queries.
On requesting documents – an organization chart is usually not very important – unless you want to know who to please (often a determinant). Above all you want its forms of information -– what forms are used to gather the information now – job applications, patient intake forms, logs kept by the people running programs, etc. – and what information needs to be extracted (standard reports to stockholders, paychecks, metrics reports to management, invoices). The output will determine the format of the input. So I guess you could say I advocate a top-down approach.
One reason I have a lot of not-for-profit organizations as clients is because they need to report to at least one agency on their activities, as well as funding agencies (such as United Way and the Dept. of Children and Families). There is no pre-packaged software for these organizations which can track their activities (there are shrink-wrap packages for non-profit accounting). They have to report activities and demographics quarterly to each funding agency or lose the funding. These projects must be designed from this vantage point of output, and often ‘registration’ electronic forms need to be designed to nudge them into getting the data needed.
Direct observation is one of my favorite methods of information-gathering. Ask questions; if you do it right, they get into ‘brag mode’. An example of the value of observation: I have a client for whom we have done data warehousing since 1996; we know all the groups they need to answer to for funding and licensing, we know the demographics that are important to the management, and we know what the esoteric codes mean. The state of Connecticut decided to create its own databases for the reports it was evaluating each month, since it had been up to this time information was manually input and was constantly in error. But the man hired to build these databases had no idea what the information meant. The result – an awkward database that has had so many errors in it that it’s been revamped 3 times in the last 2 years. Plus, they seem to think their reporting agencies are stupid, so they locked access to the database. Result – our client had to pay for re-input of 600 records, and pays extra each month because we then have to export the state’s information, fix it and add our additional tracking information. Why fix it? The state has the zip code locked into CT-only zips – my client is near the Rhode Island border and often gets clients who have RI zip codes.
Additional information? The state doesn’t think in terms of separate programs, so we have to re-align the data. And the state selected its own case-numbering system, so the client has to keep a double-system for all current cases. I could go on ad nauseum… If the developer had observed what the reporting agencies actually do, a lot of these problems wouldn’t have cropped up at all.
Characteristics for a good systems analyst during requirements determination:
Impertinence – asking questions. It looks easier than it is. You could easily miss which questions to ask, which might require a call-back. This ability to know what to ask is a developed skill, and certainly each project will make you more aware of what to look for.
Impartiality – the politics get in the way all the time. Always consider the source; what is the person’s attitude toward the project? What will this person gain or lose with the new system? You may actually be told by the ‘buyer’ that a particular person’s opinion is not [is most] important. Find out who makes the final decision – this is the person to try to satisfy in the end.
Relax constraints – yeah, right. The biggest hurdle is “I have done it this way since Ben Franklin…” The client may insist on a mimic of the present system; any change to this would have to be gradual, probably a follow-up upgrade. Try to keep as close to the present way of doing things as is efficient, such as having electronic forms look very similar to the paper forms they are using – but with time-savers on them such as default values.
Attention to detail – if you have a computing background you already know that it’s the details that will kill you
Reframing – this is no problem if you are an outside source. But if you are an in-house organization this is very difficult for the analyst as well as the client.
Knowing the business objectives is necessary to sell your solution. For example, one year Bristol-Myers had a Business Strategy Objective (BSO), which was defined in detail. All work had to be justified according to the BSO or it wouldn’t be done. One key phrase is “this is the ROI” (Return of Investment); since it’s a business buzz word, ears perk up that have no interest in the technical stuff. And it’s always a selling point – prove to the client that they will get a better profit, to the tune of a multiple of the cost of the new system in the first 5 years, and you’ve made your sale. For not-for-profit organizations, the people are busy saving the world; they don’t carefully track their own activities. Showing them how tracking particular information can increase the funding works like a charm.
Every time I build an application for them, I discover a lot of things they could track easily by computer that they weren’t bothering to report at all. As a result of the more efficient reporting, their funding increased significantly. Be sure to observe more than the sponsor offers.
Watch for side activities/processes that can be incorporated into the system (for the high-end solution, or a follow-up proposal). And watch for redundant actions which can be eliminated – this is quantifiable ROI. Be sure to re-write notes after doing an interview, receiving a questionnaire, or reviewing documents; you’d be surprised what you’ll forget in a matter of hours. Remember that your time and that of the people giving you information are both valuable. Do not give notes back to the person you question – you should have notes that are not for the clients’ eyes, since they might misinterpret them. Instead, you could graph or outline the information and have them review it for accuracy.
JAD stands for Joint Analysis and Design. This is often where you’ll find professional facilitators. Within your organization a JAD should be run by someone on a management level – or someone being groomed/trained to be on a management level. It might be the Project Manager for that project or a Systems Analyst. Because professional facilitators don’t know the subject matter they often lead the discussion in the wrong direction. The only time you’d see a JAD is within a company that has application development as its business function. It’s expensive and time-consuming for the client. It would be nice to have it run electronically– and run it at the client site – but now we’re really getting into the big bucks. In most cases a JAD is tracked on a white board or large paper pads, and then has to be rewritten and published. One big problem is squabbles among the clients. Better then to interview them separately, make your suggestions and let them squabble it out after you leave.
Analysis of gathered information
Prototyping is a great idea and should be a standard part of the development process, if you can convince the client to do it. It allays fears of what to expect, makes it easier for clients to articulate their needs and practices, and it’s cheaper in time, money and work than coming up with a revision. The only detraction is that if the contract is turned down, the developer needs to “eat” the cost.
A good approach to convincing the sponsor if the need for change is charting the existing system: all manual, hard copy and electronic processes together in a ‘current systems’ data flow diagram. Don’t bother to flabbergast the client – win them over with professionalism.
There are hard copies which must be maintained in certain industries such as pharmaceuticals and legal companies. These can be scanned into a database, moving closer to a paperless work environment (and it’s certainly a lot easier to manage). There is a company in Connecticut that does nothing but scan and index all the paperwork an attorney needs for a case, so s/he can review, evaluate, cross-reference and call up any piece of evidence in an instant.
Data flow charts really aren’t that difficult for software companies, because they usually have teams that always do the same type of applications, such as warehouse management for whatever kind of warehouse comes along – they modularize and rearrange the modules.
For presentation to the customer, ‘before’ and ‘after’ data flow charts would show the simplification of the processes, which is usually enough to convince them to continue with the project. Those of you with Visio are probably aware of the many ways in which to represent processes. Is any one icon or system the best? Absolutely not. You can use circles and squares, as long as it’s clear and well-documented – you want to be able to send the client home with a printed copy to evaluate the changes on his own time, rather than making him feel pressured to respond immediately.
Knowledge of programming is a great asset to developing these charts, so the systems analyst will often work hand-in-hand with the programmers in drafting them.
During analysis, a feasibility study should be done. Feasibility is hard to nail down. It looks somewhat overwhelming at first. Many companies have a dollar figure per-employee for additional manpower. And experts in each phase (networking, users, hardware) can usually give you information on what it will cost, or if it’s not possible to do. In large companies, there is usually a good idea ahead of time of what the costs will be, and they will be looking more for the time span involved. In small companies there is usually a serious “sticker shock”, and many projects die at conception.
Throughout this process, the aim is to achieve an agreement, which will probably mean compromise on both sides.