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.

Why be Concerned with the Business Analyst Role?

It is my contention that, without the analyst, real gaps occur. For example:

• Who looks at the bigger organizational problems?
• Who identifies the underlying conflict between what management want (the Customer who pays for the software development, after all) and what the “Users” (a horrible term – but that will be the subject of another discussion) need in order to do their jobs effectively?
• Who identifies the fact that there are (say) 1500 people who are currently doing their jobs in one way, and that after we’ve implemented the new software will need to significantly change their work patterns?
• Who helps these people design new organizational procedures to ensure that the business continues to run smoothly as the changes are made?
• Who identifies the potential lost business due to a poorly thought out customer interaction?

I could go on, but you get the picture.

Alan Cooper gave a great talk recently at a conference wherein he spoke with passion about the need for inclusion of Interaction Design in Agile projects, someone who understands how people behave and who can help the Customer come up with guidelines for the technology implementation to ensure that the resultant product works effectively in real-world use.

My contention is that this role is one which is ideally and effectively undertaken by the Business Analyst, and is something that we should have been doing all along. It is part of what we are trained for – understanding the broader business needs and interpreting these needs in ways that make sense to team members who are more focused on the technology. Traditionally the custodian of the focus on the human need has been the Business Analyst.

Business Analysts Contribute to Team Success
I strongly believe that the de-emphasis of the importance of this role is one of the major gaps in many Agile teams today. In many organizations the analyst role is hobbled – unable to effectively deliver the value they promise due to organization structure and lack of management support. The business analyst needs to be seen as the customer advocate, part of the business-focused solution provision team, rather than a purveyor of technology. Politically empowered, trusted and acknowledged for the perspective and understanding they bring, the business analyst should ideally report into a business improvement area, not into the information technology group. In this structure the business analyst will be empowered to recommend changes with a clear focus on the business value, rather than being perceived as the “lackey of technology” as part of the technology group.

What about Systems Analysts?
Note the distinction here: we are talking about Business Analysts, not Systems Analysts. Where does the “Systems Analyst” fit? While the systems analyst often has the skills to undertake business analysis effectively, I make a distinction between the two roles based on their perspective – the business analyst focuses on and is driven by an understanding of the business needs whereas the systems analyst is often biased towards, and focused on, a technology-based solution, sometimes to the point of being detrimental to actually solving the business problem (“Wow, have I got a solution for you!”). Systems analysts can be good business analysts, but they need to be very careful to suppress their urge to propose technical solutions!

Why Use an Analyst? We Want a “Customer”
The analyst spends time getting close to the diverse “stakeholders” – people who represent groups and organizations that care about the successful delivery of the business change. The analyst needs to understand the multiple dimensions of the business need; discussing with management the overall goals and objectives; working with the legal department to identify any legislative or litigious impacts of the new/changed business processes, working with the logistics department to identify changes to office space or warehouse layout and to understand the potential impact of the processes on the flow of materials or products through to dispatch; with the administrative staff to understand the potential bottlenecks that could result from a new approval process… and so on.

At some point in the analysis investigation it will become clear that solving this business problem potentially warrants an investment in technology. At this point the analyst role changes a bit and we get involved in the technical feasibility discussions – the “build vs buy” decision, the insource or outsource decision. At this stage traditionally the BA role is involved in developing the Business Case, which is still needed by the business when using the Agile approach – projects still should be justified in terms of the business benefits they will deliver to the organization. Without this valuation, the ongoing prioritization effort required for Agile backlog management can lack “big picture” vision, resulting in requirements thrash.

Once these decisions have been made and it is decided to spend some money on the technology, the analyst role changes yet again – now we become the shepherd of requirements; the collector and guide of stories. This is where the analyst actively intersects with the Agile project and becomes a vital participant with the Agile software development project team, representing customers and end users, and collaborating with the other team members to meet a clearly identified Business Need which we believe will benefit from a technology-based solution.

The Analyst works with the project team to corral the stories – acting as the customer advocate to the team, facilitating User Story definition, and being the project advocate to the wider stakeholder community, taking responsibility for getting the right customer voice to the project team at the right time. This “customer”, so blithely referred to in much of the Agile literature, is not usually a single homogeneous individual, rather they are an amorphous mass of “stakeholders” – a diverse, often contradictory, frequently competitive, sometimes negative group with divergent points of view about what the business need is and what “done” looks like.

