Eliciting and Documenting Detailed Business …and...• Requires!trained!and!experienced!personnel!for!facilitation!and recording.!! JAD ... documents.!The ......

Eliciting and Documenting Detailed Requirements What's Included in this Book

• Defining the Approach for Eliciting Requirements • Obtaining Detailed Requirements • Prioritizing Requirements • Documenting Requirements and Attributes of Requirements • Real examples of vague vs. detailed requirements • Three Requirements Eliciting Techniques • What is a Business Requirements Document (BRD) • Sections of the BRD and what goes in those sections

Introduction

Software development teams develop all types of software for all types of industries. So the software can be vastly different between companies, but all companies have the same goal in mind: develop quality software on time, on budget, and that meets the customer's real needs.

If an application is developed that is completed on budget, on time, and has very few defects, it may be an excellent system. However, if it doesn't meet the needs of the customer, they won't use it. If forced to use it, they will still use other software or manual processes to compensate for what's lacking in the new application. Company money has been spent to design (usually a very large chunk of change), develop, and deploy an application that isn't doing what they expected it to do. This will lead to unhappy users, managers, executive staff, and sometimes even unhappy investors. Requirements errors are usually the most expensive to fix.

It's imperative to have business analysis be an important part of the project. This will ensure the right requirements are captured, documented, developed, implemented, and deployed. The goal is "no surprises" for the users and business partners. When they see and use the application it should be exactly what they expected it to be.

Once the scope of a project has been defined, the next step is for the business analyst to gather complete requirements. This is the most important task for a business analyst.

A business requirement defines what the business problem is and what specifically the business needs to accomplish. There can also be system requirements. System requirements are needed in order to meet the business requirements. System requirements will usually come from the technical partners on the project, not the business partners.

The business analyst (BA) is responsible for determining where to find the requirements. Usually they will have subject matter experts (SMEs) and/or users of the software application to gather requirements from. In some cases, the project may be more technical and the business analyst will elicit some requirements from developers, architects, etc.

For the sake of simplicity, throughout this book, we'll be using SME as the reference to whom we are eliciting requirements from.

Defining the Approach for Eliciting Requirements

The BA is responsible for defining the approach they will use for eliciting the requirements. They might have a meeting in a conference room with everyone present, they may do a combination of in-‐person and by conference call, and they may do several smaller sessions if people are in different locations/time zones. The BA needs to use their judgment in regards to which option makes the most sense for the project. They may also be bound by project requirements. For example, if there's no budget for travel in the project, in person meetings may not be possible. Sometimes it's useful to use a desktop sharing tool that everyone can log into and all parties can view the same thing at the same time. There are creative options available if everyone cannot be in a room together.

Obtaining Detailed Requirements

The BA must obtain detailed and complete requirements. In order for the business analyst to accomplish this task, they must have excellent communication skills. The BA must have the ability to:

• Pay close attention to what the SMEs are saying • Ask the right questions to get more specific details on the

requirements • Take notes while still staying engaged in the conversation • Repeat back what was heard to ensure correct understanding of

what the person is stating • Keep the meeting on point and everyone engaged in the

conversation

Now let's take a closer look at each of the above

statements: Pay close attention to what the SMEs are saying

In order to effectively elicit requirements, the business analyst must stay engaged and focused on the conversation. If not, they may miss an important piece of information for a specific requirement.

It is the analyst's responsibility to understand the user's problem and build systems that meet their needs.

Taking breaks throughout the meeting can help everyone stay focused. It's important to take breaks at regular intervals so everyone has the opportunity to stretch, take a restroom break, make a call, etc. If everyone gets time to do these things, they are more inclined to stay in the room and stay focused when needed.

Ask the right questions to get more specific details on the requirements

There is a general rule that says "if you ask why three times you'll get to the real requirement". The question isn't always "why", but asking for more information three times will generally lead you to the root requirement.

Let's test that theory here. Joan is eliciting requirements for a software application a company is using to sell their widgets.

Mark tells Joan they need the ability to take payments. Joan asks Mark why he needs the ability to take payments. Mark states they have products for sale on their website and they have to be able to take payments on the site if someone decides to purchase a product.

Joan asks Mark what type of payments they will accept. Mark responds with Master Card, Visa, debit cards, and check payments.

Joan asks if there are a maximum number of items a person can buy in order to pay online and if there is a minimum and/or a maximum amount for the payments for any of the payment types.

