The Bridge - Fall 2007

theBridge707b

8/20/07

10:23 AM

Page 2

the

CONNECTING BUSINESS REQUIREMENTS TO TECHNOLOGY

Fall 2007

Getting Started Planning for Business Analysis

New Course IIBA CBAP Exam Prep Boot Camp

The Importance of a Requirements Management Plan

Tips on Estimating

Requirements Planning for a COTS Solution

theBridge707b

8/20/07

10:23 AM

Page 3

letter from the editors he year 2007 is shaping up to be another big year for the business analysis community. As the business analysis profession matures and organizations are really seeing our value, Business Analysts are being involved in projects very early, sometimes before there is even a “project” defined. To increase our skill on this early project work, we have dedicated this issue of the bridge to business analysis planning. This is such a broad topic that we have decided to continue it in our next issue. Our main article is the first of a twopart discussion on creating a business analysis work plan. This first part focuses on stakeholder analysis and communication planning.

BARBARA CARKENORD and TINA JOSEPH Additionally, Paula Harris, BA Certified™, from Wells Fargo has written a helpful article discussing the merits of having a requirements management plan and Marla Brus, with 3M Information Technology, provides an insightful article about why it is important to have a requirements plan for a COTS solution. We have also included articles on estimating business analysis time and keeping your stakeholders happy.

The IIBA™ certification program is growing rapidly with exams taking place literally all over the world. In addition to expanding the certification program, the IIBA is working on revisions to the BABOK™ and improvements to its infrastructure and membership system. See page 15 for an article from Kevin Brennan, vice president of the BABOK for an update.

With the excitement of the CBAP™ exam, we are happy to bring you an IIBA CBAP Exam Prep Boot Camp for groups and a study guide for individuals. These products are designed for Business Analysts who are seeking CBAP certification. See page 19 for details about the boot camp and study guide. Visit our website to see a preview of the study guide and our blog to get hints for completing the CBAP application.

The number of BA conferences continues to grow (how high can it go?). In the summer there was a Project World and World Congress for BAs in Boston attended by over 300 PMs and BAs. Spring and summer delivered three BusinessAnalystWorld Regional conferences and symposiums in Washington, DC, Atlanta, and Minneapolis. This fall there will be a World Congress in Anaheim, CA, and a BusinessAnalystWorld in Boston, Chicago, and San Francisco. We hope to see you at one of these locations!

T

TINA JOSEPH

BARBARA CARKENORD

Certified Woman Owned Business The IIBA logo, IIBA, and BABOK are trademarks belonging to the International Institute of Business Analysis.

PMI and PMBOK are registered trademarks of the Project Management Institute, Inc.

We don’t hire positions, we hire great people.

theBridge707b

8/20/07

10:23 AM

Page 4

the Fall 2007

TM

volume 4 l issue 2

table of contents 3

Getting Started: Planning for Business Analysis

by Barbara Carkenord

9

The Importance of a Requirements Management Plan

by Paula Harris

Please send inquiries, suggestions, and address changes to Martha Scott, Editor-in-Chief, mscott@b2ttraining.com.

Editorial Contributors Thank you to all of the companies who contributed articles and assistance for this issue of the bridge.

Design and Production Design: Mendenhall Mitchell Design Print Production: Douglas W. Lesher Printed in the USA ©2007 B2T Training All Rights Reserved.

Reproduction of content is not permitted without prior written permission.

New!

Lost in Translation

14

Book Review

15

IIBA Update

16

Ask the Experts

17

Requirements Planning for a COTS Solution

19

IIBA CBAP Exam Prep Boot Camp

t

The bridge is a publication of B2T Training.

11

Improper Communication with Your Stakeholders can Spell Disaster

A Guide to the Project Management Body of Knowledge

by Project Management Institute

Tips on Estimating Page 3

by Marla Brus

To subscribe to the bridge, please visit www.b2ttraining.com.

B2T Training • 11675 Rainwater Drive, Suite 325 • Alpharetta, GA 30004 • 866.675.2125 B2T Training is a woman-owned business based in Atlanta, GA. We offer a Business Analyst training curriculum that focuses on proven skills and techniques to define and scope the business problem, elicit and analyze requirements, document the requirements, model the requirements, and follow through with the development of business requirements test plans to ensure the project has met its defined objectives.

Our training is offered nationally and on a limited international basis. Most of our classes are taught onsite and are tailored to the unique environments of each organization. Public classes are also available in various cities around the US. CEO Tina Joseph

President Barbara A. Carkenord

Vice President Angie Perris

the bridge l Fall 2007 2

theBridge707b

8/20/07

10:23 AM

Page 5

Getting Started Planning for Business Analysis Ready…Set…Go!

BY BARBARA A. CARKENORD,

, CBAP

PRESIDENT, B2T TRAINING, BABOKTM CORE TEAM

ou’ve been assigned to a new project and you are anxious to prove the value of your role as a Business Analyst, how do you get started?

What should you do first? Who are you going to talk to? What are you going to produce? How long will this take? One way to help answer these questions is to create a business analysis work plan. This plan will help you:

Y

• Develop a clear approach to your business analysis work.

• Estimate the amount of time required to complete the work.

Taking a few minutes up front, even on a small project, will result in a big payoff for the team because it will set expectations about what will be done and how much time the analysis work will take.

Without a plan, some stakeholders may not understand why you need so much time to complete your work. Many people do not realize that business analysis work involves a lot more than just “gathering” the requirements. In addition, if you have a structured plan and approach to eliciting, analyzing, documenting, reviewing, and validating your requirements you are less likely to miss any major requirements or stakeholder areas. You are also less likely to go down the wrong path and build the wrong solution for the business problem at hand.

Business analysis planning should be done for every assignment but it doesn’t have to be a huge, time consuming burden. Planning your work will become second nature as you work on more and more projects. Many of the planning tasks can be done very quickly; some may require a little research and investigation. A “business analysis work plan” may exist only in the mind of the

theBridge707b

8/20/07

10:23 AM

Page 6

BA or may be documented formally. The important thing is that the BA thinks about how her goal will be accomplished before she begins the work. This is so critical in business analysis work because the work is not concrete or well defined. When BAs say that they are going to do some “analysis,” it is unclear what work they are going to do and what results they are going to produce.

When BAs receive a new assignment, we are at a “starting line.” We are expected to start running towards the finish line even though no one knows exactly where that line is. Business analysis planning suggests that we pause for a moment, look for the finish line, and then take the most direct route.

Regardless of the project size the business analysis work plan should include three sections: • Stakeholder analysis and communication planning • Clear definition of the project scope and tasks to be performed by the BA • A list of the deliverables that will be produced

