Outsourcing is gaining momentum not only as a way to reduce costs, but as a way to create global teams. This trend is driving an increase in demand for business analysts. The change in perspective is driving companies to think about how they manage their business in new ways, and driving interest in new tools for business analysts to achieve these goals.

Hat tip to Ryan for his article on the year of the BA. The source that Ryan found is this yahoo article on 7 trends for 2007.

Trends

The role of the business analyst has emerged as a focal point for enterprises trying to wring more out of their automation-technology investments.[...] Ironically, outsourcing is feeding a frenzy to bring aboard more analysts. The experience of outsourcing IT has taught firms their technology-project specifications were in much worse shape than they believed. When companies would deliver specs to outside firms and individuals who didn’t have deep experience with their existing automation solutions, the knowledge gaps became painfully apparent.

Neal McWhorter, in the Yahoo article (emphasis ours)

We’ve all talked about outsourcing, and many of us have designed teams with different collaboration models to address the communication challenges.

This Computerworld article suggests that business analysts are one of 5 top areas for hiring, and business process management is one of 5 top technologies being explored.

How Business Analysts Adapt

Neal suggests that BAs will evolve their role and responsibilities to be something analogous to a product manager. We’ve been treating the roles similarly here – with the primary distinction being a single-customer focus for business analysts.

Neal mentions the IIBA and their new certification program as a likely means of setting expectations of and for business analysts. Barbara writes about the upcoming certification schedule for 2007.

Tools

We can’t overemphasize the need to be good at writing requirements first, and then using tools to become more efficient second. With that said, the increasing importance of business analysts drives the increasing importance of helping BAs be more effective.

Two areas where there are huge opportunities for improvement are business process modeling and requirements gathering/management.

BPMN

There are tools and vendors for BPMN solutions, and it looks like training is finally going to be more available in 2007. Bruce Silver is developing training that uses ITP Commerce as a tool provider. We’re currently designing a training course as well, built by extending the tutorial series we wrote last year, using visio stencils and a vendor-agnostic approach.

Requirements Management Software

Today, the space can be characterized as having the following solutions available:

• Spend a lot on an enterprise package, and mandate that all your projects use it, in order to recover the costs.
• Build your own solution, using spreadsheets, documents, email and other tools.

We expect this to change in 2007 too. Both of the approaches above can be cost ineffective for single-projects within a large company, SMBs looking to become more effective, and small consulting shops providing services to other firms. There’s a lot of opportunity here for the right solution.

Conclusion

Is it the year of the business analyst? The need is indisputable. Will the C-level execs act on it?

The BABoK (Business Analyst Body of Knowledge) lists 10 techniques for gathering requirements. Here’s an overview of each one. For more details, check out the latest Guide to the BABoK.

1. Brainstorming
2. Document Analysis
3. Focus Group
4. Interface Analysis
5. Interview
6. Observation
7. Prototyping
8. Requirements Workshop
9. Reverse Engineering
10. Survey

1. Brainstorming

Brainstorming is used in requirements elicitation to get as many ideas as possible from a group of people. Generally used to identify possible solutions to problems, and clarify details of opportunities. Brainstorming casts a wide net, identifying many different possibilities. Prioritization of those possibilities is important to finding the needles in the haystack.

2. Document Analysis

Reviewing the documentation of an existing system can help when creating AS-IS process documents, as well as driving gap analysis for scoping of migration projects. In an ideal world, we would even be reviewing the requirements that drove creation of the existing system – a starting point for documenting current requirements. Nuggets of information are often buried in existing documents that help us ask questions as part of validating requirement completeness.

3. Focus Group

A focus group is a gathering of people who are representative of the users or customers of a product to get feedback. The feedback can be gathered about needs / opportunities / problems to identify requirements, or can be gathered to validate and refine already elicited requirements. This form of market research is distinct from brainstorming in that it is a managed process with specific participants. There is danger in “following the crowd”, and some people believe focus groups are at best ineffective. One risk is that we end up with the lowest common denominator features.

4. Interface Analysis

Interfaces for a software product can be human or machine. Integration with external systems and devices is just another interface. User centric design approaches are very effective at making sure that we create usable software. Interface analysis – reviewing the touch points with other external systems – is important to make sure we don’t overlook requirements that aren’t immediately visible to users.

5. Interview