Mark responds there is no limit to the number of items a person can buy, and the max/min limits are the same for all credit and debit cards, but is a lower amount for checks. Minimum for credit and debit cards is $5.00 and the maximum is $1000.00. For checks, the minimum is still $5.00, but the maximum is $250.00.

The initial requirement of "Need the ability to take payments" was a vague requirement. By asking three follow-‐up questions, Joan now has two detailed requirements:

• Need the ability to take payments via Master Card, Visa and debit cards with a minimum amount of $5.00 and a maximum amount of $1000.00

• Need the ability to take payments via checks for a minimum amount of $5.00 and a maximum amount of $250.00

This should spawn other requirements related to payments. Other questions Joan would ask are:

• Can they split the payment up with multiple cards/payment types or do they have to pay for the entire order with one payment transaction?

• Will the company need to store credit card information for the customers?

• If so, how long will they need to store the information? • Can customers keep multiple forms of payment stored on the

company's site, or only one payment type can be saved/stored?

This will continue to spawn more discussion around payments and that's exactly how it should work. The BA has a responsibility to

continue to ask questions and make the others think about things they may not have even realized they needed until they talked completely through all of the options related to taking payments.

Take notes while still staying engaged in the conversation

This is probably one of the more difficult tasks during a requirements meeting. The BA needs to stay engaged in the conversation, but will need to take notes because it's impossible to remember every decision made during the meeting.

The BA can and should take notes on decisions made during the meeting, but they should also have someone designated as the scribe for the meeting. That scribe should be taking very detailed notes on all requirements. Later the scribe and the BA can work to combine their notes and come up with a complete list of requirements.

Some people will give lengthy answers to the questions the business analyst is asking. Capture the actionable items and steps in the conversation. It's important for the analyst to repeat back to the person what they heard them say. Not everyone processes information in the same way and the analyst may interpret something completely different from what the SME/user was telling him or her.

Keep the meeting on point and everyone engaged in the conversation

At the beginning of the meeting the BA should lay some ground rules and one of those rules should be that all subjects that come up not related to this meeting will be added to a "parking lot" for later discussion.

A parking lot is simply a large piece of paper usually taped up to a wall. This paper is used to capture any subjects that are not relative to this particular meeting, but need discussion at a later time.

The BA needs to reassure the group that what they have to say is important and while they may not be able to do a "deep dive" on all topics today, they should ensure the group knows they are taking what they say seriously and will follow-‐up at a later time on those parking lot topics.

Keeping everyone engaged during an in person meeting can be as simple as continuously making eye contact with everyone during the meeting

and occasionally calling out to the "quiet ones" to ask them questions and get them involved in the discussion.

You can also do some fun things to keep people engaged in the conversation. At the beginning of the meeting, hand out reward "coupons" that say "Great Idea!" Explain that the coupons are to be handed out to others in the meeting when they present a good idea. Also explain the expectation is that nobody leaves the meeting without at least one "Good Idea!" coupon. Make a small reward for the use of the coupons.

“The after lunch energy issue” -‐ everyone knows what this means. You have lunch, you're sitting in an afternoon meeting and all you can think about is the nap you desperately want.

Do whatever you can to keep things moving. I would suggest serving a light lunch, no heavy pasta! Have afternoon snack breaks, break people up into small discussion groups, move people and furniture around, whatever you can do to keep energy flowing. Sometimes changing the lighting or temperature in the room also helps.

This can be more challenging when the meetings are held via conference calls, but there are ways for the BA to keep people engaged:

• Take a roll call and write down the names of all the people attending the meeting.

• Ask everyone to announce their name before they start talking so that everyone knows who is speaking.

• The BA and scribe should write down the name of the person related to the notes they take so they can call out to specific people if they need to re-‐engage them in the conversation.

Prioritizing Requirements

With the help of the SMEs, the BA is responsible for prioritizing requirements.

Some companies use something like "Must Have, Nice to Have, Optional" and others may use a numbering priority like 1-‐3 with 1 meaning must have and going down from there. It's important to do this prioritizing step because it sometimes comes into play when considering the scope of the project. When projects must be completed by a specific date (as most do), sometimes the scope of the project needs to change in order to meet that date. It helps to know which requirements are most important vs. least important when the project team is determining what could be held off for a later release instead of going in production in the initial release.

If the meeting is in person, the BA can use the end of the meeting to do the priority exercise. This can actually be a fun way to end the meeting.