The result of an excellent plan is that you will be able to estimate the amount of time and the stakeholder resources needed to complete the work.

planning your work. While both the PM and BA participate in the development of stakeholder analysis and communication planning, the BA concentrates on these from a requirements perspective.

See the note below about project plan components for a breakdown of planning work between the PM and the BA. Planning for business analysis work is so important and there are so many different aspects to it that it cannot be adequately covered in one article. This article, the first in a two-part series where we will discuss some of the suggested planning work that BAs should perform, focuses on two components of a business analysis plan: stakeholder analysis and communication planning.

The important thing is that the BA thinks about how her goal will be accomplished before she begins the work.

Developing a business analysis work plan is iterative. Pieces of it will be drafted and it will continue to develop as each section is refined. The amount of time spent and the formality of the business analysis work plan will be directly dependent on the type, size, and criticality of the project.

Before you can even think about planning, you must review any work that has already been done. If there is a project charter or project initiation statement, you have a starting point. If these documents are not available, draft a one or two sentence statement of purpose for the work as you understand it. You should verify this with your project manager and/or executive sponsor as soon as possible and then start

Project Plan Components Important note about project management: Ideally the BA and PM work together to develop an overall project plan. A project plan is larger and broader than a business analysis work plan. The project plan includes a work breakdown structure for all of the tasks and dependencies required to complete the entire project. It also contains plans for managing risks, costs, quality, human resources, etc. The business analysis work plan contains only those components that involve business analysis work. The Fall/Winter 2005 issue of the bridge, pg 11, included an article about scoping your project from the perspective of the PM and BA. This pie chart highlights some of the planning components for which the BA and PM are responsible.

Business Analyst Plan Components

Project Management Plan Components

Stakeholder Analysis and Communication Planning People are the most important component of any project. The BA needs to identify all of the people with whom she will be working (the stakeholders). The PMBOK™ defines the word stakeholders

Business Analysis Plan Components n Stakeholder analysis for business analysis - RACI for the requirements n Communication planning for business analysis n Requirements resource needs n List of requirements deliverables n List of other deliverables (UAT, training, etc.) n Business analysis task list n Business analysis schedule with estimated completion dates Project Management Plan Components n Project charter n Human resource planning n Stakeholder analysis - RACI for the project n Communication planning for the project n Cost budgeting n Change management planning n Risk management planning n Quality planning n Work break down structure n Activity resource estimating n Project schedule with estimated completion dates

the bridge l Fall 2007 4

theBridge707b

8/20/07

10:23 AM

Page 7

to include anyone who will be impacted by or can impact the project. For the BA, a more narrow definition would be anyone who is impacted by or can impact the requirements. This may include SMEs, software users, the executive sponsor, outside customers, vendors or suppliers, solution providers, quality assurance staff, technical writers, and anyone else who has anything to do with the project. List everyone that you can think of. Start your list immediately and continue to add to it as you develop your business analysis work plan.

By creating a list of stakeholders you are starting an activity commonly referred to as stakeholder analysis. This is a phrase that is also used by PMs. It is a critical component of planning because carefully considering all of the people involved with a project is one of the techniques that helps ensure success.

Stakeholder analysis involves thinking about each stakeholder or stakeholder group in terms of several characteristics.

These characteristics will help you decide which elicitation techniques will be most appropriate and how best to communicate with each stakeholder. Some characteristics are objective (factual) and some are subjective.

Exhibit 1 (below) lists some example objective stakeholder characteristics. These characteristics will help with scheduling requirements gathering sessions and developing your elicitation questions.

There are also characteristics about each

stakeholder that are subjective. Exhibit 2 (below) lists some example subjective stakeholder characteristics. Use discretion before documenting sensitive subjective stakeholder characteristics. These are important considerations in developing the

be most effective to ask questions one-onone or in a group? Will it be useful to meet with stakeholders from different levels of the organization at the same time or independently? Will it be productive to bring stakeholders from different areas of

Exhibit 2: Subjective stakeholder characteristics Characteristic

Reason this is important

Value to the organization

If this stakeholder group is the main talent/revenue generator of the organization, it will be treated with more respect/kid gloves than other stakeholders.

Culture/language

Understanding the native language and culture of each stakeholder will help the BA improve communications.

Be careful not to offend stakeholders in various cultures.

Learn local customs whenever possible.

Relationship to other stakeholders

If there are negative issues between stakeholders, plan more time for building consensus.

Emotional commitment to the project

If the stakeholder is not excited about a change, plan more time for requirements elicitation and organization change management.

Technical team skill level

If a developer on the team does not have much knowledge in the solution technology, plan for more detailed functional requirements.

Ability/speed of decision making

Understand if this stakeholder is comfortable making decisions quickly or takes more time and thought to come to a conclusion.

business analysis work plan but should often remain only in the mind of the BA! Use these characteristics to draft an initial communication plan. For each stakeholder or stakeholder group, what will be the best communication approach?

Think about which elicitation technique(s) will be appropriate (i.e., interviews, surveys, facilitated sessions). As you think about each stakeholder, ask yourself: Will it

the organization together or meet with them separately?

Exhibit 3 (page 7) shows a partial communication plan. The decisions about how best to communicate also depend on the number of stakeholders in the group, their physical location, their business area, and their time available for work on the project. The IIBA BABOK Knowledge (Continued, see Planning page 7)

Exhibit 1: Objective stakeholder characteristics Characteristic of the stakeholder

Reason this is important

Physical location

Location will affect face to face meeting availability. The time zone will affect meeting schedules.

Availability for project work

If the stakeholder is only available for the project a few hours a week, the project schedule must reflect this limitation.

Subject matter expertise

The level of expertise of the stakeholders will help determine how much of their time is needed for elicitation, reviewing, and approving requirements. This will also help formulate questions.

Technical team experience

If a developer on the team has never worked with formal requirements before, plan to spend time doing walk throughs explaining detailed needs.

External vs. internal

External stakeholders may not be allowed access to confidential information.

Experience on previous projects

If the stakeholders have had good experience working on previous projects they will be very helpful. If they have had bad experiences or no experience they may need more time to learn the process.

Level of formality

Some stakeholders will like casual communications/notes, while others will prefer very formal, documented work products.

Decision making authority

Does this person have authority to make decisions for this project?

Preferred mode of communication

Does this stakeholder prefer talking on the phone, using instant messaging, or face to face conversations?

5 Fall 2007 l the bridge

theBridge707b

8/20/07

10:23 AM

Page 8

theBridge707b

8/20/07

10:23 AM

Page 9

Exhibit 3: Partial Communication Plan Stakeholder Group

Impact on requirements

Executive Sponsor

Final signoff on project objectives and high-level design

Best communication approaches Executive summaries High-level presentations

New product development