Interviews of stakeholders and users are critical to creating the great software. Without understanding the goals and expectations of the users and stakeholders, we are very unlikely to satisfy them. We also have to recognize the perspective of each interviewee, so that we can properly weigh and address their inputs. Like a great reporter, listening is the skill that helps a great analyst to get more value from an interview than an average analyst.

6. Observation

The study of users in their natural habitats is what observation is about. By observing users, an analyst can identify a process flow, awkward steps, pain points and opportunities for improvement. Observation can be passive or active (asking questions while observing). Passive observation is better for getting feedback on a prototype (to refine requirements), where active observation is more effective at getting an understanding of an existing business process. Either approach can be used to uncover implicit requirements that otherwise might go overlooked.

7. Prototyping

Prototypes can be very effective at gathering feedback. Low fidelity prototypes can be used as an active listening tool. Often, when people can not articulate a particular need in the abstract, they can quickly assess if a design approach would address the need. Prototypes are most efficiently done with quick sketches of interfaces and storyboards. Prototypes are even being used as the “official requirements” in some situations.

8. Requirements Workshop

More commonly known as a joint application design (JAD) session, workshops can be very effective for gathering requirements. More structured than a brainstorming session, involved parties collaborate to document requirements. One way to capture the collaboration is with creation of domain-model artifacts (like static diagrams, activity diagrams). A workshop will be more effective with two analysts than with one, where a facilitator and a scribe work together.

9. Reverse Engineering

Is this a starting point or a last resort? When a migration project does not have access to sufficient documentation of the existing system, reverse engineering will identify what the system does. It will not identify what the system should do, and will not identify when the system does the wrong thing.

10. Survey

When collecting information from many people – too many to interview with budget and time constraints – a survey or questionnaire can be used. The survey can force users to select from choices, rate something (“Agree Strongly, Agree…”), or have open ended questions allowing free-form responses. Survey design is hard – questions can bias the respondents. Don’t assume that you can create a survey on your own, and get meaningful insight from the results. I would expect that a well designed survey would provide qualitative guidance for characterizing the market. It should not be used for prioritization of features or requirements.

This is a bit of a potpourri post. Found some good stuff out there today, check it out.

The first IIBA Exam just finished in Orlando Florida. Barbara was one of the 16 business analysts who took it. Read about her experience!

Her post has inspired me to crack open my copy of the BABoK again, so here’s some great stuff that other people have written recently:

Understanding The Goal by Marcus Ting A Kee

Marcus presents what reads like a fantastic real-world example, even though he starts with “Suppose a client…” Real or imagined, it is a great example, well written. A single idea, presented crisply. Great quick read.

A couple presentations by Kevin Brennan hinting at changes for the next version of the BABoK. In the BA Fundamentals presentation, Kevin presents the definition of a business analyst in a really interesting way. He starts on p9 with the complete definition:

A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

This definition feels pretty heavyweight (although rigorous), and it reads like an eyechart but check out what Kevin did on slides 12 through 19. Great way to present the fact that BAs do a bunch of things, and the quote above is already a shortened description of everything we do. Criticism retracted. I would like to figure out a more concise way to describe the BA role, but nothing comes to mind at the moment.

The IIBA (International Institute of Business Analysis) has just released version 1.6 of A Guide to the Business Analysis Body of Knowledge, or the BA BOK. This new release adds over 100 pages of content and is the first “essentially complete” version.

The IIBA was founded in 2003 with an exciting charter:

The IIBA is the independent non-profit professional association serving the growing field of Business Analysis. Whatever your role — requirements management, systems analysis, business analysis, requirements analysis, project management, or consulting, if you are involved in analysis for systems, business or process improvement, IIBA can help you do your job better.

The BA BOK

The business analysis (BA) body of knowledge (bok) is a massive 329 page pdf ebook available at the IIBA home page (pdf direct), that strives to include “everything” needed for the very broad role of business analysts.

The Business Analysis Body of Knowledge is the sum of knowledge within the profession of Business Analysis and reflects what is considered currently accepted practice. As with other professions, the body of knowledge is defined and enhanced by the business
analysis professionals who apply it. The BOK describes Business Analysis areas of knowledge, their associated activities and tasks and the skills necessary to be effective in their execution.

BA BOK 1.6 http://www.theiiba.org

Joining

The IIBA costs $95 per year in annual membership dues. There is an online forum for the IIBA.

End

Since we just pointed you to 329 pages to read over the weekend, we won’t write any more in this article. Have a great weekend!