Here's how this exercise can be done:

• Take sheets of colored dots to the meeting in enough different colors to match the number of priorities. If the priorities are Must Have, Nice to Have, and Optional, the BA should have 3 different colors of dots.

• The requirements should be listed on papers hung on the wall. These can be typed or hand written depending on how much time there was to prepare for the "dot" exercise.

• Each SME should be given sheets of dots in all three colors. • Every SME will go to the wall and place dots next to the

requirements based on what category they feel each requirement falls into.

• Once everyone is finished putting up there dots, it's usually easy to tell which requirements are "Must haves" because they will have the most dots next to them in the color that was meant for the "Must Have" priority.

It's important to note here that ONLY the SMEs and business partners take part in this exercise. The BA, project manager, and IT members of the

meeting DO NOT get to vote. This exercise is strictly for the business people.

This exercise can also spur discussions related to the priority for certain requirements. If there are 10 SMEs and 5 say a requirement is a must have and the other 5 say "Nice to Have", it is the responsibility of the BA to lead a discussion on which priority best fits the business needs for that requirement.

If the meeting is via a conference call, the BA may need to email the list of requirements to each SME, get them to put there priority on them and email them back to the BA. Once the BA gets the results, they can compile them and then have a follow-‐up conference call with everyone and review the results of the priority exercise.

Documenting Requirements and Attributes Let's take another look at the requirements from earlier around taking payments.

We have a requirement that says the customer should have the ability to make a check payment for a minimum of $5.00 and a maximum of $250.00

The business analyst should also document attributes for this requirement. Attributes would be the checking account number, the bank routing number, the dollar amount, the name of the account holder, the account holder address, etc.

Once all of the attributes are documented, the next step would be determining which of the attributes are required vs. optional. For example, first and last name of the account holder may be required, but middle initial is optional.

The BA will then need to determine what data types each of the attributes are. Are they a numeric, character, date/time, etc. After determining the data types, the BA needs to define the number of characters/field length acceptable for each data type and if it is "up to" a certain number or must be a specific number of characters.

Example: The bank routing number may be required to always be exactly 9 numeric values, but the bank account holder's last name can be from 1 to 26 characters.

There are many things that go into documenting detailed requirements; it is not simply listing the requirements. The business analyst needs to account for all data that needs to feed into or come out of the application in order to meet that requirement. Other considerations are:

• Where is the data going to be stored? • What type of database will be used? • Will all data be stored in one database or certain fields in one

place and others in another database? • How long is that data stored?

How often will the database be updated and what will that update process be?

If the system is built to meet the requirements of the user, we can be sure it will deliver the features they expected and since the features address the needs of the business partners, their needs will be addressed.

Requirements Eliciting Techniques

I'd like to take some time here to explain that there are a few different ways to gather requirements. In this book we discussed a meeting with everyone present and the possibility of conference calls. I'd like to talk about the different requirements eliciting techniques that can be used.

Three recommended techniques for requirements elicitation are Interview, JAD (Joint Application Development) sessions, and the Survey method.

Interview Method

Summary:

• An interview is a conversation with stakeholders to elicit or validate needs and requirements.

• An interview may include one or more stakeholders. • The interview may also involve a question and answer session

used to discover other potential stakeholders and any discrepancies between needs, the high-‐level requirements derived from those needs, and the resulting detailed requirements.

• Interviews facilitate obtaining approval from stakeholders on their needs, requirements, and any changes to them.

Advantages:

• Generally easy, because it can be done with minimal preparation. • Interviews of individuals and small groups require less

planning and scheduling effort than large workshops. • Interviews of individuals and small groups require less

stakeholder commitment than large workshops. • Interviews provide an opportunity to explore or clarify topics

in more detail.

Example Questions to Ask:

• What have you already tried? • Why now?

BA role in the interview session: • The BA may be responsible for identifying the stakeholders

or by working with the appropriate project team member to get the list of stakeholders.

• The BA is responsible for preparing questions ahead of the scheduled meeting and distributing the questions to the stakeholder or stakeholders.

• The BA is also responsible for taking the meeting notes and when possible, engaging another person in attendance to also take notes to record information discussed in the meeting and any decisions resulting from the meeting.

Stakeholder/Business Sponsor role:

• The stakeholder is responsible for providing their needs, expectations, priorities, and constraints.

• Stakeholders also validate the results of the interview.