Main source of detailed business and functional

Facilitated sessions to elicit business requirements

(Managers and supervisors)

requirements

Review sessions to validate requirements

Customer service representatives IT developer

Main users of software

Usability testing (observation)

UAT participants

Formal training on software changes

Uses functional requirements to make

Walkthrough requirements

the software changes

Review unit test results

(Planning, continued from page 5)

Area: Requirements Elicitation contains a great description of several commonly used elicitation techniques. The communication plan will also include requirements responsibility (i.e., RACI – responsible, accountable, consulted, informed) and estimated time needed from each stakeholder.

Work with other BAs on your project and your PM as you develop your communication plan. Your first draft will be based on knowledge about your stakeholders but the plan cannot be finalized until you make decisions about which requirements deliverables will be created. There are many options available

for presenting requirements: textual descriptions, data models, workflow

during which we take time to think about all of the project stakeholders and consider individual situations and concerns. When we understand the people from whom we will be eliciting requirements, we will be better able to effectively derive the true requirements and solve the true business problems. Having a communication plan shows management how we plan to use stakeholder time; an expensive corporate resource. The second article in this series will be in the next issue of the bridge. It will discuss the remaining components of the business analysis work plan: identifying the tasks to be performed by the BA, and a list of the deliverables that will be produced. n

Understanding business stakeholders and technical stakeholders is a critical first step in planning for project success. diagrams, use cases, etc. Deciding which deliverables are appropriate for the project will be covered in the second article in this series.

Summary Because BAs work to solve business problems, understanding business stakeholders and technical stakeholders is a critical first step in planning for project success. Stakeholder analysis is the activity

“It happened to me . . .”

The most knowledgeable SME on my project was a person who explains things very quickly and gets frustrated when he has to slow down and re-explain procedures to people who learn less quickly. My first strategy for requirements elicitation with this stakeholder was to schedule individual interviews so that he could talk as fast as he wanted! But our methodology dictates that we do prototyping/screen storyboarding when designing new screens so I had to conduct JAD (joint application design) sessions. My communication plan for the stakeholder included a couple of initial individual interviews and then participation in the facilitated sessions. I tried to accommodate his fast pace as best I could while still getting input from the rest of the stakeholders.

– Anonymous BA BA readers of the bridge would like to hear your experiences. Send business analysis experiences that you would like to share, in 100 words or less, to thebridge@b2ttraining.com.

Submit an article to the bridge!

7 Fall 2007 l the bridge

The bridge is published twice a year and focuses on a particular area of interest within business analysis. Articles relevant to the topic area are preferred; however, any articles about best practices, project success stories, or BA resources (books or tools) will also be considered. Submission deadline for the 2008 spring issue is January 29, 2008. To submit an article send an email to mscott@b2ttraining.com.

theBridge707b

8/20/07

10:23 AM

Page 10

Coming Spring 2008

3 Days

Planning Skills for the Business Analyst This course leads students through the development of a structured business analysis plan. BAs create a strategy for their approach to eliciting, analyzing, documenting, reviewing, and validating requirements. With a business analysis plan the BA is less likely to miss major requirements or stakeholder areas. The team is less likely to go down the wrong path and build the wrong solution for the business problem at hand. This course will help BAs plan for and estimate the business analysis effort for various types of projects and situations.

Course Outline Introduction – 1 hr • Business analysis planning • Overview of business analysis planning activities • Discuss the relationship of the PM and the BA in planning • Use of the people, project, and process approach to planning • The business analysis work plan • Getting started – a checklist to assess the project and to help get started Project - Understanding the project characteristics – 3 hrs • Project characteristics – What is the business impact? (size, importance, risk) • Project initiation documentation – Is the project clearly defined?

• Enterprise analysis – understand how this project fits into the organizational strategy • Group workshop – assess the business impact of a sample project People - Stakeholder Analysis and the Communication Plan – 4 hrs • Why plan for stakeholder interactions?

• Assess the project executive sponsor • Identify both primary and secondary stakeholders • Determine effective communication practices for each stakeholder group: • Which elicitation technique(s) will be most effective?

• What requirement presentation format will be most comfortable for each group?

• Establish the communication plan • When and where will communications be most effective?

• What are the best communication techniques for each stakeholder?

• Group workshop – identify and analyze the stakeholder groups for an example project and develop the communications plan

Intended Audience This course is intended for anyone who is interested in learning a practical approach to planning the business analysis tasks necessary for their projects.

Prerequisites BAs registering for this course must have attended Essential Skills for the Business Analyst, or have at least 2 years experience in requirements elicitation, analysis and documentation, using structured techniques. Contact B2T Training if you would like to pass out of these prerequisites.

Process - Planning the analysis activities – 3 hrs • Identify which sections of the requirements package are necessary • Consult organizational standards/ methodologies for required deliverables • Develop a list of deliverables for the project • Develop a list of business analysis tasks for the project • Review requirements planning template • Develop the requirements management plan • Group workshop – develop a task list of analysis and requirements activities for a sample project

Advanced Project Initiation Requirements – 3 hrs • Learn techniques to identify strong project objectives • Learn a technique to help SMEs scope a project with unclear boundaries • Learn to assess a project request and select the appropriate requirements components Estimating the analysis time – 3 hrs • Using past history to predict analysis time • Reviewing estimation techniques (by stakeholder, deliverable, and business objective) • Identifying negotiation areas • Getting signoff on the plan • Baselining the plan and initiating change control Planning for different types of projects – 3 hours • Enhancement or maintenance projects • COTS (commercial of the shelf software) project • Outsourced or off-shore development project • A project using a RUP style/iterative style development methodology • Large development project • Reporting or data warehouse project • Process improvement effort • Infrastructure upgrade the bridge l Fall 2007 8

theBridge707b

8/20/07

10:23 AM

Page 11

The Importance of a

Requirements Management Plan “To some a new concept… to others a path to a successful project”

BY PAU L A H A R R I S,

, W E L LS FA RG O HO M E M O RT GAG E , S E RV I C I N G P RO J E C T M A N AG E M E N T O F F I C E

Definition of Requirements Planning What is requirements planning?

Requirements planning, in my own words, is a strategy or roadmap of how requirements will be managed over the life of a project.

Importance of Requirements Planning The importance of gathering requirements before implementing huge initiatives has

Analyst will meet with different members of the project team to gather their needs and features. In the past this portion of the project may be glossed over because the solution was already in mind.

Requirements are the foundation of any project and can determine the fate of its success. Taking the time upfront to be thorough can eliminate pain in rework during later stages of the project. I’m sure, if you are a Business Analyst or even a Project Manager you can remember