Does the previous paragraph imply that I don’t believe in the “on site customer” – NO! I believe very strongly that we need an onsite customer for the Agile development process to be successful. The challenge we face is that there will be many customer voices, often shouting contradictory orders at the team. The Analyst must be able to filter the signal from the noise and help to identify the right representative customer(s) who should be involved with the project at any point in time.

So What Does this Analyst Actually Do?
On an Agile project, the Analyst also becomes the shepherd of stories – guiding the discovery process and facilitating the communication among the team, helping the customer representative(s) by asking probing “what if, what about” type questions, based on the broader investigation which initiated the project; building on their mapping of the stakeholder community, their understanding of the intricate political and influence relationships which underlie the formal structure of the organization and their ability to tap into funding sources to gain access to real-world clients (the people who actually pay for the services the system will provide) to gain an understanding of what is needed to create competitive advantage and Customer Delight – which ultimately results in commercial success.

The analyst needs to have a broad range of investigative and interpersonal skills, the ability to think critically and skeptically, using a variety of modeling techniques and other tools to help the customer representatives discover the range of stories which will ultimately make up the system. The analyst helps them express these stories in clear and understandable ways that make “done” explicit and knife edged, works with the testers and customer representatives to help identify and clarify the acceptance criteria for the whole gambit of stories.

The best analysts are involved in every aspect of story identification, and actively involved in the interaction design for the system. They have an understanding of the various ways the broad community of users will need to interact with the system, understanding the divergent needs and smoothing the differences to identify the design aspects which will work for the disparate stakeholders.

Agile Analysts are Designers as well – with an understanding which goes far deeper than simply identifying and documenting the requirements for the system. They understand the implications of screen flow and ensuring that process flows match the way people actually work, they are aware of the impact of colors and fonts, of screen layout and response times on the productivity of the people who use our systems. They look for opportunities to create truly useful systems that people want to work with, and work to guide the creation of intuitive and natural interfaces; ideally interfaces that seem to disappear, so easy to use that the operator doesn’t even notice that they are there.

The traditional analysis “what before how” approach doesn’t apply on Agile projects – most often we understand the “what” by showing the “how”, in a productive and iterative cycle that is an inherent part of the Agile development process.

Look and Feel matters – the Agile Analyst helps bring this into sharp focus when the interaction aspects of the system are being worked on.
The Agile Analyst focuses on ensuring that real business value is exposed and uncovered by working with the project team and customer representatives to find those aspects which make their work easier, more productive and deliver Customer Delight, the “stickiness” which keeps our clients coming back to do business with us over and over again.

Who Should Play the Analyst Role?
The Product Owner or chief customer advocate in a Scrum project is a role ideally suited to the Agile Analyst, provided they are empowered and supported to act on behalf of the customer. The Analyst is in the position to actively manage the product backlog and identify product priorities. Building on relationships with business stakeholders and an understanding of technical realities the Analyst can actively manage the delivery of value in the project.

The Agile Analyst needs to be an active and productive member of the business project team, not trying to produce a lengthy tome of “shall” statements, but representing, advocating and shepherding the many customer voices, asking the hard “have you thought about. . .” questions, ensuring that the products we deliver meet the diverse and competing needs of our customers, understanding and indentifying flaws, flows and issues with discussions and interactions within the entire project team, based on the User Stories current and past.

The Analyst Role is Necessary for Success

Technology exists to serve, not to be, the human need!
– Malcolm Watson, the Development Manager at Pronto Software in Melbourne

The Business Analysis community needs to step up to the mark – becoming active participants in collaborative Agile teams focused on the creation of systems that deliver real-world value and Customer Delight. An active move back to the “Analyst” part of the role – breaking the problem apart into its constituent components in order to understand the real underlying needs, then working as an active participant on the project team to deliver a solution that creates competitive advantage and customer delight!