JAD Session Method Summary:

• The Joint Application Development (JAD) technique is an extended, facilitated workshop.

• Involves collaboration between stakeholders and systems analysts to identify needs or requirements in a concentrated and focused effort.

Advantages:

• This technique allows for the simultaneous elicitation and consolidating of large amounts of information.

• This technique produces relatively large amounts of high-‐quality information in a short period of time.

• Discrepancies are resolved immediately with the aid of the facilitator.

• This technique provides a forum to explore multiple points of view regarding a topic.

Disadvantages:

• Requires significant planning and scheduling effort. • Requires significant stakeholder commitment of time and effort.

• Requires trained and experienced personnel for facilitation and recording.

JAD Process Steps:

1. Define Session: Define the purpose, scope, and objectives of the JAD session, selecting the JAD team, invite and obtain commitment to attend sessions from the appropriate stakeholders, and schedule the session. It is important to obtain management commitment to support the process and identify the appropriate stakeholders.

2. Research Product: Become more familiar with the product or service; gather preliminary information obtaining any models.

3. Prepare: Prepare any visual aids, developing a realistic agenda, training the recorder, and preparing the meeting room.

4. Conduct Session: Follow agenda to gather and document the project needs and requirements. It is important to ensure all participants are given equal treatment during the process.

5. Draft the Documents: Prepare the formal documents. The information captured in the JAD session is further refined through analysis efforts, open questions or issues discovered through the sessions are resolved, and the final document is returned to stakeholders for review and validation.

Roles:

• The JAD team is the very heart of the JAD process and the selection and inclusion of stakeholders are critical to the overall success of a JAD session.

• The team should consist of a mixture of skills from a variety of individuals.

• The participants may include Business Process Owners, Operations Managers, Client Representatives, Business Analysts, Business Managers, End Users, Data Administrators, Systems Analysts, System Designers, Auditors, Security, Standards, Vendors, Quality Assurance, Contingency Planners, Production Planners, IT Specialists, Human Resource Representatives, and Trainers.

Executive Sponsor:

The executive sponsor may be a manager of the business area whose needs and requirements are being addressed during the JAD session.

Management commitment is required for any requirements elicitation process to succeed. It is very important for the JAD session team to have a management sponsor. The executive sponsor may be a manager of the business area whose needs and requirements are being addressed during the JAD session.

• The sponsor does not have to actively participate in every JAD session.

• It might be advisable to attend the first JAD session to show support, and perhaps, the final JAD session to review the results and make comments.

• The sponsor should be available throughout the period of the JAD process to solve any serious problems or issues that may arise.

• The JAD facilitator must work closely with the management sponsor and provide full briefings on progress.

BA Facilitator:

The facilitator is the key person in the group and is responsible for planning, executing and managing the session. They should be a respected, skillful leader with a good reputation within the organization. JAD facilitator skills do not happen by chance, and the skills may have to be learned through specialized training and experience. The choice of facilitator may mean the difference between a good session and a poor one.

It is essential that the facilitator be given authority to work closely with the executive sponsor to achieve the objectives of the JAD session. The facilitator will know how to direct people and to be able to get the best information from them.

JAD Facilitators should be able to:

1. Focus on the process, not the information content of the JAD session.

2. Be unbiased and neutral, and remain impartial. It is important that the reporting structure is such that the facilitator cannot be influenced or biased.

3. Use organizational skills to lead groups and keep the sessions on track.

4. Ensure each subject under discussion is accurately recorded and completed to the stakeholders' satisfaction before proceeding.

5. Stop sideline conversations

Recorder: The recorder is responsible for documenting the JAD sessions. This must be done in an interactive fashion and the recorder must work closely with the JAD facilitator.

• Many ideas and suggestions will be discussed. • A large session may need multiple recorders • The recorder must capture the important discussion and decisions

made, who made them and why. • Laptop computers, white boards, flip charts, or overhead

devices are particularly useful.

It is the responsibility of the recorder to distribute and file the documentation at the end of each JAD session or as soon as possible after the session or topic has concluded. It can be a difficult task and should not be underestimated. The recorder should have the following skills:

1. Knowledge of the stakeholder business area. In order to record the results properly, the recorder needs to understand the concepts of what was discussed.

2. Excellent analytical skills. The recorder needs to be able to analyze what was discussed and presented in the JAD session.