assumptions, risk assessment, version control, approval processes for any documents, and any other pertinent information that relates to the requirements. In my experience the RMP not only includes ideas from the BA, it also includes any ideas that the project team may have concerning requirements planning. Even though the BA might “own” the document, input from others is helpful. Since the RMP is created for the entire project team, getting team members’ input allows them to feel a sense of RMP ownership.

Now, how does a BA create a useful RMP? The effectiveness of any RMP is driven by the project team.

Investing time up front in requirements planning on a project will save time and pain later in the analysis and design phases. become a focus area in many organizations.

It has been, in some organizations, common practice to develop an idea for a project and implement a solution in the quickest way possible. In most cases the problem that a project is trying to solve is so badly strained that a new solution is needed almost immediately. This tactic is more reactive than proactive. However, organizations are realizing that this method of project implementation is not very effective. If more time is spent in actually planning for the project, some of the failures can be avoided.

Requirements are really not a new concept. The new concept is that organizations are beginning to see value in spending the necessary time to plan appropriately for analysis in each unique project. The plan first starts with a scope, which should set the boundaries for the project. From that point the Business 9 Fall 2007 l the bridge

projects that would have progressed more smoothly if adequate time was spent in planning. According to the BABOK™, the value of requirements planning is to “specify how the business analysis team will conduct its business analysis activities over the life of the project.” While this may seem to be a simple task, often times it is one of the most challenging parts of a project – especially if the project carries a significant price tag.

Creation of a Requirements Management Plan One tool that I have found essential to help aid in requirements planning is the Requirements Management Plan (RMP).

This plan will describe how the business analysis team will conduct its activities.

Some information that is contained in this plan includes: the project scope, project requirements (business needs and features),

Personal Example The timing of when the BA becomes involved in a project can make the creation of an RMP difficult. It would be ideal if the Business Analyst was engaged in every project at the very beginning. Unfortunately that is not always the case. Engaging the BA late in the project makes it more difficult to take the time necessary to create an RMP. An example of a project that did not succeed as expected is one on which I was not engaged at the very beginning. The business was on an aggressive schedule and the deliverables were due within a couple of months from when I joined the project.

Prior to my involvement, an RMP was completed, but was not approved. This caused stumbling blocks on the project because there was no agreement. Things that should have been addressed in the plan were not. During project design we had to

theBridge707b

8/20/07

10:23 AM

Page 12

rework processes, make changes, obtain approvals, and examine roles and responsibilities. Because this particular project had a phased approach, the rework added another level of complexity, further emphasizing the importance of creating an RMP that captures all of the moving parts of the project.

may be extremely visual. In this case, using PowerPoint presentations or Visio diagrams to show the requirements management approach may be ideal.

Best Practices Business Analysts have a tough job.

Requirements planning is not easy. Some of the best practices that have worked for me are as follows: 1. Know your audience.

Hopefully the Business Analyst has met with the business lead or project sponsor to gain an understanding of all stakeholders’ roles on the project. This helps the BA understand their preferred communication styles. For example, some stakeholders on the project team

2. Re-evaluate the strategy during the requirements process.

In some projects, once requirements gathering is started, the BA might see where the strategy can be tweaked, documents might be changed, or adjustments could be made because of cost constraints. As the BA works with the project team more and more it becomes apparent what approaches work best.

3. Leave room for flexibility.

Even though the RMP is a roadmap or strategy, there should be room left for flexibility. Some strategies may appear to be a good idea at first but over time may not be appropriate. This doesn’t mean

you have failed. Actually it shows how discerning you are because you have acknowledged that something needs to be changed to make the project a success.

Okay, I can’t give out all of my secrets.

Last Words Give requirements planning sufficient time in the beginning of a project. Investing time up front in requirements planning on a project will save time and pain later in the analysis and design phases. n Paula is a Senior Business Analyst for Wells Fargo Home Mortgage. She has over seven years business analysis experience and is BA Certified through B2T Training. She works on many large and medium-sized projects.

A “must have” reference tool The Requirements Template Roadmap may be used as a companion to B2T Training’s Requirements Package Template. Using this Roadmap as a guideline or “map” for the requirements templates will help Business Analysts determine:

Provides examples of completed requirements templates.

• What to include in a requirements package • Who should prepare which sections of the package

• When and why the requirements components should be prepared

$19.95 Available for purchase at www.b2ttraining.com.

the bridge l Fall 2007 10

theBridge707b

8/20/07

10:23 AM

Page 13

lost in translation Improper Communication with Your Stakeholders can Spell Disaster

BY A N G I E P E R R I S, V I C E P R E S I D E N T, B 2 T T R A I N I N G ,

nhappy stakeholders - who wants them? Not me. Entire projects can fail when we have not established good working relationships with our stakeholders. Our best intentions to elicit excellent requirements can be “lost in translation.” One thing that I have learned is that project success comes down to a shared vision of project goals which requires people communicating and collaborating throughout the project.

Unfortunately there are many mistakes we can make when it comes to communicating with our stakeholders.

Sometimes no communication is preferred over poor communication. When our communication style is not in sync with our audience, we fail. They will tune us out. For a work session, if we invite the wrong people, too many people, or mix the wrong groups together, we may lose their confidence and cooperation. Impromptu meetings without clear purpose frustrate and confuse participants. Disrespect for stakeholder time away from their daily jobs can create hard feelings. If we cannot relate to stakeholders’ critical needs, suggestions, or “hot” buttons, we are in for a bumpy ride. When we over promise and under deliver our relationships, our requirements, and our projects may end with a big loud thud!

One of the first things we should do is get to know our stakeholders. We need to know which business areas or organizations they represent. Although it is good to make a list of the stakeholder business area interests, we should concentrate more on the people who will be involved on our project rather than the departments.

Individuals often have their own personal agendas. Stakeholders have their unique expertise and each has his or her own preferences, personality, and specific

U

11 Fall 2007 l the bridge

, C BA P, P M P

communication style. Each stakeholder on your project can be a positive or negative force that you need to manage. Below are a few tips to help us work through this challenge: 1. Identify all your stakeholder roles.

Whose views need to be represented on the project?

2. Influence the selection of stakeholders for each role. Do you know people who work in the business area who really know their stuff? Is there anyone who can champion the project? What about those whom you have successfully worked with previously?

3. Learn as much as you can about your stakeholders. You want to understand how often they like to receive communication about the project.

Understand their viewpoints, needs, concerns, and preferred communication styles. Find out their personal agendas.

Will they be positive or negative influences? Be careful with private notes about each stakeholder.

4. Engage your stakeholders early in your project. Carefully manage their expectations from the beginning. Gain consensus from stakeholders about the scope and high level priorities up front.

When they get off track remind them again of the project purpose, objectives, and benefits they will receive. Never over promise and under deliver.

