Three weeks after I graduated in May, a big moving van collected all of my possessions, including my new car (my first post-graduation debt!). I flew on a plane to Houston while the van made its way south. I did not know anybody in that city. My only contact was an employee that had called me a few times. I knew his name was Fred and I thought he was another systems analyst. When I arrived in the city, I called Fred and he invited me to meet him at headquarters. To my surprise, Fred had a huge corner office on the 25th floor–he was a big-shot manager, not another systems analyst. Fred introduced me to the people in human resources who helped me find and apartment and get situated.

Once settled from my first big move, I had to make another major life adjustment–I was expected at work at 7:15 a.m.! The first few weeks, I was enrolled in various training classes on the petroleum industry as well as technical classes on COBOL and JCL. During this time, I got to make friends with the other 60 new hires. (I said this was a big company).

Most of the first work assignments for the new hires were support of existing systems. My first assignment was on a development team to replace the entire accounting and operating system for the company. There were 70 people on the project, divided into various sub-groups based on business functions, such as accounts receivable, inventory control, accounts payable, general ledger, chart-of-accounts, etc.

I worked on the inventory control subsystem. My team consisted of a team leader–another analyst with 5 years experience, myself, and a full-time user, Ed. Ed used to run one of our largest pipe and wellhead warehouse in New Orleans, but was re-located to Houston to work on this project. He had over 20 years with the company. The goal of our subsystem was to reduce the $1 billion in surplus inventory due to poor business processes. There were over 2,000 warehouses (some are very small, basically a pile of pipe next to a drilling site) and 300,000 material codes. My first job was to understand everything about pipe and wellhead warehouses, including how material is ordered, received into inventory, inspected, tracked, transferred to the drilling sites, etc. Ed and I spent six weeks in a large conference room drawling data flow diagrams of the processes. Then the project leader quit and there was no immediate replacement. (Boy did I panic). I decided that I had to go to the warehouses because I couldn’t conceptualize the business from the data flow diagrams. (Plus I was excited about going to New Orleans).

My senior supervisor said I could go to Midland/Odessa (this was less expensive than New Orleans). This experience was a shock. I showed up at the warehouse in a suit and heals, expecting a clean building with conveyor belts and fork lifts. Instead it was a huge dirt lot with a fence around it. I followed the warehouse personnel and began to appreciate why the accounting systems were so messed up. These people were so busy hauling and inspecting pipe (with big water-pressured machines), that the paperwork was the last thing they did each day. They had to fill out forms and have to remember the material codes for everything that went in and out of the warehouse that day. With 300,000 material codes to choose from, that’s no easy task. If they don’t know the material code, they have to write out a detailed description, such as the weight, grade, thread, length, condition code, etc. After that trip, Ed and I had a much better time communicating.

After starting to design the inventory control system with Ed, I learned the true meaning of the word “integrated system”. We always had to communicate with the other sub-systems. For example, the purchase order sub-system wanted to use a new material catalogue, which would affect everyone of our programs. The chart-of-accounts sub-system wanted to create new accounting codes, again effecting the design of every one of our programs. We all had to keep in constant communication and there were scabbles as to who would change what. (I.E., everyone wants the other team to accommodate them.)

To make a long story short, midway through development, the company decided not to build the system from scratch, but to buy a software package and customize it. We waited 4 months for the contract to be negotiated and signed. With the prospects of nothing to do until the new system arrived, our senior supervisor created “RAMBO” teams to design, develop, and implement little fixes to our current system. The inventory control team (which had a new project leader, yeah!) began designing lot’s of little things to fix. We bought a Sales and Use Tax table and wrote a program to automatically calculate the right tax for material transfers. (The tax laws are so complicated that we were paying taxes “just-in-case”.) We also built and electronic data interchange to a company that tracks current market prices for pipe and wellhead. This was great because the accountants used to have to keep tons of catalogues in their office to look up prices. We wrote another system to immediately put joint interest checks in a bank (an electronic funds transfer). (Actually these projects took more than 4 months, but you get the idea).