3. Experiences with JAD tools if any are used. The JAD tool may be a word processing software, an electronic whiteboard, or a CASE tool. Whatever tool is used, the recorder has to have a good knowledge of how to use the tool effectively.

4. Good technical writing skills.

Stakeholder/Business Sponsor role:

The participation of stakeholders in the JAD session is widely accepted as essential to its ultimate success. Without their involvement, the JAD session will not be productive.

The whole point of a JAD session is to bring stakeholder and performing organization together in a structured environment. Stakeholders will rapidly gain a sense of involvement and ownership in the product or

service development where a JAD session is used. This is vital to its overall success. Most importantly, the stakeholders will get the product they want and not one that has been designed poorly for them.

Survey Method

Summary:

• The Survey Method is an electronic or paper based method of soliciting needs or requirements from stakeholders.

• The survey method is a list of questions, directed at identifying stakeholder needs or requirements.

Survey Method Advantages:

• A survey can reach a large number of stakeholders or other sources of information.

• A survey is an excellent tool to gather a significant amount of focused data in a short period of time.

• Survey method can provide good results when used to validate assumptions after the use of the interviewing technique.

• A Survey method is a good tool to gather statistical preference data.

• A survey requires little scheduling effort. • A survey requires little stakeholder commitment of time and

effort.

Survey Method Disadvantages:

• The response level is often low, especially to large surveys. • Responses are usually limited to the realm of the questions

asked, which reflect the analyst's preconceived ideas or assumptions of the survey designer.

• Well-‐made surveys require trained and experienced personnel to develop.

• Development time can be significant. • Conflicts and inconsistencies in information from stakeholders

require additional analysis to resolve.

Survey Method Process Steps:

• Decide what you want to know and how you will analyze the data

before you develop questions. • Look for questions or ideas from other sources to inspire the

writing of your method • Write questions to be as specific as possible. Use simple,

straightforward language. Avoid the use of jargon or terminology specific to a few people

• When you have written the survey questions, it is important to test them to make sure that the language is current, the questions are not biased, and the questions are relevant to the purpose of the survey. Deliver the set of questions to the stakeholder for their response. Provide a date by which the answers are to be returned.

• Write short questions to ensure reader understanding, including: • Limit the number of choices available to a question to five or less (if

applicable). • Offer a "don't know" or "no opinion" option, so people do not

invent answers. • Vary the format of the questions to keep people interested.

BA Role -‐ Survey Author:

The survey method author is responsible for crafting questions to solicit the needs and requirements from stakeholders. Once the answers have been received, the author is responsible for recording the answers into a document for confirmation by the survey method respondents.

To develop a useful method, the writer should be familiar with the purpose of the evaluation and ideally have some experience with developing surveys.

Stakeholder/Business Sponsor: The stakeholder is responsible for answering the questions and verifying the resulting information presented by the author for confirmation.

What is a Business Requirements Document, Why do I Need It, and What Goes in It?

A BRD is a business requirements document. The purpose of the BRD is to provide an outline that explains the customer and business requirements for the change and also serves to provide additional structure around the scope of the project. Business requirements have usually been gathered from meeting with subject matter experts (SMEs), end users, and business partners.

The BRD will be used to gain approval and sign off from the business partners and will be used in the development (sometimes called construction) phase of the project.

Some people will document requirements as a list in a spreadsheet and I absolutely agree this should be done...but it should not be your final documentation of the requirements. The spreadsheet is useful for getting the requirements in a document in order to keep a running list and to be able to go back and re-‐order that list as you go through the requirements phase so that requirements that belong together can easily be moved around to any order necessary. Once this is done, the requirements should be moved to the BRD document. A BRD will add other necessary information to the "requirements picture" and should be considered a necessary document in your software development life cycle. The BRD should also be the primary document used to write use cases.

Before we get started, I want to remind everyone that business requirements should be written in terms of business statements describing what the business wants to do, not how to do it. The requirement should not take the form of design or programming code.

Let's take a look at the different sections of the BRD. For the purposes of this manual, we're looking at a basic BRD that could be used by any IT group.

Project Objective

The problem statement and objective to correct the

problem.

Project Scope Scope of the project -‐ what will be included in this project.

Constraints/Assumptions/Dependencies

