In the first part of this series, we defined the role of Business Analyst (BA) and identified the personality traits generally found in successful BAs. In this part, we'll explore the set of skills a BA needs to handle the ever-changing demands of business in the 21st century. We'll also discuss where to look for candidate BAs within your organization.

Targeting the Required Skill Set

Once the role of Business Analyst has been defined, the next step is to determine the skills required to carry out the role. Although most of the skills a BA requires relate directly to the activity of business analysis, a BA (particularly a senior BA) needs to be well grounded in other disciplines such as project management, change management, time management, and communication.

The required skills can be divided into four different categories:

• Methodology
• Techniques
• Tools
• General skills

Each of these is described in the sections below.

Methodology

These skills cover the understanding of the different components of the business rules methodology and how they fit together. This includes:

1. the benefits of the methodology,
2. the purpose and content of the deliverables,
3. the process to generate the deliverables,
4. the application of the methodology.

1. The Benefits

It is essential for a BA to understand the benefits of the methodology and be able to explain them to both project team members and the business staff who participate in the project. If the benefits are not clear, it is very difficult to generate support for the process.

2. The Deliverables

A BA needs to clearly understand the purpose of the deliverables. This includes knowing:

1. the target audience for each deliverable,
2. the different sections of the deliverable and the purpose of each,
3. the level of detail required for each section,
4. how to tailor the deliverables to meet the needs of a project.

3. The Process

A BA needs to know how to produce the deliverables. This includes:

1. understanding when to use a specific technique (e.g., interviews vs. facilitated sessions),
2. the order in which the deliverables are generally produced,
3. who should participate in the process (e.g., management vs. front-line staff),
4. how to map out a plan for the requirements-gathering process (e.g., steps required, number of facilitated sessions, time required for documentation, etc.),
5. who needs to sign off on the deliverables.

4. The Application

Because each project is different, a BA needs to know when and how to apply the methodology. For example, a project that will change how service is provided to a customer will likely need to focus on workflow, whereas a project that is changing how customers are segmented will likely need to focus on business rules.

A BA must understand the risks of revising or omitting a deliverable and be able to explain those risks to the Project Manager and Project Sponsor.

Techniques

These skills cover how to produce the deliverables. The key techniques include:

• Tactics/Risk Analysis (how to produce a plan of action/Policy Charter)
• Fact Modeling (how to identify business terms, define them, and determine their relationships to each other)
• Workflow Analysis (how to map out the workflow)
• Business Rules Analysis (how to discover, structure, and decompose business rules)
• Business Model Validation (how to cross-check the components of a business model to ensure accuracy and completeness)
• Impact Analysis (how to compare the "as is" and "to be" business models to determine the impacts to the business)
• Project Planning (how to map out a project plan)

Although Project Planning is not an analysis technique per se, it is important for BAs to be able to put together their own plans rather than rely on a Project Manager to do it for them (possibly setting unreasonable deadlines due to not understanding the requirements-gathering process). It is also a good technique to help a BA lay out the approach to the analysis.

Tools

These skills deal with the use of tools to generate the deliverables. The skills include basic tools such as Word, Excel, and PowerPoint as well as specialized tools such as Visio, RuleTrack, or PTECH Framework.^[1]

General Skills

Although these skills are not specific to business analysis, they are required in order to be an effective Business Analyst. Some call for just a general understanding of the skill, while others need to be studied in depth. See Table 1 for the skills and why a BA needs each one.

Table 1. Business Analyst Skills

Skill	Rationale
Business Process Reengineering	A BA needs to understand what a process is and why it is important to design processes from the customer's perspective. He/she should also be aware of the difference between BPR and Business Process Improvement, and when each is applicable.
Business Writing	Communicating complex ideas clearly and concisely is an essential part of a BA's job. The deliverables a BA produces need to be understood by a diverse audience. It is essential that the deliverables be well laid-out, easy to follow, and form a coherent whole. This requires a solid command of the English language and of basic grammar.
Change Management	Fundamentally, BAs are agents of change. As such, it is important to understand the basic concepts of change management, particularly the stages an individual goes through during the change process. A BA should know what to expect as people deal with the change, and have strategies ready to overcome their resistance.
Communication	A BA must be able to explain concepts clearly and listen carefully to others in order to gather business requirements. Also, because a BA is rarely in a position of authority, he/she must often use persuasion to gain support for the business rules approach.
Conducting Walkthroughs	One of the primary means of communication at a BA's disposal is that of the formal walkthrough. The audience may be management, business staff, the project team, Information Technology (IT) staff, or other BAs. Each audience requires a different approach with a different emphasis on aspects of the business model. It is important to know how to organize a walkthrough for maximum effect.
Conflict Resolution	Although I dream about the perfect project where everyone gets along and no issues arise, I have yet to encounter one. It is very useful for a BA to have some effective tactics available to deal with the inevitable conflicts.
Data Management	A BA should have some familiarity with what happens to a fact model once it is handed over to a Data Analyst (DA). The BA needs to be able to communicate the fact model to the DA and ensure that it is implemented as specified. A basic understanding of entities, attributes, and normalization also helps a BA understand what kind of information the DAs need to do their job.
Facilitation	This is a critical skill for a BA. The most effective technique for gathering business requirements is facilitated sessions. A good facilitator is able to solicit much more information from the participants and make it fun in the process.
Interviewing	A BA needs to be proficient in interviewing in order to be able to draw out the correct information, even under difficult circumstances.
Presentation	There are many tips and tricks to making an excellent presentation. A BA needs to know them as he/she is often called upon to make presentations to various groups.
Project Management	Although a BA does not need to know all the ins and outs of project management, he/she should have sufficient knowledge to understand the pressures on a Project Manager. Also, the more a BA can take responsibility for managing the analysis phase of a project, the more control he/she has over timelines, resources, etc. At the very least, a BA should be able to provide input to the Project Manager for the project charter, project plan, and budget.
Research	Whether it is to find out about best practices in a business area, or just to keep up to date on events in the business rules community (e.g., at www.BRCommunity.com), a BA needs to know how to track down information. This includes using the Internet as well as library resources (both internal and external).
Risk Management	A BA needs to be concerned with two types of risk -- project risk and business risk.[2]   It is important for a BA to know how to identify, prioritize, track, and mitigate risks.
Systems Analysis and Design	A BA should have some familiarity with the activities that follow the business analysis phase of a project. He/she needs to be able to communicate the business model to the Systems Analysts (SAs) and ensure that it is implemented as specified. A basic understanding of client/server architectures, object-oriented approaches, and use case techniques also helps a BA understand the kinds of information the SAs need to do their job. A working knowledge of rule engines is also important; a BA needs to understand how the business rules can be implemented.
Time Management	Most BAs work on multiple projects at a time. A BA needs to know how to manage his/her time by setting priorities, keeping tasks on schedule, and using time wisely.