5. Develop relationships of trust and mutual respect.

Do not divulge confidential information that they provide you.

Be sincere in

your interaction, and do what you say you are going to do. Value and respect their time and their knowledge. Be humble. Do your homework. Do not ask silly questions (yes, there is such a thing as a bad question, especially to a not-onboard-yet stakeholder!) Plan well for each work session. Frequently involve stakeholders to validate their requirements.

6. Balance the types of stakeholders you have in any given work session or interview. It’s ok to have resisters (e.g., those resistant to change) and supporters in the same work sessions and on the project. The resisters may challenge you and the others with insights that may help uncover hidden requirements or complex issues. Differing viewpoints on your project help ensure success.

7. Listen carefully to what your stakeholders are trying to say. They can’t always remember to tell you everything you need to know in one sitting. Read between the lines and ask intelligent questions. Watch their body language in face-to-face meetings and listen to their tone of voice on conference calls. Try to hear what they do not say.

Lastly, remember stakeholders are just people like you. Try to put yourself in their shoes to really get to know them. They have their own strengths and weaknesses and they just want to be heard and understood. You can manage their expectations successfully if you plan well, get to know them, engage them early, and really listen to their needs. n

theBridge707b

8/20/07

10:23 AM

Page 14

8/20/07

t

theBridge707b

10:23 AM

Page 15

Upcoming Business Analyst and Related Events

• October 6 – 9, 2007 PMI Global Congress North America – Atlanta, GA – For more information visit www.pmi.org

• November 13 – 16, 2007 Project World & World Congress for BAs – Anaheim, CA – For more information visit www.iirusa.com/projectworld

• October 15 – 18, 2007 Project Summit & BusinessAnalystWorld – San Francisco, CA – For more information visit www.businessanalystworld.com

• Spring 2008 BusinessAnalystWorld – Philadelphia, PA – For more information visit www.businessanalystworld.com

• October 29 – November 1, 2007 Project Summit & BusinessAnalystWorld – Boston, MA – For more information visit www.businessanalystworld.com

• Spring 2008 BusinessAnalystWorld – Minneapolis, MN – For more information visit www.businessanalystworld.com

• November 5 – 8, 2007 Project World & BusinessAnalystWorld – Vancouver, BC – For more information visit www.businessanalystworld.com • November 12 – 15, 2007 Project Summit & Business Analyst World – Chicago, IL – For more information visit www.businessanalystworld.com

B2T Training International Partners

AchieveBlue is B2T Training’s exclusive Canadian partner and licensee.

For training in Canada, contact Mona Mitchell, President, at mmitchell@achieveblue.com or call 416.915.3112.

IndigoCube is B2T Training’s exclusive South African partner and licensee.

For training in South Africa, contact Robin Grace, Principal Consultant, at robin@indigocube.co.za.

Visit www.achieveblue.com for more information.

Visit www.indigocube.ca.za for more information.

13 Fall 2007 l the bridge

theBridge707b

8/20/07

10:23 AM

Page 16

book review A Guide to the Project Management Body of Knowledge, Third edition, PMBOK速 Guide

by Project Management Institute R E V I E W E D BY A N G I E P E R R I S, V I C E P R E S I D E N T, B 2 T T R A I N I N G ,

his issue of the bridge focuses on planning business analysis work for projects and we want to feature a book that serves as a great reference on the topic. Most books about planning are specific to how a project manager plans a project. Project Managers are thought of as the project planners yet Business Analysts must also plan their business analysis work for a project. This is an example of the skills and competencies that Project Managers and Business Analysts share.

The PMBOK may seem like a strange choice for a business analysis book review, but I believe that every good Business Analyst should be familiar with its contents. As a PMP I may be a bit

T

, P M P, C BA P

prejudiced; but I think the PMBOK, similar to the BABOK, is a great foundational reference for the Business Analyst who works closely with the Project Manager.

The PMBOK includes the vernacular that PMPs use throughout the project lifecycle. Understanding the vocabulary of the Project Manager as well as the project management processes and knowledge areas helps the BA to understand not only the PM role, but we can see where our own role needs involvement in many project management processes.

Additionally, the PMBOK has been refined over time and allows us to learn good practices we can leverage in our role to contribute to project success. The PMBOK

Guide provides a great context for how projects can be initiated, planned, executed, controlled, and closed. Although the PMBOK is just a guide and does not provide all the details we may want about certain topics, I find it provides a great overview and introduction to the processes, tools, and deliverables required to initiate, plan, and scope a project.

When we need clarification about project management terms like project charter, work break down structure, management reserve, risk management plan, communications management plan, earned value, contingency, bottom-up or top-down estimating, rolling wave planning, or Gantt chart, the PMBOK is a great reference. n B2T TRAINING RATING: HHH (scale is 1-4; 4 is the best)

New BA Certified We are pleased to highlight the latest individuals who have earned the title of BA Certified since the last issue of the bridge.

To date, we have more than 4,500 people in our program, with over 250 who have completed and received certification. We have an additional 700 candidates who have obtained BA Associate and are in the final stage of the certification process.

Individuals who are BA Certified have demonstrated knowledge and application of business analysis. We congratulate them on their success.

Jane Algard

Deborah DeWanz

Joyce Prebis

Brian Allen

Nancy Famiglietti

Christine Radasch

Jackie Boeding-Tewes

Susan Fancy

Shelley Ruth

Steven Bosso

Helen Fridman

Tim Spears

Mary Lou Bradna

Thomas D. George

Janice S. Stifelman

Timothy J. Broderick

Robin Grace

Carmen Urish

Greg Busby

Chris Keith

Samuel N. Yamoah

Jen Christy

Darrell McMath

Shaohua Zhang

Sarah Condiff

Jared McMurray

Robin Crocker

Cathleen Neag

Victor Cruz

Thanh Nguyen

the bridge l Fall 2007 14

theBridge707b

8/20/07

10:23 AM

Page 17

U P D AT E TM

The “New “ BABOK Revealed

BY K E V I N B R E N N A N , C BA P, P M P, V I C E P R E S I D E N T, B O DY O F K N OW L E D G E , I I BA

T

he BABOK committee is working to finalize the scope of the Business Analysis Body of Knowledge in preparation for a final, stable release toward the end of 2007. Based on the feedback we’ve received, we decided to realign the knowledge areas (KAs) although most of the content will be similar to that in version 1.6.

Business Analysis Planning is the KA that covers how we determine which activities are necessary to perform in order

ensure that we have correctly and completely understood those needs. The task structure of Elicitation is broken down into greater detail since the release of version 1.6 of the BABOK, but the scope of the KA remains much the same.