Constraints are considered any boundaries or restrictions within which the project must operate or within which the solution must fit and what their effect has on time and budget. Assumptions are factors that are considered to be true, real, or certain; things that are prerequisites for the project to be successful. Example: It is assumed reporting will be handled by an out of the box solution (this tells the reader you will not be building any customized reports as part of this project). Dependencies are related to any other work efforts or events that this project is depending on in order to be successful. Example: Project may rely on the deployment to production of another project to finish prior to this one deploying.

Actors/Roles Actors and roles of those actors are related to the requirements being documented. You may have people and system actors. Example: Actor 1 is a customer service representative and their role is taking a payment, System A is a credit card authorization system, and system B is a billing system to post the payment to the account are all considered actors. One is a person and the other two are systems. Current Environment

This should be a high level description of the current business environment where you intend to make a change. This can be in text, diagrams, tables, etc. The business partners should identify for you any automated applications or tools they know they are using in their day-‐to-‐day workflow. Make sure this is discussed in your requirements sessions.

Future/Target Environment

This should be a high level description of the future business environment based on how the business partners and stakeholders envision the future environment operating. This can also be text, diagrams, tables, etc.

User Requirements (sometimes called Features)

This is where you input those requirements you gathered in the meetings with SMEs, end users, and business partners. These requirements will show what is expected to be delivered by the product or service being defined by the project this BRD is for.

Functional Requirements

I'm putting this in here so that we can talk about the difference between user requirements and functional requirements. User requirements are the requirements you got from the business partners, such as "we need the ability to process credit card payments". Functional requirements describe the desired behavior of the solution. In effect, functional requirements are use cases; the steps that will be taken (by both the people and the systems) in order to process that payment. Some companies include use cases in the BRD and some do them as separate documents. I prefer them as separate documents for several reasons, a few of which are:

1. Use cases should include textual flows of the primary process 2. Use cases should include textual alternate process paths 3. Use cases should include textual exception process flows 4. Use cases should also include a process flow diagram

These are not all of the parts of the use case and, as you can see, it would create a very large BRD if you included every use case within that document. I find it to be more manageable and easier to present to the

business partners if they are separate documents. Anything too large can be overwhelming and people may "shut down" and not review the document as they should.

Non-‐Functional Requirements These are requirements that should be addressed by most projects, such as volume, capacity, performance, etc.

Open Requirement Issues

This is an excellent area to keep track of any outstanding issues or questions related to specific requirements. Keeping it in the BRD, will allow you to keep the complete list in one place and document what the resolution was in the same area. This section should include what the issue is, who it's assigned to, the date resolved, and what the resolution is. You'll want to make sure you make any changes to the other areas of the BRD that need to be made based on the resolution of each item

Reviewers and Approvers

You'll want to list here anyone that is required to approve the BRD and anyone required to review it. You can of course have as many people as you want review it, but you want to list here the person who is required to review it. Make sure you have a place in the section to include the date approved or reviewed for each person.

Related Documents

This section is great for including links to any other project related documents, such as a project charter or project definition document.

Glossary/Definitions/Terminology

The business analyst needs to ensure they are using consistent terminology. One way to accomplish this is to include a Glossary of terms and definitions in the requirements document.

This section is very useful for helping all team members understand the terminology being used. The project team will most likely be made up of people from various groups and departments in and outside of IT. A section that gives definitions to the terminology being used throughout the document will be helpful to the entire team.

Different businesses will use different BRD templates with a variation on the data they include in the BRD. However, what we reviewed in this book is the basics for a standard BRD and this information should always be included in your document. Your company may enhance the document with things such as a data glossary, conceptual and logical models, design considerations, implementation impacts, etc.

If you are at a company that either doesn't use a BRD document or wants to change to a different style, I would recommend starting with the basics that we've gone over here and then adding/changing sections as you use the document and see what works best for your organization.

As you can see, there are many things to consider besides getting that initial detailed requirement. In order to be an effective business analyst, the BA must be able to look at the big picture and also identify the details.

Using the recommendations laid out in this book should give you a good foundation to build your analyst skills on.

If you’d like to speak with me about your career goals or the Business Analysis goals of your organization, you can schedule a call with me by using the 15 Minute Asessment Session option on my calander that can be accessed via this link: https://theanalystcoach.acuityscheduling.com/schedule.php

Now go do some analyzing!

© 2014 The Analyst Coach, LLC All rights reserved.

Author Contact Info:

www.theanalystcoach.net

Author: Teresa Bennett

eMail: [email protected]

Phone: 1-‐866-‐968-‐6657

Address:

PO Box 1862

Matthews, NC 28105