What does a computer systems analyst do?
Computer systems analyst is a blanket term for a computer professional that solves computer issues and uses technology to meet the needs of the company. These professionals might be employed under different titles: IT consultant, IT specialist, programmer analyst, business systems analyst, system architect and computer specialist, to name a few. These highly-trained professionals plan, design and expand new computer systems as well as configure software and hardware. They update/upgrade current computer systems and modify them for new or expanded functions. They are frequently charged with preparing cost reports for management.

Computer systems analysts usually collaborate with other professionals in the information technology field, such as programmers, network security specialists, and software engineers, and will sometimes specialize in specific systems such as accounting, business, engineering, financial, or scientific systems. Click here to find out how to become a computer systems analyst.

What kind of training does a computer systems analyst need?
Computer systems analysts are typically required to have a degree of at least bachelor level. Many employers may require a higher graduate level degree, as well as experience in the field for more complicated jobs and senior-level positions. Computer systems analysts have many different degrees, but typically, they have degrees in computer science, information technology, and management information systems. Click here to get a list of programs to get your management information systems degree online.

Qualifications vary by employer, but general qualifications include: broad computer systems knowledge, experience in employer’s field, specific computer system knowledge, logical thinking skills, great communication and interpersonal skills, and sound problem-solving and analytical skills. Internships are appropriate for students ready to graduate, as they do not usually require any experience.

What are the prospects for a career in computer systems analysis?
Computer systems analyst jobs are projected to increase much faster than average for all occupations. There are new job opportunities expected in most related career fields. As companies and organizations continue to upgrade their technologies, excellent job prospects for computer systems analysts are expected. Employment for computer systems analysts is projected to increase by 29% from 2006 to 2016 with 146,000 new jobs. Computer systems analysts will be in high demand as companies and organizations continue to implement and incorporate new advanced technology.

How much do computer systems analysts make?
According to the Bureau of Labor Statistics, the median annual salary for computer systems analysts was $75,890 in May 2007. The middle 50% earned between $56,590 and $92,420 annually. The lowest 10% earned less than $43,930 and the highest 10% earned above $113,670. Computer systems design and related services, management companies and enterprises, insurance carriers, and professional and commercial equipment and supplies merchant wholesalers had the largest median yearly salaries.

A career in computer systems analysis is a great choice for you if you enjoy working in a comfortable environment in an office or laboratory and spending long periods of time working on a computer.

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.

Among the biggest threats to the future of corporate America are genetically engineered babies. They’ll look cute and harmless at first, with their tiny noses and symmetrical faces. Only later will the horror reveal itself, when the generation of perfect-looking people enters the work force with no marketable skills whatsoever. Can corporations survive without engineers, economists, programmers, scientists and other skilled labor? Where will the future Fords and Sarnoffs and Jobs come from?

Admit it: you’ve wondered why beautiful people rarely have any state-of-the-art skills. Are they born dumb, or does something happen to them during childhood? (Unless you’re beautiful yourself, you’ve had those thoughts, so stop rolling your eyes and making that “phhht” sound.)

Fortunately, it hasn’t mattered that beautiful people have no useful skills. There aren’t enough beautiful people to damage the economy. But that situation will change, probably in your lifetime, thanks to genetic engineering. Future generations will be tall and attractive, with perfect teeth, 20/20 vision and hair that never thins. If history is our guide, these beautiful people will not be capable of operating devices created by advanced technology such as doorknobs and can openers. It will mean trouble for corporate America. It will be even worse for cats.

I think beautiful people are born with normal intelligence. But they quickly realize they don’t need to fill their brains with unpleasant concepts such as nonlinear geometry and fluid dynamics. Beautiful people know they will never be asked to build a communications satellite or invent a vaccine. They know they can get all the money they need by charging ugly people to look at them. This commerce takes many forms, including marriage, television and Cosmopolitan magazine.

My theory is that people become only as knowledgeable as they need to be, based on how ugly they are. I have no proof of this, but I can tell you that when I was four years old, I scanned my relatives and realized I would grow up to be a short, bald, shy guy with glasses. This eliminated any hope of an easy career in marketing, politics, modeling or acting as host of Hollywood Squares. People who look like me need skills. Lots of them.

As I tracked the spread of my uncle’s baldness — a predictor of my own hairline — I studied harder and harder to compensate. My uncle eventually got so bald that I became valedictorian. I’m fairly certain that millions of other bespectacled, height-challenged introverts found academic excellence the same way.