Requirements Analysis describes how we progressively elaborate the solution definition to enable the project team to design and build a solution that will meet the needs of the business and stakeholders. To do that, we

to complete a business analysis effort. It covers identification of stakeholders, selection of business analysis techniques, the process we use to manage our requirements, and how we assess the progress of the work in order to make necessary changes. Business analysis planning is a key input to the project plan, and the PM is responsible for organizing and coordinating business analysis activities with the needs of the entire project team.

Enterprise Analysis describes how we take a business need, refine and clarify the definition of that need, and define a solution scope that can feasibly be implemented by the business. It covers problem definition and analysis, business case development, feasibility studies, and the definition of a solution scope.

Elicitation KA has been renamed to clarify that elicitation techniques are used for more than defining requirements.

Elicitation describes how we work with stakeholders to determine their needs and

have to analyze the stated requirements of our stakeholders to ensure that they are correct, assess the current state of the business to identify and recommend improvements, and ultimately verify and validate the results.

Solution Assessment and Validation covers the role of business analysis once the project team is ready to propose a solution.

It describes how we assess proposed solutions to determine which solution best fits the business need, identify gaps and shortcomings in solutions, and determine necessary workarounds or changes to the solution. It also describes how we assess deployed solutions to determine how well they meet the original need, enabling businesses to assess the performance and effectiveness of projects.

Requirements Management and Communication is our final KA. It describes how we manage conflicts, issues and changes, and ensure that stakeholders and the project team remain in agreement on the solution scope. Depending on the

15 Fall 2007 l the bridge

complexity and methodology of the project, this may require that we manage formal approvals, baseline, and track different versions of requirements documents, and trace requirements from origination to implementation.

The BABOK committee will work with our expert advisors and conduct surveys to validate this revised structure. Once that is complete, we will publish a detailed description of the new structure and a document that maps the content from 1.6 into version 2. We will then revise existing material and draft new sections to cover the gaps, and put those drafts through a careful review process. Our goal remains to complete and “freeze” the BABOK by the end of 2007 or early 2008.

During this time, the certification team will be planning the necessary work to revise the CBAP exam to incorporate this new structure. The exam will continue to be based on version 1.6 until that work is complete and a new edition is published. While we don’t yet have a firm date, this will not occur until some time in 2008. The date will be announced in plenty of time for prospective CBAPs to ensure they study the correct edition of the BABOK. If you’re currently planning to take one of the scheduled exams, version 1.6 is the only version you need to be concerned with.

It’s been a slower process than we originally planned, but version 2 of the BABOK will be a much stronger and more robust document than 1.6. We can promise that it will be worth the wait, and that it will be a solid basis for building the business analysis profession in the years to come. n Kevin Brennan has ten years experience as a BA in multiple industries, including mortgage banking, auto manufacturing, energy retailing, and regulatory agencies. You may reach him at kevin.brennan@theiiba.org.

theBridge707b

8/20/07

10:23 AM

Page 18

ask the experts Tips for Estimating Question: How should I go about estimating my business analysis work for a project?

Answer: Estimating is not an exact science because you are trying to predict how something will actually happen in the future, made more difficult by the fact that you do not have control over your stakeholders’ schedules and priorities.

There are some guidelines you can follow that will increase your likelihood of being realistic in determining the amount of time the business analysis work will take.

Identifying the tasks to be completed and the deliverables to be created is the first step in estimating the time required for business analysis work. Your best source of time estimates is past history on similar projects. BAs will benefit from keeping track of how much time they spend on individual tasks and using that information on future projects. If you have no historical

information available, interviewing those who have had experience with similar projects is the best way to determine how much time will be needed for each task.

Ask other BAs in your organization for help when you are getting started.

Depending on your organization, your Project Managers may maintain historical information about previous projects and that information may also help guide you through the estimating process.

A common technique for estimating time is the WAVE formula. WAVE (weighted average value estimate) calculates an average value from the best case (BC), worse case (WC) and most likely (ML) estimates: (BC + WC + 4ML)/6.

Creating a complete task list is the first critical success factor in estimating. Include items even if you are not sure that they will be necessary. Anything that you may have to spend time on during the course of the project must be included in this list if you

want your estimate to be realistic.

The second critical success factor is obtaining buy-in from your stakeholders that they will be available on the dates and times that you need their participation.

You can use your communication plan to provide this information to your stakeholders.

A third factor to successfully estimate the business analysis work for your project, is that proper consideration must be given to the project’s unique characteristics, scope, importance to the organization, and risk factors. Also consider the skills, knowledge, and availability of the people who will be eliciting requirements and those who will be providing requirements.

This topic will be covered in more detail in our next issue of the bridge (Spring 2008). n Send your questions to Ask the Experts at sales@b2ttraining.com.

the bridge l Fall 2007 16

theBridge707b

8/20/07

10:23 AM

Page 19

Requirements Planning for a COTS S

BY M A R L A B RU S, P M P, P RO J E C T L E A D / B U S I N E S S A N A LYST, 3 M I N F O R M AT I O N T E C H N O L OG Y

hy do we need to gather requirements on a project when we already know that our solution will be a COTS solution (commercial-off-the shelf )?

I don’t see why we need to spend time gathering requirements. We just need to look at a few vendor offerings and make a quick decision,” commented a Marketing Manager. It was my first week on a high profile project seeking to introduce a new Knowledge Share system across the company. With executive visibility and sponsorship, there was great pressure to deliver the new system quickly. As a result, the business team wanted to eliminate any unnecessary work that would delay delivery of the system.

Effective requirements gathering can help reduce significant project risks.

Whether the solution is a COTS or a custom application development, requirements gathering plays a critical role in successful software development and implementation. In the case of this project, it was important to educate several business team members on the critical role of requirements gathering. To begin educating the team, to gain their support, and to begin requirements planning for the project, I began developing the requirements plan for the project.

“W

Requirements Plan The requirements plan is a communication tool used to help gain agreement on the requirements gathering approach that will be used on a specific project. The requirements plan has two benefits. First, it helps educate non-IT stakeholders how requirements gathering activities fit into the overall project delivery.

17 Fall 2007 l the bridge

Second, it helps Project Managers better understand the requirements work breakdown structure for project planning.

Components of a Requirements Plan There are several components to an effective requirements plan. For a given project, the requirements plan describes: • Requirements gathering objectives • Requirements gathering processes • Roles and responsibilities for requirements activities • Requirements deliverable list • Methods and tools Requirements Objectives Requirements objectives describe the criteria that must be met for requirements gathering to be successful. Expressing objectives in measurable terms helps communicate the overall goals. For example, the objectives for the Knowledge Share system requirements gathering included: • Elicit requirements from 8-12 future end users with experience in different product lines.

