Career as a Business Systems Analyst

A long time ago, before Business Analysts existed, it was believed that people in the business would be able to define their own requirements.  When a business department wanted to have a new piece of software, they would go to the IT department and the developers would ask them what they wanted. The business people would express this as best they could by writing down lists of things and having meetings to explain them, and then the IT department would build or buy whatever they seemed to want.
 

The business analyst's job has changed this year -- and so have the critical skills that companies demand. New research shows that while communication is still key, knowledge of Lean and Agile methods is a must-have as well.

"How do I move into the field of Business Analyst?" or "How do I move up within the field of Business Analysis?" These are common questions heard in today's job market. Whether you are a programmer, a software engineer, a business subject matter expert (SME) who wants to transition into a Business Analyst role,a recent graduate who is trying to determine how to break into the B.A. job market, or your company just one day changed your title to Business Analyst,this article contains a list of 12 things you can do that will help you connect with the vast community of knowledge and resources.

Babies and Business Analysts go through four stages, as they open their eyes and see. 

In Stage 1, with eyes closed, BAs are blind to their organization’s mess.

In Stage 2, as their eyes begin to open, BAs see in black and white: a single process step, template or isolated requirement.

In Stage 3, the mobile movement of the outside world attracts and delights them: industries, methodologies, collaborations and emerging trends.

In Stage 4, they strengthen their muscles: the analytical and creative skills used to facilitate organizational futures and protect their parent enterprise in this new economic climate.

Many business analysts' find themselves in their role quite by coincidence but once there either decide this is a role they love or hate. There are certain requirements (if you'll pardon the cliche) or competencies you must display to be successful in this profession. We will first explore the foundational knowledge and skills needed in the early part of a business analysts' career and then what is required to progress.

A lot of people think that coming up with solutions to business problems is the hardest part about being a business analyst – particularly when working with a client who knows more about the business than you ever will. Don’t believe it, after all you’ve already made considerable progress in understanding the problem – and your understanding is based on level-headed analysis rather than a potentially emotional interpretation by your client.

Now it’s time to look for solutions – to be creative and think outside the square. In this paper we’ll offer a few tips and techniques for getting the creative juices flowing. We’ll show you that anyone can be creative and that solutions can come from the most unexpected places – you don’t have to be a subject matter expert to come up with valid, workable solutions to business problems.

Like all professions, business analysis has its golden rules – rules that are fundamental to the design of successful business systems. They might seem like common sense but it’s surprising how often we forget them and get ourselves into hot water.

Agile is here, and it's coming soon to an organization near you-if it's not already there. As a business analyst, are you ready to make the transition to this value-centered development approach? How will your role change? What will you do differently? What will you actually do as part of an agile team? What agile analysis practices might you adapt if you're working on a traditional (waterfall-style) project?

In short, how can you make yourself more valuable to your agile team and organization using your business analysis skills and abilities?
 

Wyeth CIO Jeffrey Keisling explains how working with the business on IT staffing helps promote IT-business alignment.  He also outlines the two areas of hiring focus: business analysis and business process.

As budgets tighten and organizations continue trying to achieve return on investment faster, cheaper and with better results, they are trying to create and evolve their overall enterprise architecture.

In recent years it has become more and more apparent that the job description of Business Analyst has become diluted and distorted. Can this be considered the natural evolution of a profession or is it a profession that no longer has a clear job description? Is this a profession that has moved past the point of clear boundaries or are the boundaries still there but blurred based on the need to adapt to a changing world to meet the needs of people rather than the needs of the business? What can we do to win back the respect that the Business Analyst profession deserves? Exactly whose responsibility is it to maintain a professional and respected image of this profession? Should the recruitment process of Business Analysts be an exercise in requirements gathering?

If it is allocating your internal resources, making a new hire, or bringing in a consultant; what is the best process to match the right business analyst to the right project? For organizations that truly value the role of the business analyst this is one of the most frequently pondered questions.

Companies that want to have the right people in the right roles need to address four main stages; defining the BA’s roles in the project, attracting the best talent, matching the BA to the project and finally, making the selection and continuing to support.

If a single word can represent an entire year, then 2008 was the year of change. Of course, the next American president ran an entire campaign on change, but, more specifically, the business world as we know it will simply never be the same. We’ve all learned that no company—no matter how thoroughly it is woven into the fabric of the economy—is isolated from the need for improved efficiency, due diligence and corporate responsibility.

With change having such a profound influence on 2008, 2009 will likely be shaped by the business world’s ability to adapt to that change. And, of all the groups of professionals working today, few will serve a more important role in that adaptation than business analysts. Requirements management and development, which has for so long been the unsung hero of the successful project lifecycle, is poised to begin receiving the prominence it deserves.

Here are 10 key trends to look forward to in business analysis for 2009. They represent the on-going evolution of requirements management and development and the ever-increasing value of the modern business analyst.

If Agile is to become the next zeitgeist for development, what will become of the traditional Business Analyst?

We all know the traditional waterfall mantra: analyze, design, build then test... underpinned by the common belief that the more you analyze up front the more you save in maintenance later on. This has had a huge impact on the way we organize our teams: separating functions and putting a heavy emphasis on theoretical modeling.

When a project kicks off, the classic Gantt chart dictates that analysts are on-boarded early for a lengthy requirements analysis stage. Once the requirements specification is 'signed off' the analysts are often relieved of their posts for the design crew to take over. The 'sign off' fest continues until eventually the user community is (invariably) force fed a UAT phase and the fledgling product is launched; all the while resources are inhaled and exhaled as the project plan demands. The project then becomes more of a way to co-ordinate a set of individual skill sets and activities.

Does it ever feel like no one really appreciates what you do as an architect? It doesn’t matter what you’re designing, the consensus seems to be that what you do is just a lot of planning and thinking. No one seems to understand how much time and effort you have put into understanding every nook and cranny of the business so that your projects succeed not only from a physical deployment perspective, but from an organizational perspective as well. Essentially, your main role is to lay the foundation for your entire organization to succeed in business. Whether that’s from an enterprise, application, Service-Oriented Architecture (SOA), or other architectural design doesn’t matter. Your role is clearly one of the most pivotal in any organization, yet it's also one of the most misunderstood.

I say “one” of the most misunderstood because there is another worker bee in the hive who performs just as many pivotal yet misinterpreted tasks as you: the business analyst. As you work at defining the organization and deployment structures of your design, business analysts work at defining business problems and opportunities and turning them into solutions for customers. In other words, the business analyst is another key role that’s often misunderstood.

The misunderstandings occur because on the surface, it appears that both of you are attempting to do the same job. You—the architect—are undoubtedly the best person to design a practical solution for business requirements that you’re not particularly close to. At the same time that you are designing a solution, the business analyst—arguably the person much closer to those business requirements—is attempting to design a practical solution for them. Ultimately, you both want the same thing: a solution that works for the business and is cost-effective. The problem is that the two of you are coming at that solution from different angles.

Just imagine the possibilities if you and the business analyst learned how to put those angles together to form the perfect square.

Author: S. E Slack