The unpleasant truth is that corporate America depends on a steady supply of ugly people like me, people who know they won’t survive by their looks alone. The cruel irony is that genetic engineers — themselves products of this smartening process — are threatening to dry up our wellspring of scientists and technologists — and the people who draw cartoons about them.

I try to ease my fears of the future by telling myself there will always be people who acquire skills for purely intrinsic reasons: perhaps for the love of learning, the thrill of the challenge, that sort of crap. Surely, I say to myself, people can’t be so shallow that they work only for money. I am highly persuaded by my own arguments until I talk to any other human being.

I recently gave a speech to managers of a fast-growing Silicon Valley company. Before I began, the CEO pulled me aside to tell me about the audience. He said they had all become rich from company stock options and didn’t need to work anymore. The CEO explained that the managers stayed on because they were intrinsically motivated to make the world a better place.

I was happy to be surrounded by such altruism. It gave me a tingly sensation that lasted almost two minutes, until one of the managers — not knowing what the CEO had just told me — pulled me aside to give his analysis of the audience. He explained that although everyone there had made a bundle of money, they were all still greedily pumping the cash cow with both hands — and in some cases lips — eager to exit early with the maximum possible net worth. He explained that none of them wanted to risk running out of money after leaving because if that happened, they might have to return to work at the hellhole they left. I asked about his higher purpose, to make the world a better place. He laughed. Intrinsic motivation exists, but when you’re predicting the future of corporate America, follow the money.

Clearly, any change in how kids perceive the future will influence how they prepare for it. In fact, the current shortage of engineers is sometimes blamed on me. According to some pundits, kids read the Dilbert comic strip and decide they don’t want to spend their life confined to cubicles and being menaced by pointy-haired bosses. I don’t know if that’s true, but it does pass the sniff test. According to the parents who e-mail me, a lot of family conversations are beginning with the question, “Mommy, what’s a mission statement?” and ending with the entire family in tears.

Prior to Dilbert, people prepared for corporate America without really knowing what it would be like. Today kids have Dilbert to guide them. I like to think I have steered people away from unpleasant corporate jobs, thus contributing to the entrepreneurial boom. But maybe I’ve reduced the number of future engineers below the level needed to maintain technology, thereby condemning civilization to a second Dark Age. (When my parents ask me what I’ve been doing lately, I rarely mention that part.)

There are bright spots in the work force of the future. I predict that some people will be born so smart that they can change the world without much effort. Motivation won’t be an issue for people who are so smart that everything is easy for them. I call it the Redmond effect.

Since the dawn of humankind, there have always been geniuses born to the general population at random intervals. But geniuses have rarely married other geniuses because there were so few and it was unlikely they would meet. Until recently, people married whoever lived nearby and wasn’t a relative. And if your cousin’s parents were willing to give you a fine-looking goat, you would be flexible on the relative issue too. Not that it mattered, since the demand for geniuses was low. But lately the demand for geniuses is growing exponentially, along with their breeding opportunities, thanks to the technology industry.

Like giant vacuum cleaners, Microsoft, Hewlett-Packard, Intel and companies of their kind have been sucking up the brightest people in the world and shipping them to breeding grounds in places like Redmond, Wash. For the first time in history, large numbers of fertile geniuses are living in the same places. The Redmond offspring won’t all be geniuses of course; someone has to marry the beautiful people in marketing. But many of the Redmond kids will be frighteningly smart mutants. There’s no telling how far this evolutionary shortcut can go. Each generation of geniuses will be smarter and start working younger. It’s possible that the high-tech companies of the future could be managed entirely via inter-fetus telepathy. Some entrepreneurs will cash out their stock options and retire before they are born.

O.K., maybe not. But one thing is certain. The demand for skilled employees — especially technology people — will outstrip the supply for the next hundred years. Managers won’t be able to tyrannize their rare and valuable technology experts. The balance of power will continue to shift. In the next generation, engineers will rule the corporate world.

I look forward to that day. We’re already seeing the first signs of this power shift. In many companies, engineers wear casual clothes while their managers wear uncomfortable business clothes. By analogy, when you see an organ grinder and his monkey, it’s always the monkey who has to wear the uncomfortable red vest and hat. If the monkey had the power, he’d be wearing Dockers. That’s all you need to know.