• Elicit requirements from 2-3 system stakeholders representing Corporate Research and Corporate Marketing.

• Document desired feature requirements for inclusion in a request for proposal

(RFP) to send to vendors.

• Document detailed system requirements to support the configuration and customization of a COTS package.

Requirements Gathering Process The requirements plan describes requirements management for a given project. Additionally, it describes how requirements gathering is integrated into the overall project plan. One way to communicate this information is to develop high-level process maps for: • • • •

Eliciting requirements Verifying requirements Resolving conflicting requirements Managing requirement changes

Exhibit 1 (below) provides an example of a process flow for eliciting requirements for the Knowledge Share system.

Communicating and sharing these highlevel process maps provides several benefits.

First, the process maps help explain requirements gathering activities and how each activity relates to the other. Second, the process maps help educate team members so they can understand what to expect. Third, establishing a process for resolving conflicting requirements and for managing requirements changes helps the team move to resolution more quickly.

Exhibit 1: Eliciting Requirements for the Knowledge Share System

theBridge707b

8/20/07

10:23 AM

Page 20

S Solution Requirements Resources, Roles, and Responsibilities The requirements plan clearly communicates the resources, roles, and responsibilities needed to make requirements gathering successful. Sharing this information up front, allows stakeholders and team members to better understand their role. One way to communicate this information in the requirements plan is to include a requirements resource plan and a responsibility assignment matrix.

The resource plan describes who needs to be involved and how much of their time is needed. It also indicates whether or not that resource is available to participate.

Exhibit 2 (right) gives a sample resource plan for the Knowledge Share system project.

The resource assignment matrix describes the expected responsibilities of those participating in requirements gathering. Exhibit 3 (below) shows the resource assignment matrix for the Knowledge Share system project.

Requirements Deliverable List The requirements plan should include a list of key deliverables. This helps communicate the work results of the requirement process. It also helps the project manager identify the key requirement milestones for the project

plan. For the Knowledge Share system project key deliverables included vision, system feature list, use case diagram, use cases, graphical user interface specification, and data map.

responsibilities, deliverables, tools, and methods help others better understand the critical role these activities play in the overall project.

About a year after the initial release of

Exhibit 2: Sample Requirements Resource Plan for the Knowledge Share Role

Resource

Needed

Committed

Business Analyst

Jane Doe

80%

80%

Corporate Marketing

John Doe

10%

?

Research & Development

Rick Smith

10%

10%

Division A

Jean Jones

?

?

Division B

John Smith

10%

10%

Division C

Bill Nelson

20%

15%

Methods and Tools This section of the requirements plan should identify any organizational standards, methods, or tools used to support requirements activities. One example from the Knowledge Share system is that all requirements deliverables used the templates as defined by the company’s standard new system introduction methodology.

the Knowledge Share system, the same Marketing Manager stopped me in the hallway. “Would you mind coming to the meeting next week? Would you be able to put together a requirements plan? We may need to add some new features to the system. The whole process goes better when we follow the requirements plan you outlined.” n

Conclusion The requirements plan helps communicate, plan, and educate others regarding requirements management.

Communicating the requirements objectives, processes, roles and

Exhibit 3: Resource Assignment Matrix for the Knowledge Share System Future Users

Stakeholders

Business Team

Project Management

Business Analyst

Process Mapping

I

I

P

A

Requirements Workshop

I

P

P

A

Requirement Prioritization

P

P

Technical Staff

I

R

A

Use Cases

S

S

A

R

Supplemental Specs

S

S

A

R

Requirement Verification

R

P

A

A = Accountable, R = Review Required, I = Input Required, P = Participant, S= Signoff Required

the bridge l Fall 2007 18

theBridge707b

8/20/07

10:23 AM

Page 21

Intended Audience This boot camp is designed for individuals who are seeking the CBAP certification and want a focused, structured session to ensure a thorough understanding of the BABOK and to prepare for the CBAP exam.

Prerequisites Individuals must meet the IIBA’s application requirements to sit for the CBAP exam including work experience, areas of expertise, education and professional development, and references. See the requirements listed on the IIBA website at www.theiiba.org for details.

Attendees should read the BABOK prior to attending the boot camp and bring a copy with them.

4 Days IIBA CBAP Exam Prep Boot Camp Overview

New!

Accelerate your preparation for the CBAP exam by attending the IIBA CBAP Exam Prep Boot Camp. Developed and facilitated by CBAP instructors, this boot camp provides an in-depth, structured approach to understanding the BABOK. This intense 4-day boot camp concentrates on the key areas of the BABOK and provides useful memory exercises and discussions to reinforce the concepts detailed in the BABOK. The CBAP exam consists of 150 questions. This boot camp includes 450 practice questions with feedback written by Certified Business Analysis Professionals. Attendees will learn test taking strategies, gain an understanding of the exam format, and review the types of questions that are asked on the CBAP exam. Attendees receive a free copy of our comprehensive CBAP Exam Prep Study Guide.

This interactive boot camp includes: • 450 practice questions including a full practice exam • Answers to questions include feedback for the correct and incorrect answers • Review session after each set of practice questions • CBAP Exam Prep Study Guide • Memory exercises and discussion to reinforce core concepts • Pass guarantee! Students who have prior approval to sit for the CBAP exam are guaranteed to pass the exam within 3 months after attending the boot camp or they may attend the boot camp again for free.

• Proven test taking strategies • Overview of the CBAP exam format and question types

s

CBAP Exam Prep Study Guide

Kick-start your exam prep with our CBAP Exam Prep Study Guide. Written by Certified Business Analysis Professionals, this study guide consists of 450 comprehensive practice questions for all six knowledge areas and underlying fundamentals of the BABOK. Additionally, the study guide provides an overview of the structure of the exam, test taking strategies, and memory exercises.

To purchase a study guide visit our online catalog at www.b2ttraining.com .

19 Fall 2007 l the bridge

$149

8/20/07

10:23 AM

Page 22

Course Outline Introduction – 1 hr • Overview of exam (question types, number of questions, where questions are derived from, percentage of questions by knowledge area, etc.)

• Overview of boot camp format • 450 test questions with feedback • Exam simulation • Tips and hints to reinforce concepts and techniques • Practice exercises • Glossary of terms Introduction to the BABOK – 30 min • Overview of the Knowledge Areas and their relationships • Knowledge Areas relationship to solutions lifecycle or SDLC • BABOK definitions Enterprise Analysis – 4 hrs • Assessment test questions for Knowledge Area (students self grade) • Key concepts of Enterprise Analysis • Exercises • Practice test questions (with answers and feedback using questions from the assessment) • Discussion based on missed questions Requirements Planning and Management – 4 hrs • Assessment test questions for Knowledge Area (students self grade) • Key concepts of Requirements Planning and Management • Exercises • Practice test questions (with answers and feedback using questions from the assessment) • Discussion based on missed questions Requirements Elicitation – 3 hrs • Assessment test questions for Knowledge Area (students self grade) • Key concepts of Requirements Elicitation • Exercises • Practice test questions (with answers and feedback using questions from the assessment) • Discussion based on missed questions