While working on the development team, I also had other duties. I was the data dictionary co-ordinator. That meant that as project teams started identifying new data items, I had to give them a valid name and enter it into the dictionary. I also provided reports for the database design team who had to logically order all these data fields.

I was also the security request co-ordinator. Everytime someone wanted access to a data set, I had to verify that they have a legitimate need to either read or read/write to a dataset. I passed the paperwork to the Security Administrator.

I also had to give lots of presentations to other project teams, supervisors, and users. At first I was so nervous about these public speeches. But I joined Toastmasters and learned to really enjoy talking in public. That was a vital skill to learn because that’s about the only time senior level people are exposed to the analysts, and they are the ones who ultimately determine performance ratings.

In summary, my first two years as a systems analyst were very exciting. I spent most of my time talking with users to understand the business and to other analysts to ensure compatibility between subsystems. I did a lot of design work, and created documentation for these designs, including reports, input forms, and programming specifications. I coded some of the programs myself (in COBOL and PL/1). I learned how to test systems as well as implement them. I did some technical writing by documenting new systems, including technical documentation and user documentation. The best things I loved about these two years was making friends with all the other analysts (work was very social), learning all the time about both the business and technology, meeting new challenges such a public speaking and learning to adjust my “technical jargon” to my audience.

Paying Your Dues
Few companies are willing to spend money on someone who doesn’t have some kind of programming background. There is not much difference between an analyst and a programmer, though the programmer needs to be versed in a programming language. As far as dealing with the functional requirements, these are the same position. There are junior-level analyst positions, which is almost like being a junior programmer. Any of the Java applets and the basic visual C++ programs are very applicable to today’s market, while Cobol and the older programs such as Assembler are considered dinosaurs. Without experience, a support role at the help desk with internal training is a good way to start out.

Associated Careers
Financial companies and most of the Fortune 100 companies have systems analysts who may also have programming responsibilities. But today, many young analysts are flocking to Web companies where there’s money to be made. A small starting salary combined with options could make you a multimillionaire within a short period of time, or your company could go bust within the year. Internet ventures attract risk-takers, so it all depends on how much of a gambler you are. Many systems analysts come from creative backgrounds; some return to those fields, while others combine their artistic passions with Internet opportunities. “If I left my position and was able to do anything, I would go back to photography or painting or apply those talents to Web design,” says one systems analyst.

There are two main objectives of any interview. The first is for a company to determine if you, the candidate, are the right fit for the position. The second is for you, the candidate, to determine if the company and position are the right fit for you. The following tips will address how to present your best to the prospective employer. In addition, you will find some helpful tips for determining if the company and a position are the right fit for you.

Interview Guidelines

• Relax
• Dress one better
• Turn your cell phones and pagers off
• Understand the question
• Show interest
• Show confidence, not arrogance
• No badmouthing
• Do your research
• Be on time

Relax. Many people tend to tense up at an interview. While you should always remain professional, don’t forget to relax and let you personality come through. The hiring manager should get a real sense of who you are. You will be working for or with this person every day, so it’s important for them to feel they can get along with you easily. No one wants to work with a business or systems analyst with a difficult personality.

Dress one better. A good rule of thumb is to dress one degree nicer than the group you are interviewing with. If the employer has a business casual dress code then you should dress in conservative business attire. If the employer has a casual dress code (jeans, t-shirts, etc) then you should dress in business casual. This ensures that you are always presenting yourself in the best way possible without seeming completely out of line with the company’s culture. You would never want to appear underdressed, nor would it be wise to show up in a full suit or conservative business attire if the company has a culture of being very casual. It would appear as if you wouldn’t fit it.

Turn your cell phones and pagers off. Simply turning off the ringer or placing the phone on vibrate is not enough. Everyone knows the sound off a vibrating phone or pager, and it’s very distracting. By turning off your electronic devices ahead of time you can remain focused on the interview at hand. Nothing is worse than trying to focus on a question the interviewer has just asked you while your phone buzzes incessantly.