In the corporate future when engineers consolidate their power, cubicles will still exist, because they’re very space efficient. Engineers appreciate efficiency. But unlike the sterile boxes of today, every cubicle will be a technology wonderland customized for the occupant. Flat-panel screens on each wall will give the impression you are in a hot-air balloon floating over the Alps. Noise-cancellation technology will block out the surrounding sounds while providing a symphony within the cubisphere. The computer will continue its evolution to a full entertainment center, providing a constant supply of first-run movies, live nudity, gambling and video conferencing. The engineer’s chair will be soft and warm, conforming to the body and providing simulated motion and vibration to match the entertainment. The cubicle experience will be so much better than life on the outside, engineers won’t want to leave. That could be a problem.

I heard about an experiment where rats were given the choice between food and cocaine. They chose the cocaine until they starved. The same thing will happen to the engineers. I predict they’ll all starve to death inside their cubicle wonderlands.

I just hope no one blames me.

Dilbert clearly has a lot to answer for.

(If the humor’s not your thing and you’re considering a career in systems analysis, you might want to have a look at this quiz: “Should You Become a Computer System Analyst?“)

As a systems analyst, you may design new systems, including both hardware and software, or add a new software application, to harness more of the computer’s power. Most system analysts work with specific types of systems-for example, business, accounting, or financial systems, or scientific and engineering systems-that vary within the organization and industry. Some system analysts are known as systems developers or systems architects.

Firms and candidates, in this industry, provide services related to the commercial use of computers, mostly on a contract basis, including custom computer programming services; computer systems integration design services; computer facilities management services, including computer systems or data-processing facilities support services for clients; and other computer-related services, such as disaster recovery services and software installation. They also work with Internet service providers, web search portals, and data-processing, hosting, and related services firm, government, manufacturers of computer and electronic products, insurance companies, financial institutions, and universities.

Required technical skills can include knowledge of PL/SQL, Oracle, SQL Server 2000, MS-Access – Crystal Reports, Windows Server 2000/2003, Windows 2000/XP, Visual Basic, Microsoft.net MS -Office; Experience with enterprise finance and/or HR software systems; combined with demonstrable proficiency in producing appropriate, effective documentation are considered prerequisites for success in this field. Preferably, a BS in Computer Science, MIS or related area supplemented by a minimum of 5 yrs previous experience and/or training, that includes computer programming, systems analysis, computer operations and hardware/software troubleshooting, can enable you to find challenging opportunities in this field.

Candidates with a 2-year degree, to a graduate degree, face the most favorable job-prospects and estimated growth is anticipated in the foreseeable future. Employment is expected to increase much faster than the average, as organizations continue to adopt increasingly sophisticated technologies.

As highly trained skilled knowledge workers and information technology experts, they will be in demand. Some of the main duties and tasks include: design and development of new hardware and software systems, incorporating new technologies, new areas of specialization or changes in technology is prevalent.

Typically seeking to work in offices or laboratories, in comfortable surroundings and even pursuing tele-commuting or self-employment, contract and project-work, working independently as contractors or consultants, are all viable options. A 40-hour work week is typical, but more and more weekend, evening and deadline-related, project-work, characterize the modern technology-driven environment. Other risks specifically to watch for, would be susceptibility to eyestrain, back discomfort, as well as hand and wrist problems such as carpal tunnel syndrome or cumulative trauma disorder.

The number of job openings currently exceeds the number of job seekers. Many new entrants are recent graduates

To enhance your professional knowledge and broaden your opportunities, consider:

• Keeping constantly updated in your specialty
• Improving interpersonal skills
• Setting standards and guidelines for safety/operations
• Learning business management
• Finding out about international networks

Also, be sure to check regularly for opportunities in the marketplace.

For systems analyst, programmer-analyst, and database administrator positions, many employers seek applicants who have a bachelor’s degree in computer science, information science, or management information systems (MIS). MIS programs usually are part of the business school or college and differ considerably from computer science programs, emphasizing business and management-oriented course work and business computing courses. Employers are increasingly seeking individuals with a master’s degree in business administration (MBA), with a concentration in information systems, as more firms move their business to the Internet.

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.”