Requirements Analysis and Documentation – 4.5 hrs • Assessment test questions for Knowledge Area (students self grade) • Key concepts of Requirements Analysis and Documentation • Exercises • Practice test questions (with answers and feedback using questions from the assessment) • Discussion based on missed questions Requirements Communication – 3 hrs • Assessment test questions for Knowledge Area (students self grade) • Key concepts of Requirements Communication • Exercises • Practice test questions (with answers and feedback using questions from the assessment) • Discussion based on missed questions Solution Assessment and Validation – 3 hrs • Assessment test questions for Knowledge Area (students self grade) • Key concepts of Solution Assessment and Validation • Exercises • Practice test questions (with answers and feedback using questions from the assessment) • Discussion based on missed questions Business Analysis Fundamentals – 1 hr • How fundamentals are incorporated in exam Practice Exam – 6 hrs • Practice exam • Discussion based on missed questions Conclusion – 2 hrs • Key concept recurring themes “BABOKisms” you want to know • More test taking strategies

Learn how you can host a CBAP exam at your location. Contact B2T Training today at sales@b2ttraining.com or call 866.675.2125!

t

theBridge707b

For more information on this course visit www.b2ttraining.com.

the bridge l Fall 2007 20

theBridge707b

8/20/07

10:23 AM

Page 23

certified core courses Essential Skills for the Business Analyst

4 Days

A Business Analyst’s main responsibility is to elicit, detail, and document requirements in a format that is useful to business stakeholders and technical developers. This first course in our core series is designed as a foundational course to level set the students’ understanding of the BA role in the industry and discuss how this may be different in their organization.

Students attending this course will learn how to scope the project from a requirements perspective and determine the appropriate level and complexity for each requirement.

We will discuss various elicitation, analysis, and documentation techniques, learn how to conduct a requirements review, and learn how to ensure that requirements are at the appropriate level of detail. To enhance analysis communication skills, we discuss various techniques for gathering requirements and how to ask the right questions. This class is an excellent class for BAs with varied backgrounds and experience levels to discuss ways to improve their organizational BA processes.

Earn 28 IIBA CDUs and PMI PDUs

Detailing Business Data Requirements

3 Days

Missing or poorly defined data requirements are the primary reason that most systems fail. By definition, a process transforms data. The goal of this class is not to teach BAs to model or design physical databases; it is to fully understand data requirements and to be effective at communicating with the developer and technical staff.

The second course in our core series teaches students how to identify the data elements within the project and detail them to the appropriate level, in the best documentation format for the users to review and the developers to use. Depending on the project, various techniques are discussed for documentation. This class covers techniques of logical data modeling and the use of requirements templates. A half-day workshop is included to reinforce the concepts learned.

Earn 21 IIBA CDUs and PMI PDUs

4 Days Detailing Process and Business Rule Requirements Our third core course teaches BAs how to define various levels of processes and to document the associated business rules. The techniques taught in this class define the essential business processes within the scope of a project and detail them into functional requirements. Techniques include decomposition diagrams, workflow modeling, use case descriptions and scenarios, and prototypes. This course walks through the complexity of how to scope your project into phases if necessary and how to check the entire requirements package for completeness. A half-day workshop is included to reinforce the concepts learned.

t

Earn 28 IIBA CDUs and PMI PDUS

For more information on these courses visit www.b2ttraining.com.

21 Fall 2007 l the bridge

8/20/07

10:23 AM

Page 24

advanced and specialized courses Facilitating Requirements for Business Analysis

3 Days

This course teaches students to plan and conduct a facilitated session to elicit business and functional requirements. The art of bringing people together to elicit requirements and gain consensus on solutions is a critical success factor for all BAs. The workshops in this course ensure students have the opportunity to conduct a requirements elicitation session for one project deliverable and to play each of the key roles in at least one session. This class is limited to 8 students and over 60% of the class time is spent on interactive, real-world business case study facilitated sessions.

Earn 21 IIBA CDUs

2 Days Requirements Validation This course takes the Business Analyst through the steps that ensure business requirements are validated and that the solution is usable and meets the business needs.

Business Analysts will learn to design efficient requirements validation tests to make the best use of limited resources and time. This course addresses many of the important tasks in the BABOKTM knowledge area Solution Assessment and Validation and equips Business Analysts to design efficient and effective tests that demonstrate the application solutions meet their user’s needs.

Earn 14 IIBA CDUs

management/technical seminars Overview of Business Analysis

4 Hour Seminar

This seminar presents the Business Analyst role to managers and others who lead and work with Business Analysts. In order for the Business Analyst to be successful, both the IT and business community must embrace the business analysis process. The seminar can be used as a working session to discuss how your organization will implement the business analysis process and approaches for documenting the requirements.

1 Day Developer’s Introduction to Business Analysis This class provides an overview of the Business Analyst role and a detailed review of the requirements document provided to the development team. To ensure an integrated team, IT developers need to understand the role of the Business Analyst. They should also be familiar with the requirements that Business Analysts are gathering and documenting. This includes understanding categories of requirements, the core requirements components, and the documentation formats used for each type of requirement. IT team members must also understand the testing life cycle and the personnel involved. This course gives students an overview of the Business Analyst role, requirements documentation, and software testing.

t

theBridge707b

For more information on these courses visit www.b2ttraining.com.

the bridge l Fall 2007 22

theBridge707b

8/20/07

10:23 AM

Page 1

B2T Training’s public classes Core Courses Essential Skills for the Business Analyst - 4 Days Detailing Business Data Requirements - 3 Days Detailing Process and Business Rule Requirements - 4 Days Advanced and Specialized Courses Facilitating Requirements for Business Analysis - 3 Days Requirements Validation - 2 Days IIBA CBAP Exam Prep Boot Camp - 4 Days

Atlanta, GA • Chicago, IL • Dallas, TX • Houston, TX • Louisville, KY • Minneapolis, MN • New York, NY • San Diego, CA • Seattle, WA • RECEIVE A 10% DISCOUNT! 1. When you register and pay for three courses.

2. When groups of 3 or more employees from the same company register and pay for one course.

Visit www.b2ttraining.com for the latest public class schedule, pricing information, and to register.

B2T Training 11675 Rainwater Drive, Suite 325 Alpharetta, GA 30004

Prsrt Std U.S. Postage PAID Permit #309 Knoxville, TN