Understand the question. Listen carefully to the question being asked as well as what it not being asked. If you don’t understand the question, or you believe the interviewer has left out some important information required to answer the question, then ask a series of clarifying questions to obtaining the necessary information. This an excellent way to demonstrate one of the most important skills required of a business or systems analyst (information gathering). Be straightforward and concise with your answers. How long or short your answer is isn’t nearly as important as the content of your answer. Don’t be evasive and don’t lie or bluff. Bluffing will destroy all credibility. If you don’t know the answer, then say so. If you think you can make an educated guess then let the interviewer know that you aren’t sure but based on the experience you do have you believe you can figure it out. Let the interviewer see your thought process as you work out your answer. Many times how you go about problem solving is more important than whether you arrive at the right answer. In any case, take a few seconds to think about your answer and formulate a structured response. Rambling and saying the first thing that comes to mind conveys that you think randomly and in an unstructured way.

Show interest. At the end of the interview thank the interviewer for taking his or her time to see you and shake their hand. If you are still interested in the job make sure to let the interviewer know that you are interested and that you want the job. Let the interviewer see that you are excited about the position.

Show confidence, not arrogance. Always present yourself with confidence, but be careful not to come across too strongly or the interviewer may perceive your confidence as arrogance. This is always a delicate balancing act. State the facts of the situation needed to get your point across and convey the information using powerful action words.

No badmouthing. Be positive and avoid making negative remarks about former jobs, managers, or employers. Business and systems analysts need to be able to work with a wide range of personality type. Badmouthing others will not help you land the position.

Do your research. Prior to the interview research the company to learn as much about your prospective employer as possible. Make a list of questions to ask the interviewer. This shows that you are able to research areas that you know little about, another important skill of business and systems analysts. Convey what you’ve learned from your research and what you found interesting about the company.

Be on time. You only have one chance to make a first impression. Plan to show up for your interview at least 15 minutes early, and plan for unexpected delays. Showing up early gives you the opportunity to clear your head of the day’s events. Take the time to refocus on the interview at hand. If you do encounter an unexpected delay, be sure to call ahead and let the interviewer know that you may be arriving late.

Then, members of the team develop a shopping list, plot a step-by-step game plan, implement the system, test it, and troubleshoot. They also might supervise the trainers, who will try their best to convince everyone that the new system “really will make your life easier.”

Being a systems analyst requires programming skill, but more important is the ability to see the big picture: translate geek-speak into plain English, identify company needs, and get everybody on board.

Creative liberal-arts types with computer expertise usually make better systems analysts than pure techies. If you’d love playing with leading/bleeding-edge adult Tinkertoys for a living, this can be a dream career. Yet another plus: Because so much sensitive communication is involved, this is among the most offshore-resistant computer-related careers.

Median Pay
National: $91,000. More pay data by metropolitan area

Training
A bachelor’s degree is normally expected, but not necessarily in computer science. Computer expertise acquired through real-world experience is often acceptable. An M.B.A. is a plus, though for most positions it’s not required.

Smart Specialty
Government agencies and universities hire lots of systems analysts, and they’re often the most stable employers. Increasingly, the private sector is using temporary employees, hired just for a specific project.

Because they must write user requests into technical specifications, the systems analysts are the liaisons between vendors and the IT professionals of the organization they represent. They may be responsible for developing cost analysis, design considerations, and implementation time-lines. They may also be responsible for feasibility studies of a computer system before making recommendations to senior management.

A systems analyst performs the following tasks:

• Interact with the customers to know their requirements
• Interact with designers to convey the possible interface of the software
• Interact/guide the coders/developers to keep track of system development
• Perform system testing with sample/live data with the help of testers
• Implement the new system
• Prepare High quality Documentation

Many systems analysts have morphed into business analysts. And, the Bureau of Labor Statistics reports that “Increasingly, employers are seeking individuals who have a master’s degree in business administration (MBA) with a concentration in information systems.”