Finding Business Analysts

Now that you've defined the role of Business Analyst, determined what type of person you need to fill that role, and targeted the skills he/she should have, you're ready to form your BA group. You may be in the enviable position of being able to recruit BAs from both inside and outside the organization, or you may have "inherited" an existing group with little or no BA experience.

If you need to recruit (whether initially or over the long term as the department grows), there are a few things to consider.

Firstly, you need to ensure that you recruit someone with the personality traits described in Part 1. If you don't screen for these traits, you may end up with a person who just can't be successful in the role.

Secondly, as the business rules approach is relatively new, you will not likely find experienced BAs, even outside the organization. So be prepared to invest a lot of time and effort in training.

One of the questions I'm frequently asked is whether new BAs should be drawn from the ranks of the business areas or from the Information Technology (IT) department. There are definite pros and cons for each case (see Table 2).

Table 2. Business vs. IT as a Source of Business Analysts

Source	Pros	Cons
Business areas	Has solid understanding of the business Has an established network of contacts in the business areas Is known and trusted by business staff Can talk to business folks in their language	Often has had little or no exposure to any methodology or analytical discipline May have difficulty dealing with IT issues Might not be able to look beyond the way things are currently done
IT department	Usually has had some exposure to methodology Has good contacts in the IT department Often has been involved in multiple projects Can talk to IT folks in their own language	May not be able to make the paradigm shift from a technology to a business perspective Doesn't usually have strong ties to the business areas May have difficulty talking to business staff in their terms

I have worked with some very capable business people who simply did not have any analytical ability — they were never able to master the art of "factoring" information into terms, workflow, and business rules. I have also worked with IT staff who were excellent analysts but did not "get" the business perspective — their view of the world was through tech-colored glasses and they simply were not able to change.

In the end, it comes down to the individual. If the person has the aforementioned personality traits as well as a strong business perspective, then he/she can be trained in the methodology and techniques.

If you are recruiting from a business area, look for the person that everyone goes to for help with business issues. This person is generally able to analyze a problem and find a solution. He/she usually has extensive business knowledge and is well respected. Also, look for someone who has had experience on a project, possibly as a subject matter expert. If the person enjoyed the assignment, it is an indication that he/she might work well in a team environment.

If you are recruiting from the IT department, look for the person that the business folks turn to when they need an explanation in business terms of IT issues. This person often acts as a liaison between the business and IT on projects. He/she also tends to be the one to push for the maximum involvement of the business in the project.

For the sake of this article, we are assuming that you have a Human Resources department to assist you in the recruiting process and so will not deal with that here.

Once you've targeted the skills and recruited the BAs, you're ready to start thinking about how to train them. Tune in to Part 3 of this series, which will show you how to assess the BAs' current skill levels and put together a training strategy.

Notes

[1]  The set of tools required will depend on your organization. Wherever possible, use tools that your Information Technology (IT) department supports -- it greatly simplifies the installation, training and ongoing support.

[2]  Project Risks are defined as exposures in running the project (e.g., resources not available, union rules in conflict with proposed changes in procedures, etc.). Business Risks are defined as continuing exposures on the business side once the "to-be" business solution has been implemented.

References

Lam, Gladys S.W. "Business Knowledge -- Packaged in a Policy Charter," DataToKnowledge Newsletter, Vol. 26, No. 3 (May/June 1998). URL: http://www.BRCommunity.com/a1998/a385.html.

Ross, Ronald G. "Who or What is a True Business Analyst?" DataToKnowledge Newsletter, Vol. 27, No. 2 (March/April 1999). URL: http://www.BRCommunity.com/a1999/a412.html.

Ross, Ronald G. Business Rule Concepts, the New Mechanics of Business Information Systems. Business Rule Solutions, Inc. 1998.

Ross, Ronald G. and Gladys S.W. Lam. The BRS Fact Modeling Practitioner's Guide: Developing The Business Basis For Data Models. Business Rule Solutions, Inc. 2000.

# # #