the Systems Analyst role - building a team
When a company is considering installing a new system (or startup system), the most common approach is to create a team for the project. If the company is small it will usually hire an integration company to do the development. A mid-sized company may have an in-house project manager, but not the IT staff to handle the project; they will often contract out the work to an integration company answering to the project manager. In a large company, there is usually sufficient staff with the right capabilities to complete the project in-house.
An integrated system is one which combines more than one system, such as a network, or the phone lines at a Help Desk. Sometimes one would integrate a Mac network into a Novell PC network, or have communications between more than one network. Of course, software needs to be integrated into an existing or new system. Some companies that call themselves Integrators build entire systems. It's not really a hard and fast term.
Choosing team members may not be a privilege given to the systems analyst; teams are often made up of volunteers or are assigned by management. It is up to the systems analyst to determine the talents of the team members and lead them accordingly. People in IT need to be “team players”, willing to work with each other, and the project manager needs above all to be able to manage all the personnel on the team to achieve the success of the project.
The actual participants in analysis and design vary, from a single programmer (or developer, as they prefer to be called) and his/her client, to entire teams, depending on the size and politics of the organization. The team may be led by a systems analyst rather than a project manager, and the analysis may be done by a single person or a group. Often the project manager is the representative of the business end of the project, and the systems analyst manages the technical group. A new buzz word in the industry for a systems analyst is “application architect”; it loosely applies to someone who designs the path an application will follow, and is usually the purview of a systems analyst.
A successful team is built on trust in one another, listening to each other, and rigorous communications. As a consultant, I often step into a team of people who have worked together in the past. I have to have the faith in myself to speak up. And I find that the team invariably welcomes a fresh point of view.
The team members, then, can consist of the following: project manager, systems analyst, developer, hardware technician(s), database administrator (DBA), SME (subject matter expert), and sponsor (the person who instigated the project and will OK all steps and payments). Not all of these positions will be in all projects, of course, and some roles may be filled by more than one person.
I was recently working in a large world-wide corporation. They had a well-earned reputation of high retention - once you were hired there, it was rare that you got fired. However, in order to maintain this retention, they sometimes had to move people into roles that were created just to find a place for them. One example is called "shadow IT". What this meant is that the person was no good at his/her job as a research chemist, but did demonstrate an ability for hacking on computers. These shadow ITs were not a formal part of the IT organization, and as such not held to the ethics or processes in the IT group. So they would do as they pleased, pass opinions on IT work as 'representatives' of their scientist colleagues, and generally cause more havoc than good.
As a systems analyst, managing expectations may be the most difficult part of the job. For example, you may have to tell clients they cannot have parts of the wish list due to costs, time constraints or equipment limitations.
Ethics are a strong part of the systems analyst’s function. Most companies outsource a great deal of their IT work, in every level from technical support to network management and project management. An ethical consultant (also called a contractor) should document all work so it can be picked up by a third party and must respect the confidentiality of the work s/he is involved in. I have been privy to information about therapy patients, drugs being developed, financial information on a small business such as a real estate office. It is very important that I and my staff let this information pass right through and never be repeated. A consultant who is hired via a contracting company is bound two ways – loyalty to the home company as well as the client – and must keep a fair balance between the two. If this is done correctly, the home company will support the consultant to the end. If the consultant functions unethically, s/he will end up on the street, and virtually blackballed.
The team should follow a specified methodology, which is determined by the project manager or systems analyst (these terms are often interchangeable). The most common method is the waterfall method to direct the SDLC (system development life cycle). Nonetheless, nothing is etched in stone, and the systems analyst (SA) must have the flexibility to handle problems as they show up.
The biggest problem is calming the client down. Next biggest is convincing the IT people involved that it’s human to miss something or not be able to predict something. Clients tend to believe the IT group that this will always work the first time round. While it's nice to exude confidence, the truth of the matter is that no matter what extent you tested, once the product goes into production on a full scale of over 5000 users, passing around worldwide networks with Unix boxes, NT servers and Win2000 desktops, there are bound to be some logjams. The client has to understand that this is going to happen, and be reassured by the prompt putting out of the fires. The IT workers are similarly frustrated when they've tested the product extensively in systems testing, UAT (User Acceptance Testing, which is a small group of subject matter experts) and possibly even pilot programs. Nonetheless, one server in the Mount Vernon site, or a user's machine with unique settings (don't ask...) can upset the best-laid plans. Assure the IT people that this is not unexpected - then recruit them to troubleshoot the problems that crop up.
The typical steps that a systems analyst will guide in the waterfall method are:
- initiation - client sends out an RFP or requests system or software development; developer asks general questions to get the 'big picture'
- Analysis - through several different methods, developer determines exactly what is needed, budget, time constraints and feasibility; developer then proposes project to client via a Requirements document which, when signed by both parties, is a contract to go ahead with the development. Due to the cost of the analysis phase, a contract may be more general and signed before analysis begins.
- design - the systems analyst will architect the system, usually by designing system hardware, data flow diagrams, use-case diagrams and ERDs, and sometimes even a class diagram.
- development - programmers write code, build databases. Technicians build hardware and systems. At this point, system testing (of both hardware and software) is done, and UAT (User Acceptance Testing).
- implementation - setting up the entire system at the client's site. This includes notifications and production testing.
- maintenance - upgrades, troubleshooting in the opening weeks of the implementation, patches
Because of the broad spectrum of responsibilities that an SA must shoulder, this person must have experience in all phases of this life cycle. And it is the SA who will probably answer for the success or failure of the project.
