situation analysis reference guide - enfocus solutions

2.0Reference Guide

Situation Analysis

V. 1

Table of Contentspp Introduction to Situation Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

pp Chapter One: 2.1 Document Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Visualization and Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Comprehension Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

Situation Analysis Workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Group Discussion Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Task Completion Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Related Content in RequirementCoach™ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

pp Chapter Two: 2.2 Define Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Visualization and Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Task Completion Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

What to Do When You Are Handed a Bad Vision Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Application Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Group Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Situation AnalysisRequirements Excellence Framework™

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved

pp Chapter Three: 2.3 Define Project Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Related Technique: Objective Chain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Comprehension Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

SMART Objectives Worksheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65


pp Chapter Four: 2.4 Assess Organizational Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Visualization and Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Questions to Ask the Project Sponsor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76


pp Chapter Five: 2.5 Determine Capability Gaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Collaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Visualization and Elaboration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84


pp Chapter Six: 2.6 Define Constraints, Assumptions, & Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Comprehension Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97


Situation AnalysisRequirements Excellence Framework™

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved

Requirements Excellence Framework™

© Copyright 2013 Enfocus Solutions Inc. All Rights Reserved 1

IntroductionAccording to recent publishings by the International Institute of Business Analysis (IIBA), the term “situation” refers to the combination of two project components:

p� The context surrounding the project

p� And the change that guides the solution.

Before the project team can even think about building the solution, they need to ensure they have a firm grasp on the situation that surrounds the project. Without fully understanding the problem being addressed or the goals that are to be achieved, the business analyst will define a poor set of requirements and the development team will build a solution that doesn’t meet the needs of the organization or its stakeholders. Understanding the situation means all project contributors, as well as all stakeholders related to the project, fully understand the following components of the project:

p� The problem being addressed (Task 2.1 Document Problem)

p� The vision of what the solution will look like (Task 2.2 Define Vision)

p� The project’s objectives (Task 2.3 Define Project Objectives)

p� The organizational context that surrounds the project (Task 2.4 Assess Organizational Context)

p� The gaps in organizational capability (Task 2.5 Determine Capability Gaps)

p� The project’s restrictions and limitations (Task 2.6 Define Project Constraints and Assumptions)

Document and socialize these important pieces of information with Enfocus Requirements Suite™, which allows project teams to reference, present, and archive all business analysis knowledge related to the project. Performing the tasks and practices that make up the situation analysis task group greatly contributes to project success, ensuring the team has a strong foundation on which they can build the solution.

Situation Analysis



IntroductionBefore the project team can begin to develop a solution, they need to fully understand the problem or opportunity that is being addressed by the solution, including the needs and wants of executive sponsors. This task is often performed poorly, because many organizations often end up using some kind of “problem statement” that is nothing more than a list of user complaints. Merely documenting hundreds of complaints does not accurately document what the true problem is. To resolve the problem, it is essential that project teams and stakeholders determine what the real problem is, document it, and understand it.

Chapter One: Document Problem

Document Problem

2.1 Chapter One



Core ConceptsProblem Statement

According to the Business Analysis Body of Knowledge (BABOK), a problem statement states the business need, identifies key stakeholders, and briefly describes the positive impact that meeting the business need will have on those stakeholders. Creating a good problem statement is a key task that must be performed before starting to elicit requirements for a solution. Understanding the purpose of the project is essential to comprehending the underlying needs, so that you can make appropriate trade-offs in time, cost, scope, quality, resources, and risk as you manage the project.

MotivationThe motivation behind implementing the project must be understood before anyone can sign-off on it. The problem statement provides that motivation to project contributors and relevant stakeholders. Without a problem statement, the project lacks justification and direction. A good, clear problem statement will enable your project team to focus on the problem and provide a foundation for the team to begin working on the solution.

Problem Definition (PD)Although it is the key activity, developing the problem statement is only one activity related to the task of defining the problem. Either a project manager or business analyst is typically responsible for preparing a Problem Definition (PD) document. The PD should generally include the following components:

p� Summary Problem Statement: Provide one to two sentences explaining the current problem, opportunity, or challenge. The process for developing the problem statement is described in this workbook. p� Current Performance: Briefly describe the organization’s current performance. p� Target Performance: Briefly describe what the organization’s performance should look like. p� Cause of the Problem: Describe what is preventing the organization from achieving the target performance.p� Risks: Describe the risks associated with not addressing the problem.

Most of the work necessary for creating the PD is focused on the summary problem statement. At this phase in the project, the other sections, like the current and target performance descriptions, should be very high-level. An in-depth analysis of current and desired organizational performance will occur in Task 2.5 Determine Capability Gaps.

Principles of Writing a Problem Statementp� Do not confuse the problem with the solution or the symptoms. p� Do not focus on the “who;” focus on the “why” of the problem.p� Do not assume too much too early, limiting what you can learn through observation and examination. p� Do not view the problem statement as though it is written on a stone tablet. Writing a problem statement is an iterative process.




Process

1. Describe the current conditions and environment.

Describe the existing system or process and its condition, as well as the existing environment. Try to answer as much of the following questions that you can about the system:

p� What is the function of the system?

p� What people are involved with the system—what types of stakeholders?

p� What skills or abilities are required to use the system?

p� What are the higher and lower level system goals and interfaces?

p� How does data flow in the system and what activities are involved? How are they related?

p� What components are there in the system and what is their purpose?

Try to answer as much of the following questions as you can about the surrounding environment:

p� Who uses the system and what are their characteristics?

p� What other systems currently exist that are similar? What are their strengths and weaknesses?

p� What is the weather environment surrounding the system?

p� What are the characteristics of the people in the surrounding environment: size, strength, skills, literacy, handicaps, etc.?

p� What procedures are currently in place (i.e., construction process, labor relations, management, payments, schedules, or sequences)?

2. Describe the organization’s goals to be achieved.

Finding out what users and stakeholders think is vital to understanding the organization’s goals, since they are the people who set them. Before you try to identify a problem, examine the documented organizational goals for an idea of what success in the organization looks like. Attempt to answer the following questions with as much detail as possible:

p� What are critical factors and/or characteristics of an ideal system?

p� How do you measure performance of the system?

p� What is the goal of your design?

p� What is wrong with the current system? In relation to your goals?




3. Identify what is preventing the organization from achieving these goals.

Identify what is preventing you from achieving the goals examined in the previous step. Having identified obstacles and errors the project team is now ready to prepare the first draft of the problem statement. Don’t worry too much about the quality of the statement at this point—right now, you are simply making a start. It’s okay if it consists of several sentences or a set of bulleted items.

Attempt to answer the following list of questions to determine where the problem lies in the organization. These questions are organized into six categories of possible problems. They do not encompass every type of possible problem, but are rather suggestions for general considerations.

CATEGORY QUESTIONS

1. Strategy Are your projects poorly aligned with business objectives?

Is the implementation of your projects siloed?

2. Service/Product Is there an impediment to service delivery due to the untimely retrieval of information?

Is there a high level of customer dissatisfaction due to errors?

3. Processes Is manual processing too intensive due to physical handling of paperwork, mail outs, and manual coordination of events?

Is there double data entry or manual maintenance of data in spreadsheets or personnel data?

4. Applications Is there poorly developed functionality due to inadequate definition of business and functional requirements?

Is there out of date functionality caused by a constantly evolving business climate?

Is there little or no application support due to proprietary or redundant software?

5. Information Is the information and content stored on various devices unstructured, making search and retrieval very difficult?

Are there disparate methods of coding the same types of datasets in disparate repositories?

6. Infrastructure Is there not a lot known about all systems, making the strategic coordination of maintenance difficult?

Are there multiple applications supported on multiple systems creating unnecessary maintenance overhead by supporting duplicate systems?




4. Analyze the problem.

Now that you’ve identified the problem, expand on it. This activity can be performed with the help of problem analysis techniques and questions like those listed below. Problem analysis techniques that may be helpful according to your situation are described in-depth in the BA Techniques series on www.RequirementCoach.com. See Visualization and Elaboration for descriptions of the most commonly used techniques. Try to answer the following questions with as much detail as possible. It is a good practice to discuss these questions in a group setting.

p� Who does it affect? Who doesn’t it affect?

p� What does it effect? What does it not effect?

p� How does it affect? How does it not affect?

p� When is it a problem? When is it not a problem?

p� Where is it a problem? Where is it not a problem?

5. Finalize the problem statement.

Rewrite the statement based on the analysis results. Now you can focus on the quality of the problem statement. Revise the sentences or bulleted items into as few sentences as possible. According to BABOK, the recommended sentence structure for a problem statement is as follows:

WORDS TO USE WHAT TO SAY

The problem of Describe the problem.

Affects The stakeholders affected by the problem.

The impact of which is

What is the impact of the problem—on each stakeholder.

A successful solution would

List some key benefits of a successful solution.




Once you have finalized the problem statement, enter it into RequirementPro™ as displayed in the screenshot below.

6. Review the problem statement.

Once all of the above activities have been performed, the problem statement should be agreed to by all relevant stakeholders. A suggested practice is for the business analyst or project manager to compose the PD and then present it to a group of stakeholders for discussion and approval. Use the checklist provided in this document on page 18 to ensure the problem statement is sufficiently complete. The problem statement may require a re-write once all stakeholders have reviewed it.

We suggest hosting a workshop to discuss all the deliverables from the Situation Analysis task group at the same time. See page 15 for information on preparing for that workshop.




CollaborationDefining the problem is a process performed much better collaboratively than individually. The task of defining the problem cannot be performed well without the input of relevant stakeholders. The business analyst is responsible for ensuring stakeholders are appropriately involved in problem statement development. It is important to ensure stakeholders feel included in all phases of the project, from beginning to end.

No matter what techniques or methods you decide are best for communicating with stakeholders, it is always important to facilitate a dialogue. Very rarely should the stakeholder read the problem statement for the first time and say “That’s good enough.” The business analyst has to ask questions and promote discussion among stakeholders. There needs to be someone asking questions about assumptions, processes, policies, and your organization in general if you hope to improve anything.

There is no tried-and-true method for collaborating with stakeholders. All stakeholders are different, with different needs and preferences for communication—that’s why you need to make sure to adequately perform Task 1.7 Determine Collaboration Approach. Developing a tailored approach to socializing with stakeholders at the onset of a project will prove beneficial at every phase in the project lifecycle. Depending on the selected approach, the business analyst will determine the best way to go about documenting the problem statement. Different steps in the process will require different types of engagement and communication.

For example, to describe the current conditions, environment, and organizational goals, the business analyst will benefit from observing business processes as they are performed, including their individual activities. Observation allows for a comprehensive view of the actual work that gets done, rather than just trusting users to describe the steps they are supposed to perform to complete a particular activity. Another useful technique for gathering information about the current conditions, environment, and organizational goals is to interview stakeholders, either individually or in groups. Often, the analyst will discover that a combination of the two techniques will work best with the project at hand. Observation is a great technique for validating the data that you have collected from previous elicitation sessions. In addition, it can serve as a stimulus for generating new interview topics and questions.




Reviewing the Statement with stakeholders

One vital step of the problem documentation process that stakeholders need to be involved in is reviewing the statement and coming to an agreement on how it is written and what it says. Depending on the organizational context of the problem, there are multiple ways of ensuring this activity is completed smoothly and successfully. If the organization subscribes to StakeholderPortal™, communicating with stakeholders by using the application is by far the quickest and easiest way to get input and feedback from them, regardless of their location. There are two ways the business analyst can ensure stakeholders are involved in the problem statement review process via StakeholderPortal™:

p� Publish an Announcement on the Dashboard: When a user creates a news feed post, all project contributors and stakeholder users are automatically notified via email. If you would like to include all project contributors and related stakeholders in the review process, publish a post to easily and quickly notify them. In the news feed post, notify the project contributors that the problem statement is ready for review.

p� Assign Action Items: Action items are tasks that can be assigned to any individual user in RequirementPro™ or StakeholderPortal™. If you would only like specific users to review the problem statement, assign an action item to each individual. The user will get an email notification to perform that task. Once an action item has been completed, the assigned user notifies the assigner.

To review the problem statement, stakeholders should refer to a checklist like the one provided in this document to determine whether the problem statement is well-written and addresses the needs of the organization. Once they have been notified that the statement is ready for review, either by announcement or action item, the stakeholders should comment on the record in the application to voice their opinion. The business analyst will take all comments into consideration in the final rewrite.

If your organization is not using StakeholderPortal™ to reach stakeholders, there are other options for ensuring the business analyst receives the necessary stakeholder input. If there are many stakeholders in different locations, it may suffice to email all relevant stakeholders asking for their feedback. If stakeholders are located in the same place, another technique for communicating with them is to hold focus groups, which are made up of a small number of people brought together to discuss a specific topic. Meetings with multiple stakeholders are a great way to collaborate with a variety of stakeholder personas.




Visualization and Elaboration The following techniques are commonly used to visualize and elaborate the problem statement. While these are the most popularly used techniques, they are not the only ones available for problem analysis. For a complete list of problem analysis techniques, see the Requirements Excellence Framework™.

Ishikawa Diagram (AKA Fishbone Diagram, Cause-and-Effect Diagram)

One of the most commonly used techniques for exploring a problem and its root causes is an Ishikawa Diagram. This technique is especially helpful when the project team is having difficulty brainstorming causes of a problem. To use an Ishikawa Diagram, you need to have a problem in mind and a whiteboard or flipchart for taking notes. This technique is performed best in a group setting. The general procedure for using an Ishikawa Diagram is as follows:

1. Write the problem statement at the right center of the whiteboard or flipchart. Draw a box around it and draw a horizontal arrow running to it.

2. Brainstorm the major categories of problem causes. Categories typically included are:

p� People: Anyone involved with the processp� Activities: How the process is performed and the specific requirements for doing it,

such as policies, procedures, rules, regulations, and lawsp� Applications: Software or applications that are used to perform the problemp� Inputs: Inputs that are needed to start the processp� Outputs: Outputs from the processp� Metrics: Data generated from the process that are used to evaluate its qualityp� Environment: The conditions, such as location, business unit, culture, and time

in which the process operates

Causes Effects

Environment

Process

Materials

Equipment

Management

People

Problem

Seco

ndar

y Cau

se

Seco

ndar

y Cau

se

Primary Cause

Seco

ndar

y Cau

se

Seco

ndar

y Cau

se

Seco

ndar

y Cau

se

Seco

ndar

y Cau

se

Seco

ndar

y Cau

se

Seco

ndar

y Cau

se

Primary Cause Primary CausePrimary Cause

Seco

ndar

y Cau

se

Seco

ndar

y Cau

se

Primary CauseSe

cond

ary C

ause

Seco

ndar

y Cau

sePrimary Cause




3. Write the categories of causes as branches from the main arrow.

4. Brainstorm all possible causes of the problem. Ask questions about why certain events occur. As brainstorming participants provide ideas, the facilitator writes them down on the appropriate category branch.

5. Again, ask the question “Why does this happen?” about each cause. Write sub-causes branching off the appropriate causes. Continue to ask why to determine deeper levels of causes. Layer branches to indicate causal relationships.

6. Now, you should have a diagram displaying all possible causes of the problem that the project team can think of. Depending on the complexity and importance of the problem, you can now investigate the most likely causes further. This may involve setting up investigations, carrying out surveys, etc. to test which of the possible causes is actually contributing to the problem.

Mind Maps

Mind mapping is another great technique commonly used for exploring a problem and its causes. Mind map diagrams have a basic tree format, with a single starting point in the middle that branches out, and divides again and again. The tree is made up of words or short sentences connected by lines. The lines have meaning as well, signifying a relationship between two entities. One simple method for using a mind map is to perform a 5W (and 1H) Analysis of the problem at hand, which means you examine the:

p� Who

p� What

p� Where

p� When

p� Why

p� How

Look at each W (and the H) on the mind map and extrapolate each one to a lower level of detail. Then, possible causes will begin to emerge.

Where

Why

How

Problem

Who

What

When




A3 Report

A common Lean technique for documenting the problem statement is to create an A3 Report. A3 is the international standard name for a piece of paper sized 11”x17”. The process of creating an A3 Report involves dividing the problem definition into four quadrants on a single sheet of paper. This structured report format allows the report to be clearly and consistently communicated on one page of paper, reducing the waste of report writing and reading. The A3 problem solving technique is great when collaborative thinking is required. An A3 Report should be divided into the following sections:

1. Problem Statement: Provide the problem statement as it was determined using the process described in this document.

2. Current Conditions: Briefly describe the current conditions within the organization surrounding the problem.

3. Target Conditions: Briefly describe the conditions that will exist once the project has been completed.

4. Barriers to Taking Action: Briefly describe anything that may pose an obstacle to problem resolution.

Information should FLOW and be simple.

Background & Problem Statement

Target Condition

CurrentCondition

Barriersto Taking

Action




Comprehension Exercise Complete the following three-step exercise for practice in developing a complete problem statement. For best results, perform this exercise with a group of individuals to allow discussion.

Step 1: After reading the scenario below, identify and write down the problem in the space provided.

Step 2: Revise the problem to adhere to the designated structure:

The problem of

affects

The impact of which is

A successful solution would

One of Enfocus Health’s strategic organizational goals is to ensure every client has an electronic medical record. But, because of a recent merger, achieving this goal has been prevented by the existence of two separate medical record systems. RHS uses Clinicare and AHS uses a home-grown system. Because of a lack of integration, wait times have increased from 1 hour to 3 hours over the last year, and administration spends up to 15% of their day searching for records and resolving issues.




Step 3: Compare your problem statement to the one we created below.

Since inception, Enfocus Health has always worked towards the goal of every client of the health centre having an electronic medical record. However, because they are a result of a merger between AHS and RHS, the full achievement of their goal has been prevented by the lack of integration and effectiveness of having two separate electronic medical record systems.

RHS was using Clinicare system, and AHS was using a home-grown system. While Enfocus Health has been able to operate with both of these systems, it has not been effective, wait times are slowly increasing, and client records are routinely lost resulting in poor customer service and increasing wait times.

According to recent analysis, wait times have increased from 1 hour to 3 hours over the last year. And administrators spend up to 15% of their day searching for client records, or resolving issues with existing ones.

The two separate systems are the direct causes of these previously mentioned problems and affected areas include: clinical, financial, community services, education, research and quality improvement. The critical areas of improvement for Enfocus Health include better client medical record management, decreased client wait times, more effective planning and decision making, improved learning environment, superior client record accessibility, improved client confidentiality and privacy, and better client interaction and client satisfaction.




Situation Analysis WorkshopThe activities that make up the Situation Analysis task group are so vital to the rest of the project that we suggest setting up a focus group or workshop with relevant stakeholders to review and revise the Problem Definition as it has been developed by the BA. During the same meeting, it is a good idea to also review other deliverables from Situation Analysis, such as the vision statement, organizational context, capability gaps, business objectives, and project constraints. Perform the following steps to prepare for the workshop:

1. Develop a statement of purpose, scope, or objective for the workshop. Present the concept to management and obtain commitment from the project sponsor.

p� Purpose: why the workshop is to occur. p� Scope: what will be included and excluded.

p� Objective: what is to be accomplished.

2. Meet with key subject matter experts to become familiar with the business area under focus (basic business flow and business terms, acronyms, and jargon). This is not so you can participate, but rather to reasonably facilitate the workshop discussion.

3. Identify participants.

4. Interview the potential participants. p� Get an understanding of the business need. p� Identify potential issues and resolve them prior to the workshop.p� Understand the concerns and attitudes (hidden agendas) of the participants.p� Understand the group dynamics and identify potential “problem people characteristics.”

p� Suggested interview questions:pp Describe the current process. pp What do expect from the workshop?pp What is your understanding of the purpose of the workshop?pp What should the output of the workshop look like?pp Do the participants have authority to make decisions?pp Who should attend? Why? Who should not? Why? pp What materials or work products will be needed as aids to discussion?

pp What would prevent you from attending the entire workshop?

5. Prepare participants. p� Identify any materials or work products they need to bring.

p� Get commitment to attend the entire workshop.

6. Develop an approach (step-by-step activities necessary to accomplish or create the deliverables). Set the agenda. Use the agenda worksheet on the next page.




Agenda Worksheet

Workshop Purpose:

The purpose of this workshop is to...(summarize the expected outcome)

so that...(identify how the requirements deliverables will support the project objective).

Location: Date: Time:

Participants:

Participant Meeting Preparation:

Information or Materials to Bring:

Workshop Start: Time Allocation:

Welcome and introductions

Review the workshop purpose statement

Present the agenda

Explain the ground rules

Execute kick-off

Workshop Process (Activities): Time Allocation: Expected Outcome:

1.

2.

3.

(insert additional rows as needed)

Workshop Finish: Time Allocation:

Review workshop accomplishments

Identify next steps

Review and assign open items

Evaluate the workshop

Roles:




Group Discussion GuidelinesThe very best problem statements are created in an iterative, collaborative process with the help of relevant stakeholders. This means that the exercise is guided, materials are developed with a sense of formality, and the analyst is armed with some penetrating questions or ideas that will help in a group discussion. The suggestions below are for after you’ve developed your problem statement and should be used at a time when you are either guiding the team through the exercise of thinking and refining, or, you are in a period of quiet reflection and wanting to go that extra mile for quality.

p� Timeliness is key: a team may recognize a problem, but to get to action, an executive must accept that action needs to take place now. Ask your team questions like, “What is it about this problem that requires immediacy?” “When you read the list of impacts, do they suggest or imply ‘Why take action today?”

p� Think economics and emotions: when dealing with a larger initiative, benefits need to be both economic and emotional. People seldom take action solely on the merits of one in the absence of the other. Think pragmatically—what is the economic benefit that links this problem to corporate goals? Then, think idealistically—what is the emotional reason that makes the future better? When crafting the key benefits, ensure you capture the imagination of both the analytic and the visionary.

p� Remove the adjectives: words like “very,” “bad,” “good,” etc., are by nature judgemental rather than objective and take away from making a concise problem presentation. Think about dropping them from the problem statement.

p� Use words that resonate: a popular technique is to get other people to talk about the problem to find a way to express the problem in a way that resonates. A problem statement must gain agreement and acceptance to have value. If people have to work hard to understand the problem, then you need to keep working on how it is being expressed. A great problem statement isn’t just a great idea—it’s also a great expression of that idea.

p� Talk about implications: a great problem statement is understood to have significant implications directly related to the organization. Discuss them with the team, and keep it simple rather than stretching credibility past belief. When people agree on the implications of something, and those implications have an impact on direct cost, quality, service, brand, etc., then you have reached a consensus on why you need to do something about it.




Task Completion Checklist After the problem statement has been entered into RequirementPro™, the project team and relevant stakeholders must review the problem statement to ensure everyone agrees to it and understands it. As you review the problem statement, weigh it against the following criteria:

CRITERIA DESCRIPTION ✓

Concise The essence of your problem needs to be condensed down to a single sentence. A reader of the problem statement should be able to say, “Aha! Now I can understand the problem.”

Specific The problem statement should focus your thinking, research, and solutions toward a single population or issue.

Measurable Problem can be measured in terms of degree and frequency. The strongest problem statements incorporate measurable aspects of both the degree and frequency of the problem as it exists.

Specifies Impact The problem statement should identify the population affected by the problem.

Unambiguous The statement should be written clearly enough that the reader cannot make his/her own assumptions.

Solution-free While the problem statement should give the team direction in designing the solution, it should not have any actual solution design elements.

Related Content in RequirementCoach™Analyst Brief: Writing Great Problem Statements: As documenting complaints or listing prescribed requirements does not accurately document underlying problems, this brief provides help with writing great problem statements.

Training Video: Three Levels of Software Requirements: We can organize or thoughts about requirements with a three-level model. The top level represents the business requirements, the second level represents the user requirements, and the third level represents the functional requirements. This video was created by Karl Wiegers.

Tips for Successful Business Process Improvement Projects: Although every part a business will probably benefit from a business process improvement project, some processes will return much bigger benefits than others. It is very important that the first area chosen has the potential to return big benefits.




IntroductionThe project vision is a description of the desired state or ultimate condition that should exist after the project has been completed. Without clear boundaries, it is harder to anchor the solution scope. With consensus on the outcome, it is clearer for staff and stakeholders as to where the project ends. The vision allows the analyst to stay objective and impartial in the face of risks like being drawn into an ever-widening circle of interventions because you can always refer people back to the vision and ask if that’s now changed. The project vision helps to document the necessary boundaries.

Defining the project vision is also key in ensuring stakeholders are motivated to agree to initiating the project. Documenting the project vision in a well put-together statement sets a foundation for early investigation work that will be included in the business case. It will serve as a basis for team discussion concerning high-level business requirements, as well as stakeholder needs. Once those elements have been determined, the vision statement will help to ensure all project contributors remain focused on the project’s goals.

Chapter Two: Define Vision

Define Vision

2.2 Chapter Two



Core Concepts

Vision Statement

Typically, the vision is expressed in a vision statement, which is a brief statement or paragraph that describes the why, what, and who of the desired software product from a business point of view. While the statement does not give direction on how to implement the solution, it does provide direction to business analysis planning. Later in the project lifecycle, the vision statement will provide context for making decisions throughout the course of the project’s life. The analyst always wants to be in the position to ask, “Is this consistent with our vision, or are we changing solution scope here?”

What goes into it?

Describe the desired future state and make sure to refer back to stakeholder interests, as well as provide relevant background. The vision statement should include information about your target customers, a description of the need or opportunity being addressed, and an explanation of the primary advantages of the project (in other words, it should include the who, what, and why of the project).

Where does it get used?

The vision statement will be presented to stakeholders in the early planning stages of the project for discussion and collaboration. The understanding of that vision and what it means to all stakeholders in terms of solution and implementation tactics deepens over the course of the project.

When is it created?

The project vision should be developed after the problem statement, before capability gaps have been assessed.

Participants

Ideally, the project vision statement should be written by the project sponsor. However, a business analyst or project manager may prepare the vision on behalf of the sponsor. In this case, the project sponsor will need to approve and support the vision. While only one individual may actually write the vision statement, many individuals need to be involved in its creation. Get stakeholders to participate in the drafting of the vision. Producing a vision without stakeholder involvement, might make stakeholders feel as if they are being told what to do. They may not agree with or support the vision. Also, you want stakeholders actively engaged rather than passively engaged. When stakeholders are actively engaged, the vision statement is in their words, the buy-in is much higher, and the vision statement can be used with more confidence later in the project.




Benefits of a Good Vision Statement

The vision will ultimately serve as the foundation for project tasks, including defining solution needs and validating requirements. The vision statement is the common starting point for discussion about more specific activities and outcomes. A well-crafted vision statement does three things:

p� Grabs and directs the project team’s attention

p� Sets the project team’s agenda

p� Energizes the project team’s work

Qualities of a Good Vision Statement

Summarizes the vision in a powerful phrase. Capturing the essence of your vision using a simple memorable phrase can greatly enhance the effectiveness of the vision statement. If you have trouble coming up with a succinct summarizing phrase, try adding one after you’ve written the rest of the vision statement.

Describes people, processes, and technology. The vision should describe the process, how the technology supports the process, and how stakeholders will benefit from the new solution. Ensure that the vision is aligned with organizational goals; try to link the vision to achieving a specific organizational objective. A powerful phrase is only useful when it is grounded on a powerful idea.

Ensures the reader understands the sense of importance. Upon reading the project vision, stakeholders should be able to understand and verbalize why the project is important and be able to see how the solution, once implemented, will help the organization obtain its desired state and outcomes.

Takes up as much space as needed. Good vision statements require more than one sentence. The purpose is to create a mental picture charged with emotion that can serve to energize and inspire you and your team, while at the same time ensures that you all have the same understanding.




Process

1. On your own or with the help of a small focus group, begin to draft the vision statement. Remember to include the who, what, and why.

2. Describe the envisioned process, the technology needed to get there, and how the stakeholders will benefit.

3. Ensure that the project vision aligns with organizational goals. The vision should be easily linked to achieving a specific corporate objective.




4. To present the rough draft vision statement to all relevant stakeholders, document the draft in RequirementPro™ and announce its availability for review by creating a project announcement on the Project Dashboard. Let project contributors and stakeholders review the vision statement in RequirementPro™ and StakeholderPortal™, and then discuss revisions in the group setting of the Situation Analysis workshop discussed in Chpater One: 2.1 Document Problem. Encourage stakeholders to comment on the Project Overview with their initial input. This will help set the foundation for workshop discussions.

5. Revise the statement according to the results of the discussion. Don’t forget to edit the documented version in RequirementPro™. This way, when you onboard a new stakeholder, they can get an understanding of the project’s goal.




CollaborationThe best way to make sure stakeholders participating in creating the vision statement is to set up a focus group or workshop in which the project vision is discussed in-depth. As mentioned in step four of the process, it is suggested you hold a workshop where stakeholders can provide feedback on all six tasks in the Situation Analysis task group.

When you get resistance on spending time on a vision statement, remember: the most important thing is to get people talking. People who are very operationally focused sometimes don’t like to engage with what they see as excessive introspection. But, when you get the stakeholders talking and starting to make tangible connections using some of the visualization methods suggested in this guide, they appreciate that this exercise is helping to bring a shared clarity that they might not have been able to achieve themselves.

If you’ve created many vision statements before, the visualization techniques presented in the next section offer ideas for dealing with various stakeholder situations. For the analyst that has facilitated fewer sessions like this, here are a few pointers for getting started:

p� Pick one. One of these visualizations is likely to resonate more for your style of running a meeting. Use that one and go with it. All of these will take you over the goal line.

p� Practice it first on a project you know. Everyone has a wealth of past projects you’ve done. Visualize that project, and start mapping the words into the diagram. See where that takes you, and then refine it.

p� Practice it on a fellow analyst for the project they’re working. Talk to him/her over coffee. After a 30 minute conversation, you will have tuned your technique a little, built more confidence in the flow of the facilitation approach, and will be better prepared for facilitating a group discussion with stakeholders.

Entering your vision statement into RequirementPro™ enables collaboration and promotes it to the rest of the project team. Once in RequirementPro™, stakeholders can review the vision statement, ensure their interests are included and offer their comments. Having a vision statement documented in a place where everyone can easily find it is helpful when all stakeholders cannot take part in the Situation Analysis workshop.




Visualization and Elaboration

Concept Diagrams

Concept diagrams are rather similar to mind maps, which were discussed in Chapter One: 2.1 Document Problem. Although both can be great tools for group-driven brainstorming, mind maps are often restricted to radial hierarchies and tree structures. A concept diagram can be a map, or system view, of a real or abstract system or set of concepts. This technique is more free form than mind maps, as multiple hubs and clusters can be created, unlike mind maps which fix on a single conceptual center.

Concept diagrams provide a way to collaboratively model and transfer your knowledge to the other project contributors and stakeholders. They can be useful in eliciting and representing the knowledge of domain practitioners and contributing to the design of the solution. Concept diagrams are a useful tool for supporting the high-level design of new technologies (e.g., interfaces). They help you visualize the relationships between different concepts within a central focus.

When creating a concept diagram, the general concepts are usually drawn at the top, with more specific concepts arrayed hierarchically below. The lines connecting the concepts contain keywords or phrases that summarize the relationship between the topics that connect. For example, Concept A “causes” Concept B. Concepts may be cross-linked with each other to depict more complex relationships between concepts.

Concept

ConceptConcept Concept

Concept ConceptConcept Concept

Concept ConceptConcept

relationship relationship relationship

relationshiprelationship relationship

relationship relationship

relationship relationship




Business Models

According to Alexander Osterwalder in his book, Business Model Generation, a business model describes the rationale of how an organization creates, delivers, and captures value. The business model is like a blueprint for a strategy to be implemented through organizational structures, processes, and systems. The project vision needs to be able to fit into that strategy. A business model should already exist before project implementation. If it does not, you will probably benefit from creating one. Using the business model for inspiration is a great starting point for discussion of how to achieve business value. According to this technique, there are nine basic building blocks that can be used to describe the business model. The nine blocks include the following:

p� Customer Segments: defines the different groups of people or organizations an enterprise aims to reach and serve.

p� Value Propositions: describes the bundle of services or products that create value for a specific customer segment.

p� Channels: describes how a company communicates with and reaches its customer segment to deliver a value proposition.

p� Customer Relationships: describes the types of relationships a company establishes with specific customer segments.


generate

generate

carry

carry

generategenerate

generate

buys one

buy from

keeps

proprietary

require

self

require specific

protected by

protected by

starts lifecycle

generate

Key Resources

Channels

Cost Structure

Key Partners Key Activities Value Propositions Customer Relationships Customer Segments

Manufacturers

Marketing

Logistics

R&D

Retailers

Brand

Patents

Razor handles

Razor blades

“Lock-in”

Customers

Retail

Handle purchase (1x) Blade

replacements

Logistics

R&D

Legal

Manufacturing

Marketing

buys many

Revenue Streams



p� Revenue Streams: represents the cash a company generates from each customer segmentp� Key Resources: describes the most important assets required to make a business model workp� Key Activities: describes the most important thing a company must do to make its business model work.p� Key Partnerships: describes the network of suppliers and partners that make the business model work.

p� Cost Structure: describes the costs incurred to operate a business model.

REMEMBER: When you use a business model like this to facilitate the vision statement, the vision statement describes the domain of change. What’s new, or augmented in the diagram, as a result of this project needs to be visually apparent unless it’s all net new.

The Four-View Model

The four-view model is a discussion/brainstorming technique that consists of four key areas that must be addressed in the completed vision statement. This technique can be used as a memory aid when discussing the project vision with relevant stakeholders. It can be used to make sure that the vision statement encompasses the necessary changes in people, processes, technology, and organization. As you can see below, the four-view model illustrates the fact that the entire organization consists of four elements that need to work together.

When you discuss the necessary changes in one triangle, it is vital that the other three triangles of the model are considered and the corresponding changes are identified. The four views that you must discuss to develop the project vision include the following:

p� Organization: the management structure, roles, responsibilities, and resources.p� Processes: the business processes used to deliver the organizations’ services and to support its work.p� People: the employees responsible for implementing the business processes carrying out the work of the organization.p� Technology: the hardware and software systems used to support the work of the organization.

Organization

Technology

Process

People




Impact Mapping Sometimes referred to as Effect Mapping, Impact Mapping is an innovative new concept for strategic business planning developed by Gojko Adzic, a renowned strategic software delivery consultant. According to Adzic, impact mapping is a great way to engage senior business and technical experts at the start of work on a project to create a shared understanding of scope—not from a technical but from a business perspective. Visual collaboration techniques ensure that senior decision-makers share an understanding of key business requirements, helping to align project contributors and stakeholders with the overall vision, and giving delivery experts enough information to make the right decisions later.

An impact map is a visualization of scope and underlying assumptions, created collaboratively by senior technical and business people. They help to define goals by requiring you to identify the expected goal as the first activity. Impact maps are simple mind maps that grow during a discussion that is facilitated by answering four questions:

p� Why? Why are we doing this? What is the desired business change? In the center of the impact map, describe the goal you are trying to achieve.

p� Who? Who can produce the desired effect? Who can obstruct it? Who are the consumers or users of the system? Who will be impacted by it? In the first branch of the map, describe the actors who can influence the outcome.

p� How? How should our actors’ behavior change? How can they help us to achieve the goal? How can they obstruct or prevent us from succeeding? In the second branch of the map, describe the impacts you are trying to create.

p� What? What can we do, as an organization, to support the required impacts? In the third branch of the map, list the deliverables, software features, and organizational activities that will facilitate goal achievement.

Who?

Why?

Who?

How?

How?

How?

How?

What?

What?

What?

What?




Answering the questions on the higher level branches will help you develop the vision statement. A suggested practice is to use the impact mapping method for discussing high level business requirements in the Situation Analysis workshop. Fill out the first few branches of the impact map, and then, when it’s time to develop the solution scope, use the impact map technique to map the solution’s features. In the end, the hierarchical nature of the map will clearly show who benefits from a particular feature, why, and how it contributes to the end goal. An impact map is incredibly helpful in that it allows you to focus on the things that are important immediately and still keep a high level overview of the entire scope for later.

For more discussion on impact mapping, refer to 3.0 Solution Conceptualization Reference Guide.

Task Completion ChecklistA good vision statement should focus on the desired outcome of the project/goal at its completion data. There are a few general guidelines for writing a compelling and powerful vision statement. Weigh your completed vision statement against the checklist below:

✓

Summarizes the vision in a powerful phrase.

Describes people, processes, and technology.

The sense of importance is easily understood.

Clearly specifies the who, what, and why.

Clearly connects the project to a strategic business objective.

Approved by the project sponsor.

Approved by relevant stakeholders.




What to do When You are Handed a Bad Vision StatementLet’s say you’ve been handed a vision statement and set of objectives that fail the test on the previous page, what do you do? Many times—not always—the problem is one of information organization and trying to unbundle the ideas from the way they are written. Start by taking each sentence made in the vision statement and unpacking it into to two types of categories of information:

1. GOAL: An outcome the company wants to achieve through the project.

2. OBJECTIVES: Statements that quantify a specific goal. These are always measurable. Often there is more than one objective for every goal.

Fill in the below table using as few words as possible to represent the idea. No adjectives, no filler words like “synergy,” just write down the idea.

You will quickly realize the following:

p� There are goals without objectives.

p� There are objectives that are unlinked to any apparent goals.

p� One or two of the goals are really more overarching statements that encompass all the other goal statements.

The facilitation activity is then to work with the stakeholder team to fill in the blanks, and begin to clarify which of the overarching themes you see is really the purpose (vision) of the project. To see this technique in action, see page 33.

GOAL: WHAT WE WANT TO ACCOMPLISH OBJECTIVE: HOW WE MEASURE SUCCESS ON THE GOAL

Goal 1 Statement p�

p�

p�

Goal 2 Statement p�

p�

p�




Application Exercise Quickly read through the vision statement below. Mark the phrases that can be re-worded to make them more effective, and then edit the vision statement in your own words in the space provided. Refer to the Task Completion Checklist on page 29 for a reminder of what the vision statement needs to consist of. Compare your edited version with ours on the next page.

Implementing a single electronic medical records system will address some customer complaints in health care and make us the best healthcare center in the state. At this time, we need to implement a single electronic medical records system that will help us lower wait times, expand programs and services, and provide every client with an accurate single electronic medical record. This means Enfocus Health will become an industry leader and the best health center in the country.




In the vision statement on the previous page, there are few things that are actually okay with it. In the beginning, notice how it lacks a really powerful phrase that gets your attention or gives you motivation. Also, note how the statement doesn’t take the time to describe the people or processes the project will truly impact. The most important weakness is that it doesn’t connect the project vision to a shared organizational goal. If a stakeholder were to read that vision statement, they wouldn’t get an understanding of the project, or receive any motivation to take part. Read the vision statement below for an idea of how to connect the project’s goals with the strategic business objectives laid out by the organization.

Implementing a single electronic medical records system will address the top 3 customer complaints in health care and make us the most innovative and forward-thinking healthcare center in the country.

Since our establishment, Enfocus Health has always strived for low wait times, expanded programs and client services, as well as a completely electronic keeping of all client medical records. Over the years we have done well to achieve a good part of these goals—we have some of the lowest wait times in the country, our programs and services have grown 30% since we first started and we do have electronic medical records for our clients. However, over the last year our numbers have been slipping and we have been seeing an increase in wait times, stagnant growth of our programs and services and our electronic records have been the cause of many customer complaints, and in some cases even a lack of proper care for our clients.

It’s time we move forward and implement a single electronic medical records system that will help us to get back on track and meet our business goals of a 10% decrease in wait times, 15% expansion of programs and services, as well as every single client having an accurate single electronic medical record.

For our doctors this will mean more efficient access to client information and therefore more effective client treatment. For our nursing staff this will mean less confusion and less time spent sorting out medical records and more time caring for our clients. And for our client this will mean significantly decreased wait times, and better treatment for their ailments.

And for Enfocus Health, this will mean being an industry leader and the best health center in the country.




Take a minute to check how this NEW vision statement on the previous page is mapped using the technique suggested on page 30.

We can use this chart to determine what changed:

1. Every goal is now made more tangible through measurement. The expected organizational impact is clearer.

2. The team DECIDED that this project is more about the reduction in customer complaints, than the accuracy of the medical record. The former, in the minds of the stakeholders, has more compelling impact.

The vision statement could easily have been goal 1 or 4 as both could be the overarching thing the company is trying to accomplish through this project. When stakeholders selected ‘reduction in customer complaints’ as the primary objective over accuracy it brought more clarity to this project, and it’s pretty easy to see how this guidance would be useful in keeping people focused and making decisions aligned to this outcome as the project progresses.

GOAL: WHAT WE WANT TO ACCOMPLISH OBJECTIVE: HOW WE MEASURE SUCCESS ON THE GOAL

Goal 1: Reduce customer complaints p� Recognized as most innovative and forward thinking healthcare center in the country (as measured by satisfaction)

p� Address top 3 sources of complaint

Goal 2: Reduce wait time p� 10%

Goal 3: Expand programs and services p� 15%

Goal 4: Accurate medical record p� Every patient has an electronic record

p� Doctors access to record improves: positive clinical impact

p� Nurses: lower error, less administration




Group ExerciseThe following exercise is a tool that was created to help a collaborative group define and agree upon the project’s end goals. In a collaborative group meeting, work through the steps of drafting a vision statement for a project. We suggest distributing a document similar to the exercise below.

Step 1: Each individual must take a few minutes to think about the answer to the question stated below. Write the answer in the space provided.

If our success could be guaranteed, what would be the end result of our efforts?

Step 2: After writing your answer, discuss your ideal outcomes as a full group. Have someone record the answers. Ideally, the recorder is someone other than the individual conducting the meeting.

Take about 10–15 minutes to perform this exercise. Don’t forget to designate a recorder!

Step 3 (if needed): Get a commitment from a small sub-group (no more than 2–4 people) to develop a draft vision statement from the information generated for review at a later time by the full group.




Chapter Three: Define Project Objectives

IntroductionToo many people take too little time to correctly define and document the project’s business objectives. Since the objectives are going to drive project development, they’re something you want to spend time with when you’re defining them. This task doesn’t only take ten minutes, which is the amount of time too many people put into defining objectives; instead, set aside a considerable amount of time to adequately determine what the solution will need to achieve to solve the business problem at hand.

The purpose of developing good business objectives is to position the project for success and produce a successful return on investment (ROI). However, you can’t define those high-level business objectives without figuring out how to get there. According to the ROI Methodology, to achieve the ROI objective, you need to set various levels of other goals (or objectives) that lead up to it. The ROI Methodology is a process developed by the ROI Institute that has been used consistently and routinely by thousands of organizations in the past decade. Instead of or in addition to an organizational or project Balanced Scorecard, the Enfocus Solutions process for defining business objectives is based on the proven success of the ROI Methodology.

Using the ROI Process to define project objectives produces results-based solutions:

p� Projects are developed and delivered with the solution in mind.

p� Stakeholders know that their responsibility is to obtain results through the project.

p� A measurement and evaluation system and process is used for each project.

p� Multiple approaches are used to measure contribution to produce a balanced view-point.

p� Follow-up evaluations are developed to measure project progress and results are reported to stakeholders.

Define Project Objectives

2.3 Chapter Three




Core Concepts

Business Objective

Business objectives are high-level business requirements that provide a clear understanding of the goals that the organization seeks to achieve. An objective can relate to a change desired by the organization or to a condition that the organization wants to maintain. Identifying business objectives contributes to the task of controlling scope creep and is the first step toward achieving a successful return on investment (ROI).

When you’re developing the project objectives, remember to avoid weak objectives. Powerful objectives include the conditions under which an objective is achieved, as well as criteria demonstrating objective achievement. Although they contain considerably less detail, business objective statements should be written with the clarity and conciseness of requirement statements.

Balanced Scorecard

The Balanced Scorecard is a popular strategic planning and management system used to ensure business activities are aligned to the overall vision and strategy of the organization. The developers of this technique were the first to acknowledge the importance of measures other than financial ones in achieving a balanced view of the organization’s performance. The Balanced Scorecard provides a framework that helps develop performance impact measurements, as well as identify what should be done and measured in the project. If there is one already developed in the organization, we suggest referring to it often to ensure the project aligns with the organization’s strategy. In some organizations, executives in different functions develop scorecards to reflect their business segments. Often, the organization may have one main scorecard for the entire organization, and then individual ones per department.

ROI Methodology

Before we discuss the process of defining business objectives by using the ROI methodology, let’s get acquainted with the methodology first. This leading method for determining the ROI of a project was created by Dr. Jack J. Phillips in the 1970s and has since then been widely implemented and developed by the experts at the ROI Institute, Inc. The ROI Institute focuses on everything ROI, including ROI competency building, implementation, networking, and support. Dr. Jack Phillips has written and edited numerous award-winning series and books, and is known worldwide for his expertise on accountability, measurement, and evaluation. Another large advocate and supporter to the ROI Methodology is Dr. Patti P. Phillips, Dr. Jack Phillips’ wife. Dr. Patti Phillips serves as president and CEO if the ROI Institute, Inc., and is also known world wide for her expertise in accountability and ROI measurement and evaluation.




The basic idea behind the ROI Methodology is that you can’t simply define the project’s ROI and expect to achieve it without setting up some milestones along the way. Instead of setting the ROI and quickly defining some high-level business measures, the ROI Methodology takes the time to properly assess needs and then define and measure objectives to result in a better ROI. Because of its success, the ROI Methodology became well known and widely used after its creation in the 1970s and has been continuously updated and improved since its creation over 20 years ago. The ROI Methodology is widely used all over the world. In fact, according to the ROI Institute...

p� Over 4,000 organizations are implementing the ROI Methodology.

p� Over 4,000 individuals are certified to implement ROI Methodology.

p� Over 100 articles on the ROI Methodology have been published in 30 countries.

p� 30 books have been published on ROI Methodology and application.

p� ROI Methodology and application books have been published in 33 languages.

p� ROI is currently being implemented in over 51 countries and is expected to keep spreading.

Dr. Jack Phillips created the ROI methodology when he noticed a shifting paradigm in the way businesses functioned—organizations were moving more away from activity-based projects, and more towards results-based projects. Activity-based projects of the past focused on inputs for project planning and reporting and didn’t include business needs, measurable objectives, a baseline assessment, or cost-benefit analysis. In fact, activity-based projects didn’t even measure results. Dr. Phillips realized that there needed to be a unified process for producing projects that yield quantifiable results, and so the ROI Methodology was born. The ROI Methodology is very much a results-based process because it links programs/projects to specific business needs, assesses performance objectives, lists objectives for behavior and business impact, communicates expectations and impacts to project participants and stakeholders, measures results, and focuses planning and reporting on outcomes.

The ROI Methodology works because it offers a step-by-step process and a balanced set of measures to determine ROI. It is successful because the ROI Methodology works as a segue between business evaluation and program evaluation while balancing research and statistics with a practical application. Two reasons the ROI Methodology is so well used is because it is flexible for all types of programs, and credible enough to be accepted by Managers and Administrators.




There are many common problems in projects that can be solved by diligently developing the project’s business objectives as pointed out by the experts at the ROI Institute, such as:

p� Lack of business alignment

p� Inappropriate project solution

p� Project participants are not engaged

p� Lack of focus on business results

p� Failure to prepare the environment for the project

p� Lack of accountability within the project

p� Problems with data collection

p� Failure to isolate the effects of the project

p� Lack of involvement with key managers

To ensure you create a full set of objectives that address the problems listed above, the ROI Institute instructs the business analyst to develop the project objectives in levels that range from the stakeholders’ perception of the project all the way to the actual ROI. Different levels of business objectives provide you with a way to measure the success of a project in every stage of the lifecycle. Developing objectives in levels will help you to ensure the project delivers the desired value. The different levels ensure you collect data at different intervals in the project, which in turn ensures you keep track of project progress. The table below describes the five levels of evaluation that will be used to define and measure business objectives.

EVALUATION LEVELS MEASUREMENT FOCUS

Level 1: Reaction & Perceived Value

The reaction to and perceived value of the project. Measures participant satisfaction with the program/project.

Level 2: Learning & Confidence

Learning to use the content and materials, including the confidence to use what was learned. Measures changes in knowledge, attitudes, and skills.

Level 3: Application & Implementation

Use of content and materials in the work environment, including progress with actual items and implementation. Measures changes in on-the-job behaviors or actions.

Level 4: Impact & Consequences

The consequences of the use of the content and materials expressed as business impact measures. Captures changes in business impact measures.

Level 5: ROI Comparison of monetary benefits from program to program costs. Compares the benefits to the costs.




Process

Step One: Utilize a Balanced Scorecard, the ROI Methodology, or Both.

Before you begin the process of defining business objectives, determine if your organization has a Balanced Scorecard. If so, you should first complete the Balanced Scorecard section in RequirementPro™ to ensure the project vision aligns with the organization’s strategic objectives already in place. For each of the four perspectives, answer the question, “How does your project support the Balanced Scorecard?” Each perspective consists of pre-defined strategic objectives, measures, targets, and initiatives. As the business analyst, it is your responsibility to ensure this project aligns with each one of the elements in the scorecard. The Balanced Scorecard is an especially great resource for determining the measures for each objective, a task discussed later in this guide. The four perspectives of the Balanced Scorecard are Learning and Growth, Business Process, Customer, and Financial:

p� Learning and Growth Perspective: includes metrics put in place to guide managers in focusing training resources. “Learning” also refers to things like mentors in the organization and users’ ease of finding help for problems.

p� Business Process Perspective: includes measures that show how well the business is running and whether its services meet stakeholder requirements.

p� Customer Perspective: focuses on the importance of customer satisfaction.

p� Financial Perspective: includes the traditional need for financial data.

If your organization does not have a Balanced Scorecard already developed, the professionals at Enfocus Solutions recommend that your organization creates business objectives using ROI Methodology, and avoid creating a Balanced Scorecard all together for efficiency’s sake. Often times, Balanced Scorecards are required by an organization’s management and executives and are then used to determine objectives, but Balanced Scorecards aren’t required for defining project objectives.




Step Two: Perform an Initial Analysis.

Using the ROI Methodology to define business objectives involves following the V-Model from various ROI Methodology books, including Project Management ROI: A Step-by-Step Guide for Measuring the Impact and ROI for Projects, and Show Me The Money: How to Determine ROI in People, Projects, and Programs by Jack J. Phillips (creator of the ROI methodology), et al. Follow along on the V-Model below as you perform the process laid out in the ROI Methodology. Following this methodology when determining your objectives will ensure you achieve the outcomes you set out to accomplish in the first place. Information about the ROI Methodology has also been gathered from Dr. Jack Phillips and Dr. Patti Phillips’, The Bottom Line on ROI, A One Day Workshop Describing How to Calculate the ROI in Government Training Programs.

The Alignment Process

V ModelStart Here

1 1

2 2

3 3

4 4

5 5

Initial Analysis

Payoff Needs

Business Needs

Performance Needs

Learning Needs

Preference Needs

ROI Objectives

Impact Objectives

Application Objectives

Learning Objectives

Reaction Objectives

End Here

Measurement and

Evaluation

ROI

Impact

Application

Learning

Reaction

Business Alignment

and Forecasting

ProjectThe

ROI Process Model




According to the ROI Institute, the ROI process starts with defining the needs that are to be met by the solution in an initial assessment, beginning with the biggest needs and moving down the left side of the V-Model. Assessing various levels of needs will ensure that your organization fully understands the context of the problem and creates objectives that reflect actual needs.

Listed below are the five levels of needs that should be identified to determine good project objectives:

A. Payoff (ROI) Needs.

The highest level to be evaluated are Payoff Needs, also known as ROI Needs, so that an appropriate solution may be identified first thing and your program/project begins with a clear link to business results. A financial need for a project has to be determined and analyzed to determine if the project is financially worth it. Examine the potential payoff of solving the problem or taking advantage of the opportunity. To begin with, answer the following key questions from The Consultants Guide to Results-Driven Processes by Jack Phillips, et al. for every project:

1. Is this project worth pursuing?

2. Does the project address a critical issue?

3. Is there an opportunity to add value with the project?

4. Is it a feasible project?

5. What is the likelihood of a positive ROI?

If your organization answered yes to the above questions and estimates a positive ROI, continue on to answer the following questions from The Consultants Guide to Results Driven Processes by Jack Phillips, et al., to determine ROI/Payoff Needs:

p� Why is this needed?

p� Who will support the project?

p� Who will not support the project?

p� Are there important intangible benefits?

p� How is the project funded?

p� Is this issue critical?

p� Is it possible to solve the problem?

p� How much is it costing?

p� Can we find a solution?

p� Are there multiple solutions?

p� What happens if we do nothing?

p� How much should the project cost?

p� Is this a strategic issue?

p� Is it feasible to improve?




Next, determine the project’s potential payoff. The payoff will depend on two factors: the monetary value derived from the business measure’s improvement and the approximate cost of the project. Generally, the payoff is either in profit increases or in cost savings.

After identifying ROI Needs, additional analysis may be necessary to justify moving forward, or it could be decided that the project is not necessary.

B. Business Needs.

Ensure that the project is connected to one or more business measures so that the business situation can be clearly assessed. Define the measures that must improve as a reflection of the overall success of the project. Business needs often refer to gains in productivity, output, quality, efficiency, time, and cost. This type of need can always be defined with a business measure, and should be supported by hard data when possible.

Hard Data vs. Soft Data

Examples of hard data include revenue, productivity, profitability, cost control, and quality assurance because they are factual measures of improvement, that can easily be measured, quantified, and converted into monetary values. Below are a few examples of hard data that business needs may gather in relation to gains in output, time, costs, and quality:

OUTPUT

p� Sales

p� Items Sold

p� Productivity

p� Shipments

p� Money Collected

TIME

p� Cycle Time

p� Overtime

p� Processing Time

p� Efficiency

p� Average Time Delay

COSTS

p� Unit Costs

p� Variable Costs

p� Fixed Costs

p� Budget Variances

p� Cost by Account

QUALITY

p� Waste

p� Error Rates

p� Failure Rates

p� Dropout Rates

p� Rejects




Soft data is harder to collect and analyze than hard data, because it is often subjective and behavior-oriented—think of measuring things like attitude or satisfaction. Below are a few examples of soft data arranged by category:

WORK CLIMATE/SATISFACTION

p� Complaints

p� Stress

p� Teamwork

p� Job Satisfaction

p� Employee Engagement

INITIATIVE/INNOVATION

p� Creativity

p� Suggestions

p� Patents

p� Partnerships

p� New Services

CUSTOMER SERVICE

p� Customer Complaints

p� Customer Satisfaction

p� Customer Loyalty

p� Customer Value

EMPLOYEE DEVELOPMENT/ADVANCEMENT

p� Promotions

p� Readiness

p� Capability

p� Performance Appraisal Ratings

IMAGE

p� Reputation

p� Brand Awareness

p� Diversity

p� Social Responsibility




C. Performance Needs.

Examine the job performance needs and answer the question, “What must change on the job to influence the business measures previously defined?” Doing this will help to align the project with the business. Although these needs are often neglected, they are often critical in providing a link to the project solution. Performance needs can vary considerably and may include ineffective behavior, a dysfunctional work climate, inadequate systems, a disconnected process flow, improper procedures, a non-supportive culture, outdated technology, and/or a non-accommodating environment.

D. Learning Needs.

Next, assess the learning needs to define what users must know to make the project successful. All solutions have a learning component. Ask the question, “What specific skills, knowledge, or perceptions must change or improve so that job performance can change?” Users may need to learn how to perform a task differently or how to use a new process or system. The learning components can range from developing competencies and capabilities to understanding a new policy or procedure. One of the most useful ways to determine the project’s learning needs is to ask stakeholders who understand the process best.

E. Preference Needs.

Lastly, identify the structure of the solution. Often, projects fail to reach their full potential because of misunderstandings and differences in expectations surrounding the project. Each stakeholder preference in the structure of the solution corresponds to a Level 1 objective, ensuring the project structure and solution will relate directly to the reaction objectives and the initial reaction to the solution. Determining preference needs will drive the project requirements and define how the project will be implemented.

Step Three: Develop Objectives.

Next, move up the right side of the ROI Institute’s V-Model to define specific project objectives that directly correlate to the needs defined in Step Two. Regardless of the size of the project or style of development, we strongly suggest you define all five levels of objectives before moving forward in project planning. The Consultants Guide to Results-Driven Business Proposals by Jack Phillips, et al. states, “For a project to add value and result in a positive ROI, a multilevel chain of impact must occur.” This chain of impact will occur after all project objectives have been defined and will begin as your organization moves up the right side of the V-Model with the goal of meeting the objectives that have been set.




Phillips explains that after stakeholders have become involved with a project, participants who react to it in the desired way may see value in the project (therefore meeting the reaction objectives). Next, stakeholders will learn how to make the project successful (hopefully accomplishing the learning objectives), and then apply or utilize the new project tools, procedures and processes (fulfilling the application objectives). The result of the project will be business impacts (fulfilling impact objectives), and at the conclusion of a project the ROI may be calculated to test the ROI objective.

As your organization composes their project objectives, remember that objectives are supposed to display an acceptable level of value to stakeholders. The goal of project objectives is to provide direction to stakeholders about which way the project is going and what the project will accomplish. In addition, business objectives are meant to excite stakeholder and executive—so keep the objectives themselves fairly high-level, and more details (such as the objective’s measure, expected outcome and timeframe, and data collection method and frequency) will be added on later.

Conditions and Criteria

An objective’s conditions and criteria ensure that objectives are clearly understood by ALL stakeholders and participants. Objective conditions detail the parameters under which a person is expected to perform or achieve the stated objective. For example, take the objective, “Business analysts will construct a business process model.” This objective could be made clearer by adding the condition that a specific business process methodology must be followed. With the new condition, the objective could be revised to read, “Business analysts will construct a business process model using BPMN.” For help, remember that conditions often point out the “when, where, and how” of an objective.

Objective criteria define the level of accuracy, quality, precision, or time within which the objective should be carried out. Objective criteria should define specific amounts, and are most often time-based deadlines or define how well something is to be done. For example, let’s take the objective, “Business analysts will construct a business process model using BPMN.” Time Criteria could be added onto this objective to make it even clearer, for instance, “At the end of the conference, business analysts will construct a business process model using BPMN.” An objective’s conditions and criteria may be included in the objective itself or in the objective’s additional details.

Level 1: Reaction Objectives. Reaction objectives ensure stakeholders involved with the project are satisfied and see value immediately, and in the long term. The data for ensuring these objectives are met is collected routinely to make necessary adjustments and keep the project on track. If stakeholders perceive the project as irrelevant or unnecessary, more than likely, it will not succeed in the workplace.




Good reaction objectives identify issues that are important and measureable while being attitude-based, clear, and concise. Good reaction objectives have the ability to predict program success, and will specify that a change in thinking or perception should result from the project/program.

Dr. Jack Phillips and Dr. Patti Phillips recommend asking the following questions in, The Bottom Line on ROI, A One Day Workshop Describing How to Calculate the ROI in Government Training Programs, whenever developing reaction objectives. These questions should help in brainstorming good reaction objectives:

p� How relevant is this program?

p� How important is this program?

p� Are the facilitators effective?

p� How appropriate is this program?

p� Is this new information?

p� Is this program rewarding?

p� Will you implement this program?

p� Will you use the concepts/advice?

p� What would keep you from implementing objectives from this program?

p� Would you recommend the program to others?

Following is an example of a reaction objective:

“One year after implementing Enfocus Solutions’ software and business analysis methodology, business analysts will perceive business analysis as necessary and effective.”

Level 2: Learning Objectives. Learning Objectives ensure that stakeholders learn what they need to know to make the project successful. Define the competency or level of performance necessary to make the solution successful. Learning metrics are essential to measuring learning because they demonstrate what the expected outcomes are for any project/program training or instructions. Participants should be able to look at learning objectives and know not only what they are expected to learn and demonstrate, but also the level or quality of that knowledge as well.

Tip p� Learning objectives SHOULD state what the participant is expected to do upon training.

p� Learning objectives SHOULD NOT state what must be understood or known to complete a task.




Good learning objectives describe behaviors that are observable and measurable, and are best when written to be outcome-based, clear, and concise. Most learning objectives will have three parts:

1. Performance—What participants will be able to accomplish anything with their newly found knowledge, skills, or competencies.

2. Condition—Conditions under which the participant is to perform a learned task.

3. Criteria—The level or degree of proficiency needed to perform the newly learned task.

Three different types of learning objectives are possible—they can address awareness, knowledge, or performance. Learning objectives involving awareness will state a participant’s level of familiarity with terms, processes, or concepts; those involving knowledge will state the necessary general understanding of any new concepts or processes; and, those involving performance will state what skill learners are expected to demonstrate.

Following is an example of a learning objective:

“After one year of implementing Enfocus Solution’s software and business analysis methodology, business analysts will be able to identify all key project stakeholders.”

Level 3: Application Objectives. Application objectives focus on activities or actions, not the ability to act (Level 2) or the consequences of acting (Level 4). Define what is expected of the project in terms of performance. Application objectives should provide specific milestones that indicate when certain parts of the process have been implemented, place an emphasis on applying what was learned, and describe how things should be in the workplace once the project solution is implemented.

Tip Level 3 and Level 4 Objectives Provide...p� Direction to designers and developersp� Guidance to instructors and facilitatorsp� Goals for participationp� Satisfaction for program sponsorsp� A framework for evaluators

(from The Bottom Line on ROI...)




Good application objectives are observable and measurable, and are best when written to be outcome-based, clear, and concise. Application objectives will describe what the participant will or has changed as a result of the project/program and may have three components:

1. Performance—What the participant will accomplish by an agreed-upon follow-up time.

2. Condition—Conditions under which the participant is to perform a task.

3. Criteria—The level or degree of proficiency under which the task must be performed.

Application objectives may either be knowledge-based or behavior-based. Knowledge-based application objectives will state how the participant is to use concepts, processes, etc., and behavior-based application objectives will state a demonstrable skill. Dr. Jack Phillips and Dr. Patti Phillips recommend asking the following questions in The Bottom Line on ROI, A One Day Workshop Describing How to Calculate the ROI in Government Training Programs whenever developing application objectives. These questions should help in brainstorming good application objectives:

p� What new or improved knowledge will be applied on the job?

p� What is the frequency of skill application?

p� What new tasks will be performed?

p� What new steps will be implemented?

p� What new action items will be implemented?

p� What new procedures will be implemented or changed?

p� What new guidelines will be implemented of changed?

p� What new processes will be implemented or changed?

Application objectives will answer the question, “After the project/program is complete, what will participants be able to do?”

Following is an example of an application objective:

“Six months after implementing Enfocus Solution’s software and business analysis methodology, business analysts will have all project requirements input into RequirementPro™.”




Level 4: Impact Objectives. The goal of impact objectives is to indicate key business measures that should improve. Impact objectives define the ultimate expected outcomes from the project, making them critical to measuring business performance. Top executives rate this as their number one most-used measure. Consider the impact objectives to be what initially drives the project because they reflect what the sponsor wants to see changed or improved. One easy way of determining impact objectives is to use the organization’s Balanced Scorecard or that of the business unit at hand, but a Balanced Scorecard isn’t mandatory for creating impact objectives that achieve bottom line results.

Impact objectives must contain easily collectable measures that are linked to skills and knowledge learned and implemented through the project, and should specify what the participant has achieved. Good impact objectives are results-based, written to be as clear and concise as possible, and may contain hard or soft data. Impact objectives containing hard data will be output-focused, quality-focused, cost-focused, and time-focused. Common types of impact objectives containing soft data will be customer service-focused, work climate-focused, and job satisfaction-focused.

Impact objectives will answer the question, “ After participants have applied any new knowledge and skills necessary for the project, what will their performance impact?”

Following is an example of an impact objective:

“After one year of implementing Enfocus Solution’s software and business analysis methodology, cycle times will have improved by 20%.”

Level 5: ROI Objectives. Determine the acceptable return on investment (ROI). The ROI is most often determined or approved by the project sponsor or other executives. Although exact ROI will not be calculated until business impact data has been collected, the estimated ROI should be determined in the early stages of the project. To define the expected payoff from investing in the project, calculate the impact objectives’ monetary value and compare that with the projects’ estimated costs (how to determine a business objective’s monetary value is covered in step eight). When estimating costs, remember to include all costs from the planning stages to post-implementation.

Intangible Benefits. In addition to the five levels of measurable business objectives, some benefits are so subjective it is not possible to accurately attribute monetary value to them—these are the intangible benefits that should also be identified along with the five levels. Intangible benefits can include things like:

p� Increased employee engagement

p� Increased brand awareness

p� Improved networking

p� Improved teamwork

p� Improved customer service

p� Fewer complaints

p� Reduced conflict



Step Four: Develop Objective Details.

For each project objective, remember that the objective itself is supposed to be an acceptable level of value for whatever the objective specifies—value from the point of view of a stakeholder. What Jack Phillips refers to as “forecasts” are meant to define and estimate (whenever possible) what each objective’s quantitative value will be by defining Measures, Data Collection Methods and Frequency, Expected Outcome and Timeframe, and Accountable Individuals.

Forecasts should also include conditions and criteria for achieving the stated objectives. Conditions are situations under which the participant will complete the task, procedure, or action, and criteria are the specified levels of quality, accuracy, or time within the objective that will be carried out. Sometimes conditions and criteria are included in the project objective, but they don’t have to be. For example, a condition of a learning objective could be that it must be accomplished using the provided training materials, and a criterion could be that the objective must be met within the year.

At this point in time, document your business objectives and their details (forecasts) into RequirementPro™. The following fields will be explained in more detail, but each field should be entered into RequirementPro™ for each business objective:

p� Name (business objective name)

p� Type

p� Description

p� Measure


p� Data Collection Method and Frequency

p� Baseline

p� Expected Outcome and Timeframe

p� Accountability



The table below should serve as a quick, go-to guide for explaining each objective type/level, and each objective’s measurement focus, typical measures, data collection methods, and data collection frequency.

EVALUATION LEVELS/TYPES OF BUSINESS

OBJECTIVES

MEASUREMENT FOCUS TYPICAL MEASURES DATA COLLECTION

METHODSDATA COLLECTION FREQUENCY

Level 1: Reaction & Perceived Value

The reaction to and perceived value of the project

p� Relevancep� Importancep� Usefulnessp� Appropriatenessp� Intent to use

p� Questionnaires & Surveysp� Interviewsp� Focus Groupsp� Performance Testsp� Technology & Task Simulation

Beginning of project and at routine intervals

Level 2: Learning & Confidence

Learning to use the content and materials, including the confidence to use what was learned

p� Skillsp� Knowledgep� Capacityp� Competenciesp� Confidence

p� Questionnaires & Surveysp� Interviewsp� Focus Groupsp� Performance Testsp� Task Simulation

Beginning of project and at routine intervals

Level 3: Application & Implementation

Use of content and materials in the work environment, including progress with actual items and implementation

p� Extent of usep� Task completionp� Frequency of usep� Actions completedp� Success with usep� Barriers to usep� Enablers to use

p� Questionnairesp� Interviewsp� Focus Groupsp� Observations p� Follow-up Sessions

Post-implementation evaluation

Level 4: Impact & Consequences

The consequences of the use of the content and materials expressed as business impact measures

p� Productivityp� Revenuep� Qualityp� Timep� Efficiencyp� Customer Satisfactionp� Employee Engagement

p� Existing Databasesp� Reportsp� Balanced Scorecardsp� Action Plansp� Performance Contracts

Post-implementation evaluation


Level 5: ROI Comparison of monetary benefits from program to program costs

p� Benefit-Cost Ratio (BCR)p� ROI%p� Payback Period




A. Measures:

Determine the measures that will illustrate the progress of the project’s objectives. An objective’s measures are a good place to fit in conditions and criterion. For example, take the reaction objective, “One year after implementing Enfocus Solutions’ software and business analysis methodology, business analysts will perceive business analysis as necessary and effective.” A good measure for this reaction objective would be, “Business analysts will perceive business analysis to be necessary for effectively completing a project as indicated through surveys by an average of 4.0 out of 5, on a 5 point scale.”

Action Verbs for Defining Learning Objective Measures

Before deciding on how an objective is to be measured, you must decide what is to be measured. Use the following list of verbs from The Consultant’s Guide to Process-Driven Proposals by Jack Philips, et al. to help in defining learning objective measures that are performance based:

p� Name

p� Write

p� Prepare

p� Describe

p� Recite

p� Reboot

p� Differentiate

p� Identify

p� Load

p� Explain

p� Search

p� Sort

p� Locate

p� Stop

p� Solve

p� Calculate

p� Eliminate

p� Construct

p� Complete

p� Start up

p� List

p� Compare

p� Recall

p� Contrast

p� Determine




Key Words for Defining Reaction Objective Measures

Reaction objectives are best measured whenever the measures are written using key words that reflect stakeholder reactions. Use the following list of key words from The Consultant’s Guide to Process Driven Proposals by Jack Philips, et al. to help in defining reaction objective measures:

p� Perceive

p� Feel

p� React

p� Rate

p� Envision

p� Interpret

p� View

p� Deduce

p� Deem

Action Verbs for Defining Application Objective Measures

Application objectives are best whenever they identify specific behaviors, tasks, and actions that are observable, measurable, and outcome-based. For this reason, application objectives should be fairly easy to measure, given the right wording. Use the following list of verbs and their explanation from The Consultant’s Guide to Process Driven Proposals by Jack Philips, et al. to help define application objective measures:

p� Increase: Increase a particular activity or action.

p� Decrease: Decrease a particular activity of action.

p� Eliminate: Stop or remove a particular task or activity.

p� Maintain: Keep the same level of activity or a particular process.

p� Create: Design, build, or implement a new procedure, process, or activity.

p� Use: Use a particular activity or process.

p� Perform: Conduct or do a particular task.

p� Participate: Become involved in various activities, projects, or programs.

p� Enroll: Sign up for a particular program, process, or project.

p� Respond: React to group individuals, or systems.

p� Network: Facilitate relationships with others who are involved or have been affected by the program.

p� Grade

p� Regard

p� Think

p� Consider

p� Inclination

p� Stance

p� Opinion

p� Attitude

p� Impression



Various Impact Objective Measures

Impact objectives can be measured using data that is easily collected and non-disputable, or measured using data that is more objective, like data collected about job satisfaction or loyalty. Impact objective measures will vary drastically depending on the type of project and its expected impact. The following list is condensed from The Consultant’s Guide to Process Driven Proposals by Jack Philips, et al., and consists of different types of projects and the various key impact objective measures for each.

PROJECT TYPE KEY IMPACT MEASUREMENTS

Business Coaching Costs, customer satisfaction, efficiency, employee satisfaction, productivity/output, quality, time savings

Sales Meetings Customer loyalty, market share, new accounts, sales

Marketing Products Brand awareness, churn rate, cross-selling, customer loyalty, customer satisfaction, market share, new accounts, sales, up-selling

Onboarding Early turnover, performance, productivity, quality of work, training time

Software Projects Absenteeism, costs, customer service, job satisfaction, productivity, quality, sales, time, turnover

Career Development Job satisfaction, promotions, recruiting expenses, turnover

Safety Programs Accident frequency rates, accident severity rates, first aid treatments




To ensure your measures are effective once they have been determined, refer to the following checklist created by the ROI Institute

✓

Important: connects to strategic business objectives.

Complete: adequately tracks the entire phenomenon.

Timely: tracks the correct period of time.

Visible: public and openly known.

Controllable: tracked by someone who has a clear view from the measures to results.

Cost-effective: efficient to track

Interpretable: easy to make sense of.

Simple: easy to understand from any stakeholder perspective

Specific: clearly defined.

Collectible: can be collected with sufficient amount of effort.

Team-based: finds value in the judgment of a team, not an individual.

Credible: valid in the eyes of management.





B. Data Collection Method(s) and Frequency:

Specify the schedule for collecting data and the methods of collecting the data. The methods for collecting data will vary according to the level of objective. The data for each objective is collected at various points in the project lifecycle. For example, the early stages of the project are a critical time when you should be capturing reaction and learning data to ensure you are achieving those objectives. Although often neglected, this feedback validates the decision to continue the project. Routine collection confirms that the project aligns with the business need.

To determine the appropriate methods for data collection, consider the following:

p� What is the type of data? For example, surveys, observations, interviews, and focus groups are most often best suited for application objective data.

p� How much of the participants’ time must be spent? Ensure time requirements are as minimal as possible, and that participants understand the value in the data collection.

p� How much of the manager’s time must be spent?

p� What is the cost of this specific method?

p� How much will the data collection disrupt normal work activities?

p� How accurate is this data collection method?

p� If you’re using more than one data collection method, is each additional one worth extra time and effort?

p� Are there any cultural bias surrounding data collection methods?

Whenever possible, the business analysts at Enfocus Solutions recommend gathering objective data with an online survey tool. To determine the prevalence of an attitude, opinion, knowledge, confidence, or behavior, ask questions that use a rating scale. Employing the use of rating scales within online surveys to measure objectives will improve the speed it takes to create surveys, distribute surveys, and then gather and analyze response data.

C. The Expected Outcome of the Objective and its Timeframe:

Describe what achieving this objective will do for the organization. Also, specify when the organization will start seeing the benefits. For the reaction objective, “One year after implementing Enfocus Solutions’ software and business analysis methodology, business analysts will perceive business analysis as necessary and effective.” The measure is that, “Business analysts will perceive business analysis to be necessary for completing a successful project effectively as indicated by an average of 4.0 out of 5 on a 5 point scale.” While the expected outcome and timeframe would be, “Within one year, business analysts will perceive business analysis as necessary and effective by an average of 4 out of 5 on a 5 point scale.”




D. The Accountable Individuals:

Accountability should be addressed when planning the project’s objectives to ensure there is no misunderstanding of responsibility. Many possibilities exist as to the accountable parties, such as project contributors, the project sponsor, or even independent consultants. Determine who will be accountable for collecting measurements, as well as performing the actual improvements. Everyone in the project should have a responsibility related to data collection.

SMART OBJECTIVES

After defining business objectives according to the 5 levels of evaluation and then defining measures, data collection methods, expected outcome/ time frame, and accountable individuals for each objective, ensure that each objective is SMART. SMART business objectives are a common best practice in business analysis. A few variations of the acronym exist, but Enfocus Solutions refers to SMART objectives as Specific, Measurable, Achievable, Relevant, and Time-bounded.

p� Specific: Ensure the objective provides a detailed description of something that has an observable outcome. When writing an objective, state exactly what is to be achieved. Stay away from vague descriptions like, “Will facilitate training,” and, instead, use more concrete details. For example, “Create a web-based training site.”

p� Measurable: Ensure the desired outcome is traceable and measurable. An objective statement should answer the question, “How will I know when an objective is accomplished?”

p� Achievable: Ensure the necessary work is practical and attainable. The objective must be within the organization’s control and feasibly achieved using current resources.

p� Relevant: Ensure the objective aligns with the organization’s key vision and goals. Before moving forward with the project, the business analyst must ensure the organization will benefit from the solution.

p� Time-bounded: Ensure there is a realistic timeline for the project’s goals and required action items that is consistent with the objectives. Create a comprehensive schedule for all of your activities to ensure your objectives are met in a timely manner.

Step Five: Document Baseline.

Develop evaluation plans and document the current baseline measurement. This baseline will be used for comparison throughout the project lifecycle to determine the progress of improvement.



Step Six: Collect Data.

Collect data during solution implementation (Level 1&2), and collect data after solution implementation (Level 3&4).

Step Seven: Isolate the Effects of the Solution.

Isolating the effects of a project is necessary for figuring out how much improvement has resulted from the solution, and how much improvement resulted from outside influences. Unless all factors potentially impacting a project are identified, reported objective results will lack credibility. There are almost always multiple factors contributing to a measurable project outcome, so if a project’s effects are not isolated, no link between project outcomes can be clearly established. Identify all key factors that might contribute to measurable improvement related to the project. This acknowledges that credit for a project’s success doesn’t rest solely with the project.

The following list from Dr. Jack Phillips and Dr. Patti Phillips’ book, The Bottom Line on ROI, A One Day Workshop Describing How to Calculate the ROI in Government Training Programs, offers some methods for isolating a project’s effects. However, the method for isolating a solution’s effects will vary from objective to objective, depending on the objective’s measurement:

p� Use of a control group arrangement

p� Trend line analysis of performance data

p� Use of forecasting methods of performance data

p� Participant’s estimate of program impact (percentage)

p� Supervisor’s estimate of program impact (percentage)

p� Manager’s estimate of program impact

p� Use of expert/previous studies

p� Calculate/estimate the impact of other factors

p� Customer input




Step Eight: Convert Data Measures into Monetary Values.

For many stakeholders, the most important value is money and it is often the easiest to understand. Before you can calculate the project’s estimated return on investment (ROI) by comparing its monetary value with its costs, you must convert the impact objective data that you collected to monetary value. Often, similar measures have been used before in the organization and already have standard monetary values assigned to them. However, sometimes you must assign value to a new measure:

1. Focus on a single unit of measure. For example:

p� One reworked item

p� One hour of cycle time

p� One customer complaint

p� One patient served

p� One hour of downtime

2. Determine the cost value (V) of the unit. If it is not a common unit of measure for which there is no standard value available, refer to reports or other resources that may help pinpoint the cost of one unit.

3. Calculate the change (change thingy) in performance data. This change is directly attributable to the project.

4. Determine the annual amount of performance data change (change thingy P). Annualizing the change value develops a value for the total change in the performance data for one year.

5. Calculate the annual value of the improvement. To do this, multiply the annual performance change by the unit value for the complete group in question. The total value will include the total improvement for all participants providing data.

∆P x V

Step Nine: Calculate ROI.

Once you have determined the monetary value of the measurements, you can compare the annual project benefits with the cost of the project to calculate the ROI. The final ROI percentage is calculated as the annual monetary benefits minus cost, divided by the actual cost, and multiplied by 100.

ROI = Net Project Benefits x 100Project Costs




CollaborationRemember that it is the project team’s responsibility to continuously communicate results throughout the project lifecycle. Providing well-defined objectives for each level to stakeholders will help justify the project, gain support, and build goodwill. Communicating the objectives and their results is critical to project success. As mentioned in previous chapters, we suggest setting up a focus group or workshop to collaboratively discuss the deliverables related to the Situation Analysis task group. In this workshop, stakeholders review the developed objectives and provide input on completing the records in RequirementPro™.

Remember that communication can always be a politically sensitive issue within the organization. Ensure information is delivered to everyone who should receive it, as well that the same information is consistently distributed to everyone. At the same time, remember that communication should be be tailored for and targeted to a specific audience to address their interests, needs, and expectations.

Reasons for communicating business objectives:

p� Seeking approval for the project

p� Gaining support for the project

p� Securing agreement on the solution

p� Motivating participants to become involved in the project

As you collect data, you may find areas in need of improvement. This is often viewed as “bad news,” but it doesn’t have to be. When communicating bad news during the project, remember the following:

p� Recognize the power to learn from errors and improve as a team.

p� Remain objective.

p� Find out what went wrong and let people know.

p� Always try to drive improvement.

p� Put a positive spin on it: “Now we have data that show how to make this project more successful.”




Related Technique: Objective ChainWhen projects start to become unwieldy in size, a common practice is to narrow the scope of the project to something that is more manageable. A good way of determining what should be in and out of scope is to calculate the value of each objective by determining the value of the related features. This is usually done once the process of defining features has begun. The Objective Chain is a useful tool for examining the value of an objective’s related features, even if it consists of features that are far removed. This document provides an overview of the Objective Chain visualization technique; for more information on how to use the Objective Chain, see Visual Models for Software Requirements by Joy Beatty and Anthony Chen.

Objective Chains should be primarily created by the business analyst, but they require the input of the team to explain how features contribute to objectives. When first creating the chain in a group setting, use sticky notes and a whiteboard to document everything. Then, once everyone reaches agreement, document the chain using a visualization software tool, like Creately. In the Objective Chain hierarchical diagram, the business objective is placed in the top left and the features are placed in the lower right. The branches that connect the two elements contain objective factors and objective equations.

p� Objective Factor: qualitative statement about how one level in the hierarchy contributes to the level above it. For example, “Increasing the number of sales representatives who have passed tests increases sales.”

p� Objective Equation: captures the quantitative values of the relationship between objective factors. For example, “Increased revenue = 200 x (number of passed tests after change) —(number of passed tests before).”

Before you can perform this technique, you should have at least a basic understanding of the features related to the project. Then, follow these steps to create the Objective Chain:

1. Place the objective at the top of the tree.

2. Chain the objective factors of the business objective and link the business objective to the first feature, which should be added to the end of the chain, like in the example on the next page.

3. Examine the second feature and the factors that link it to the objective. Complete the chain for the second feature.




Increased Revenue

Increasing no. of sales reps. who have passed tests increases sales

Increased revenue = 200 x (no. of passed tests after change - no. of

passed tests before)

Taking training before tests increases number of passed tests

Total passed tests = 90% x (no. of reps. who take training) + 25% x (no.

of reps who do not)

Providing training options outside the classroom increases training participation

Increased number of reps. taking training = (% increase in training participation) x (total no. of reps)

Increasing no. of sales reps. who have passed tests increases sales

Increased revenue = 200 x (no. of passed tests after change - no. of

passed tests before)

Providing offline training increases the number of representatives taking training

Percentage increase in training participation = 20%

Online Training

Example of an Objective Chain

Taken from Visual Models for Software Requirements by Joy Beatty and Anthony Chen.




Comprehension Exercise Determine how to improve each of the poorly written business objectives below and re-write the statement in the space provided. Remember to always ensure your business objectives adhere to the acronym SMART. After you complete the exercise, compare the objectives you wrote to the ones we developed on the next page.

1. Decrease client wait time.

2. Increase revenue from the restaurant.

3. Reduce the time it takes to search the online store for a product.

4. Reduce quality complaints and claims.

5. Ensure compliance with new medicare claim regulations.




Comprehension exercise Answers

1. Decrease client wait time to be seen by a physician from 2 hours to 20 minutes by January 2014.

2. Increase revenue by 25% each month by catering 2 parties a month.

3. By December 2013, reduce the time it takes to search the online store for a product by 40%.

4. This one can be separated into two objectives. 1) Reduce the number of customer quality complaints by 25%. 2) Reduce claims paid for quality problems by 75% by December 2014.

5. Ensure compliance with new Medicare claim regulations when they go into effect on August 9, 2013.




SMART Objectives WorksheetDeveloped at Wayne State University, the following worksheet will guide you in building SMART business objectives. Answer the following questions and then synthesize the information to develop individual business objectives:

Specific

What will you achieve?

How will you know when it is done?

Measurable

If applicable, what are the quantity expectations?

If applicable, what are the quality expectations?

If applicable, what are the frequency expectations?

If applicable, what are the cost expectations?




Achievable

What are the knowledge, skills, abilities, and experience needed to achieve the objective?

Are there available resources to achieve the objective? If so, what are they?

Are there any time factors or environmental constraints that need to be considered?

Relevant

Which of the organizations’ strategic priorities does it relate to?

Which strategic objective on the Balanced Scorecard does it support?

Why are you doing this?

Time-oriented

When does it need to be completed?




Task Completion Checklist After developing the project’s business objectives, ensure the project contributors have reviewed the objectives according to the following criteria:

DEFINED ALL FIVE TYPES OF OBJECTIVES ✓

Reaction Objectives defined.

Learning Objectives defined.

Application Objectives defined.

Impact Objectives defined.

ROI Objectives defined.

REVIEWED ALL OBJECTIVES ✓

All objectives are specific.

All objectives are measurable.

All objectives are achievable.

All objectives are relevant.

All objectives are time-oriented.

Type of measurement is documented.

Method of data collection is documented.

Frequency of data collection is documented.

Baseline measurement is documented.

Expected outcome of completing the objective is documented.

Timeframe in which the objective must be completed is documented.

All responsibilities for achieving the objective are documented.




IntroductionOnce the project vision has been determined, it’s time to start thinking about the changes that are required to provide that vision. The well-documented business objectives from the previous task help to paint a rough picture of the solution so that the BA can perform a preliminary assessment of the organizational context surrounding the solution before performing a more formal impact analysis in the next task group, 3.0 Solution Conceptualization. The information from this task will be used to guide the BA through the next two tasks of this task group, as well as the majority of Solution Conceptualization.

Documenting and assessing the organizational context of the project will help the project team begin to set the scope, determine who the stakeholders are, and determine any other impacts that the solution has. Later, you will document the scope with solution features after you conduct formal stakeholder and impact analysis to get an understanding of stakeholder needs.

As you assess the organizational context, remember that it is not necessarily static, meaning it may be constantly changing. For example, the current season could have an effect on certain types of product releases. This is one reason it is important to assess the organizational context for each project individually. Another reason is that each individual project will have different goals and different services, stakeholders, and processes involved—meaning they have different organizational contexts.

Assessing the organizational context for each individual project will make it easier when it comes time to:

p� Determine Business Objectives

p� Determine Capability Gaps

p� Determine Constraints, Assumptions, & Risks

p� Perform Impact Analysis

Chapter Four: Assess Organizational Context

Assess Organizational Context

2.4 Chapter Four



Core Concepts

Organizational Context

According to IIBA, the “context” is the part of the environment which encompasses the change; it must be noted that the context is distinct from the controlled organizational change. The context is everything relevant to the change, but the change itself. Examples of the organizational context can include, but are not limited to:

p� Attitudes

p� Behaviors

p� Beliefs

p� Competitors

p� Culture

p� Demographics

p� Goals

p� Governments

p� Infrastructure

Benefits of Organizational Context Assessment

Assessing the organizational context is the first step to performing impact analysis, which is a structured approach to looking at a proposed change, so that you can identify as many of the impacts or consequences of the change as possible. Impact analysis is important for evaluating whether you want to invest in a project. In addition to helping set scope, it also helps the project team prepare for and manage any issues that may arise.

Assessing the organizational context is a prerequisite task to determining capability gaps and identifying specific impacts. The organizational context of a solution will determine how readily new systems or processes can be adopted, and, more importantly, whether the solution can be achieved at all. Also, in performing this task, you are controlling the scope of the context. In the subsequent tasks, you’ll take that information and develop the finite scope of the solution. Remember that the two concepts (organizational context and solution scope) are separate.




ProcessThe following steps do not have to be performed in order. A lot of this information will come from the project sponsor. See Questions to Ask the Project Sponsor on page 66 for more sample interview questions. Once all aspects of the organizational context have been assessed, summarize your findings and enter them into RequirementPro™ for the whole project team to review.

1. Determine the locus of the problem. The organizational context may be either internal or external. An internal organizational context only includes individuals or business units within the organization. An external organizational context includes entities that reside outside of the organization, in addition to internal impacts.

If the problem appears to impact only the organization, meaning it is an internal organizational context, does it impact...

p� The entire organization?p� A single business unit or department?p� A single workgroup or team within a department?p� One or two specific individuals? p� If the problem appears to impact stakeholders, processes, and technology outside

of the organization, does it impact...p� Customers?p� Suppliers?

p� Alliance Partners?

2. Determine the project perspective. The perspective is a particular way of regarding the project. Knowing the perspective of the project is important when you’re beginning to determine what areas of the business are impacted by the project. Is the perspective...

p� Strategic? Meaning, does it focus on long-term goals within the organization?

p� Tactical? Meaning, does it focus on the business functions within the organization?

p� Operational? Meaning, does it focus on the users’ tasks within the organization?

3. Describe the organization’s operating characteristics. Mapping out operating characteristics will help to determine what areas of the business are impacted. If creating an organizational context assessment report, a business model and any other business process models should be attached. This step includes multiple activities:

p� Document the business model (if one hasn’t already been created). The business model should describe how the organization creates, delivers, and captures value.

p� Document business functions. The business functions are fundamental activities of a business unit, including a group of activities designed to accomplish specific goals.

p� Document business processes. A business process is a set of defined ad-hoc or sequenced collaborative activities performed in a repeatable fashion by an organization.




4. Describe the geographic locations involved with the project. Geographic locations may conflict. If stakeholders operate in different parts of the globe or country, that may have an impact on how the solution gets developed. What is the location of...

p� Relevant stakeholders?

p� The development team?

p� The project sponsors?

5. Determine the primary type of problem. Classifying the problem helps determine what areas of the business the solution will focus on. Is the problem...

p� Systems-related?

p� Process-related?

p� Related to communications people?

p� Product-related?

6. Determine the urgency of the problem. This will have an effect on the project’s scheduling of events, as well as other planning activities. The main question that needs to be answered at this step is “How critical is the resolution of this problem?” Is resolution...

p� Critical?

p� Mission Critical (requires immediate attention)?

p� Mission Critical (important, but can be scheduled)?

p� Non-mission Critical?

Mission critical means that any failures that occur will result in the failure of business operations (in other words, it is critical to the organization’s mission).

7. Classify the project in one of three ways:

p� Market-driven: producing a new product in response to market needs. For example, a software company sells products and maintains market share by creating programs that meet consumer needs.

p� Crisis-driven: quickly solving a specific problem. For instance, in response to a serious product defect, an automobile manufacturer may quickly organize a project to manage their recall and replacement and create a public relations campaign to address the issue.

p� Change-driven: changing operations to match the current environment or to be more effective. For example, projects may be driven by regulatory needs, defined by maintenance requirements, research-driven to explore a problem or opportunity, or driven to maintain market share.




8. Assess the degree of cultural shift.

The culture of the organization refers to the codes of conduct, values, beliefs, and actions that are shared by the people working in the organization. Before you can determine whether to invest in the project, you need to have an understanding of how much it will affect the culture of the organization. If the project implies a significant degree of cultural shift, you will need to assess whether it is worth the work it takes to change the way people work together. Talk to the project sponsor about how much change it will take to shift the organization’s culture according to the project vision.

9. Assess the amount of anticipated change. Now, you need to assess the amount of anticipated change in the organization’s business processes and procedures. In addition to contributing to the decision whether to invest in the project, this information will have an effect on scheduling of business analysis and project activities. If there is a significant amount of change to implement, you need to schedule enough time for people to perform tasks.

p� Significant (complete paradigm shift)

p� Major

p� Minor

10. Assess stakeholder types. You’ll need to know this information when you perform Task 3.2 Conduct Stakeholder Analysis. Figuring out your stakeholder types as a part of the organizational context will facilitate the process of gathering stakeholder information.

p� What are their locations?

p� How many relevant stakeholders are there?

p� What are the different types of stakeholders?

Once you have assessed the organizational context, you need to share that information with the rest of the project contributors and relevant stakeholders. The easiest way to do this is with RequirementPro™. Once you enter the information, notify other project participants that it is available for review by publishing a project announcement on the Project Dashboard.




CollaborationPerforming the assessment of the project’s organizational context cannot be done without the help of the project’s relevant stakeholders. Stakeholders need to be involved in the process of discovery that is context assessment. The BA should perform an initial assessment of the project’s context and then present that assessment to project contributors and relevant stakeholders via RequirementPro™. Let everyone know that it is available for review by posting an announcement on the Project Dashboard, and ask them to post any comments or questions they may have. Use those comments and questions to spark a discussion in a group setting about the organizational context.

Talk to stakeholders to make sure you are not missing anything, and that you do not have any wrong information. As mentioned in the previous two reference guides, we suggest setting up one workshop to discuss the tasks related to Situation Analysis. In this workshop, use one of the visualization techniques listed in the next section of this chapter to discuss the context surrounding the project.





Context Diagram

The project team must find a way to graphically represent the context of the project, including technology, the organization itself, groups being impacted, and the nature of the changes the project will bring to bear. The idea is to provide an easy way of portraying the context into which the project will place its business solution. The process laid out in this workbook for defining the organizational context includes a lot of information that you need to cover. We suggest performing the ten steps of the process in a group setting with collaborative discussion. Good practice is to use a context diagram like the example below to document the findings of the discussion.

Context of <Project Name>

Customers & Agency Groups Involved

p�

p�

p�

p�

BusinessProcess

p�

p�

p�

p�

Key Inputs

p�

p�

p�

p�

Key Systems Used by the Processes Currently

p�

p�

p�

p�

Key Systems Impacted or to be in Place with Project

p�

p�

p�

p�

Key Outputs

p�

p�

p�

p�

ImpactedPopulations

p�

p�

p�

p�

RevisedProcess

p�

p�

p�

p�

Purpose of Project:

Summary of Current Situation:

Summary of End of Project:




Organizational Modeling

Organizational Modeling is a useful technique for assessing the organizational context of a project. It is especially useful in projects that cross a lot of boundaries, different divisions, departments, and managers. Organizational modeling is a great starting place for determining what parts of the organization are impacted by the project. While it is a great tool for assessing the context, it will also prove useful later when you need to conduct an in-depth stakeholder analysis.

The output of organizational modeling is an organization chart, which is a chart displaying the lines of responsibility between departments within the organization. An organization chart will help you to understand the perspectives and interests of the people involved. Also known as an organizational structure, an organization chart defines an organization through its framework, including lines of authority, communications, duties, and resource allocations. An organization chart can be considered as the viewing glass or perspective through which individuals see their organization and its environment.

Organization Chart

Quality ControllerLeader(Name)

Quality Controller

Product Manager(Name)

ProductionSupervisor

(Name)

ProductionOperator

Store Leader(Name)

StoreController

Chemical Engineer(Name)

Managing Director/Sales Director(Name)

Sales Executive(Name)




Questions to Ask the Project SponsorYou will probably have many sources of information as you gather stakeholder knowledge about the context surrounding the project. The best source of information available to you is the project sponsor. In the beginning stages of the project, the sponsor will have the most knowledge of every detail related to the project. Interviewing the project sponsor is a great place to start assessing the organizational context so that, later, you can more easily and accurately define the solution scope. Use the sample questions below to develop an initial set of questions to ask the project sponsor.

p� How does the project fit in with the organization’s overall business strategy? p� Who will you be going to for approvals and funding?p� How does the problem manifest itself in the organization? p� Who is affected? How? Why? p� What can you do about it? What have you done to date? p� What has not been done about it? p� What does the future of this problem look like if nothing is done? p� What’s driving us to do this now? What if we did nothing? What if we waited until next year?p� How does this fit into the overall priority of projects?p� For whose benefit is the project being undertaken?p� What customer group or department is the project intended to impact?p� What customer groups or departments are indirectly impacted?p� Where are the impacted customer groups or departments located?p� Who is likely to feel threatened by this project or have strong opinions against it?p� Who do we need to talk to that has to be happy with the results?p� Who are the strong supporters of this project? p� What would you expect to spend on this project?p� Whose budget is this coming out of?p� Who will I talk to about getting staff for the project? p� How are expectations set? Who sets them? p� Are there pre-assumptions about the solution? Are customers open to different alternatives? Would they accept suggestions from the project team, or is this a top-driven solution? p� How has the organization handled change in the past?p� Who should be involved in the project? Who should not? p� Is there any tolerance for degradation in service, support, or performance while the project is underway? Is there tolerance for re-prioritizing other project initiatives to give this project priority?p� What kind of changes to the organization’s culture will the project cause? p� How much change is being proposed to the business processes? What changes will need to occur?




Task Completion ChecklistThe organizational context consists of many components. Weigh your assessment against the criteria on this checklist to ensure you’ve covered all areas.

✓

Locus determined as internal or external.

Project perspective determined as strategic, tactical, or operational.

Organization’s operation characteristics described.

Business model documented.

Business functions documented.

Business processes documented.

Geographic locations involved with the project described.

Type of problem determined as systems-related, process-related, communications-related, or product-related.

Project classifed as market-driven, crisis-driven, or change-driven.

Degree of cultural shift assessed.

Amount of change assessed.

Stakeholder types assessed.




Introduction

“The hardest single part of building a system is deciding what to build... No other part of the work so cripples the resulting system if done wrong.

No other part is more difficult to rectify later.” —Fred Brooks, No Silver Bullet, 1987

Although Brooks is correct in his assessment, the question still remains—how do you figure out what you need to build?

After gathering an understanding of the project and the context surrounding it, the business analyst (BA) will begin the path to discovering what needs to be built to achieve the project vision defined in task 2.2. The BA, relevant stakeholders, and project contributors will need to meet to determine whether the organization is poised to achieve the goals laid out in the project vision statement using the existing people, processes, and technology—this is done through a gap analysis. Information gathered in Task 2.3 Define Project Objectives and Task 2.4 Assess Organizational Context will guide your capability gap analysis. To assess current and required capabilities, it is essential that you have already documented and analyzed the organizational context of the project to determine what areas of the organization will need to be changed to deliver a successful solution. It is important objectives are already defined so that the team knows what capabilities it needs to assess.

Chapter Five: Determine Capability Gaps

Determine Capability Gaps

2.5 Chapter Five



Core Concepts

Capabilities

Before we discuss how to determine the gaps in the organization’s capabilities, let’s determine what a capability is. A business capability is an ability or capacity for a company to deliver value, either to customers or stakeholders. Business capabilities are a useful abstraction because they represent the next level of detail beneath the problem statement and vision statement. A capability does not include information about how work is performed. At this level of planning, the project team needs only to specify the what and not the how.

Capability Gaps

When the organization is not capable of achieving desired goals, this is known as a capability gap. A capability gap is the difference between the ability of existing systems to meet operational requirements and expectations. The project team will need to analyze the current capabilities of the existing process as it is carried out with its current outcome and compare the assessment to the desired outcome and the process needed to achieve it. Capability gap analysis helps you to understand how you’re going to get from the problem documented in the problem statement to the vision laid out in the vision statement. Capability gaps are an important part of being able to figure out what the solution will look like. Put very simply, the capability gap analysis will show you where the organization is right now, and where you want it to be in the future.

Assuming the current capabilities insufficiently meet the project objectives, after assessing the capability gaps, the next task will be to determine the solution that will achieve the vision. According to the Business Analysis Body of Knowledge (BABOK), after you determine the required capabilities, you may discover that change is required in any number of the following components to deliver the required solution:

p� Business Processes

p� Functions

p� Lines of Business

p� Organization Structures

p� Staff Competencies

p� Staff Knowledge and Skills

p� Training

p� Facilities

p� Desktop Tools

p� Organization Locations

p� Data and Information

p� Application Systems

p� Technology Infrastructure




According to Glen B. Alleman in Performance Based Management, some examples of capability gaps include things like:

p� We need the capability to pre-process insurance claims at $0.07 per transaction rather than the current $0.11 per transaction.

p� We need the capability to remove 1½ hours from the retail ordering process once the merger is complete.

p� We need the capability to change the Wide Field Camera and the internal nickel hydride batteries, while doing no harm to the telescope.

p� We need the capability to fly 4 astronauts to the International Space Station, dock, stay 6 months, and return safely.

p� We need the capability to control the Hell Fire Missile with a new touch panel while maintaining existing navigation and guidance capabilities in the helicopter.

p� We need the capability to comply with FAR Part 15 using the current ERP system and its supporting work processes.




Process It is the responsibility of the business analyst to assess the current capabilities of the enterprise and identify the gaps that prevent it from meeting business needs and achieving desired outcomes. Project contributors and relevant stakeholders should be involved in gathering the necessary information and assessing the capability gaps. There are three steps to performing this task:

1. Document and assess current capabilities.

First, review and analyze the enterprise architecture, gathering as much information as is available about the current state of the business areas affected by the identified problem. The BA must have a complete understanding of the organization’s business processes and the architecture that supports the business. The main activity performed in this step is capability modeling. If capability models do not already exist, the project team will have to create an “As-Is” model pertaining to the area of the enterprise that is under review. See Visualization and Elaboration on page 74 for an explanation of capability models.

According to BABOK, examples of common capabilities to assess include:

p� Business processes

p� Features of a software application

p� Tasks that an end user may perform

p� Events that a solution must be able to respond to

p� Products that an organization creates

p� Services that an organization delivers

p� Goals that a solution will allow stakeholders to accomplish

2. Determine necessary capabilities.

Once the organization’s current capabilities have been fully described, the project team must contrast the current capabilities with capabilities that are required to carry out the project vision. In this step, the business analyst develops the “To-Be” models. By comparing the current and future states (aka the “As-Is” and “To-Be,” respectively) the business analyst can identify the gaps in organizational capabilities that will need to be addressed to adequately support the project vision. This model will eventually be used to develop solution features.




3. Document the assessment in RequirementPro™.

Once the project team has successfully completed the capability gap assessment, the BA should enter a summary of the gap analysis into RequirementPro™ to allow all project contributors and relevant stakeholders know what gaps in the organization are being addressed by the project.

It is a good practice to document all findings in a Capability Gap Analysis (CGA) document. All of the required information for the CGA will not be available to the project team until other related tasks have been performed, such as 3.2 Conduct Stakeholder Analysis, 3.3 Perform Business Process Analysis, 3.4 Assess IT Service Impact, and 3.5 Assess Enterprise Data Impact. The CGA should generally include the following sections:

p� Project Name and Description

p� IT Service Impact and Gap Analysis

p� Business Process Impact and Gap Analysis

p� Organizational Skills Impact and Gap Analysis

p� Data Impact and Gap Analysis

When it comes time to gather stakeholder needs, one possible method is to set up scenarios in RequirementPro™ that correspond to the required capabilities. Then, approach the relevant stakeholders for each scenario and ask them to fill in the details or create any scenarios that the project team may have missed.




CollaborationCommunicating the findings of your capability gap assessment to stakeholders can often be a political issue if stakeholders feel that their abilities are being criticized. As the BA, you need to ensure stakeholder socialization is performed carefully and correctly. You don’t want anyone to think that they are lacking in ability, or that the problem lies with one individual. You need to be clear with stakeholders that the problem is with the organization, not their skills.

To ensure this information gets appropriately communicated to the project stakeholders, it is important to provide the findings of the assessment for stakeholder review. The easiest way to do this is with the Project Vision section in RequirementPro™. After you enter the capability gap summary into the application, make sure you announce via project announcement that the information is available for review. Assign action items to specific people whose opinion you really need. Also, encourage stakeholders to comment on the Project Overview if they have anything to say or ask about the capability gap results. Whenever you onboard a new stakeholder to the project, regardless of when they join the project, ensure they review the Project Vision section in StakeholderPortal™, including the capability gaps that are being addressed by the solution.

As mentioned in the previous few chapters, we highly recommend setting up a focus group for all of the tasks performed in situation analysis. Remember that collaborative discovery is key, and the team won’t be able to get all the information they need unless they have the help of the people who carry out the work that performs the capabilities. Everyone needs to be able to fully understand the situation, not just high-level project contributors. Make sure you communicate with your stakeholders and request feedback before moving on to defining the next level of requirements.





Business Capability Modeling

Use a business capability model, also known as a capability map, to represent the network of capabilities that your business currently has or needs to have to meet the organization’s strategic goals. Business capability modeling is the process of modeling what a business does to reach its objectives (its capabilities), instead of how it achieves its objectives (its business processes).

A capability model is a map of the enterprise that associates the business capabilities, processes, and functions required for business success with the IT resources that enables them. The goal of this approach is to model the business on its most stable elements. While the way in which a business implements its processes is likely to change frequently, the basic capabilities of a business tend to remain more stable.

Capability modeling is useful for highlighting the things that are impacted by changes in the business. It will help to answer the incredibly important questions...

p� What capabilities must change to support the project vision? p� What capabilities are no longer needed?

p� Are there any new capabilities that must be developed to execute the project vision?

There are many tools available for creating a capability model, including an outline with a word processing document, Post-It notes, or a diagramming tool that supports organizational charts. The facilitators of the exercise should work with stakeholders to identify a business owner for the model, ideally the leader who has P&L (profit and loss) responsibility for the scope being modeled, or a strategic planner for the P&L area. Then, perform the following steps:

1. Determine the scope of the model. The largest possible scope is the entire organization. Other levels of scope where capability modeling will add value are the geographic business unit, division, product/service line, and/or profit center. Use the top circle on the diagram to describe the scope of the hierarchy in the language of the stakeholders.

2. Identify and document high-level capabilities, such as Product Development, Marketing, Delivery, and Business Operations. This level of detail should represent the major capabilities within the scope managed by the business owner.

3. Decompose high-level capabilities into lower-level capabilities. Document lower-level capabilities.

Business Capability

PeopleProcesses Technology




McKinsey 7S Framework

The McKinsey 7S Framework is a model consisting of seven internal aspects of the organization that need to be aligned if it is to be successful. The 7S model is useful in many situations, such as:

p� Improving the performance of the organization.p� Examining the likely effects of future changes within the organization. p� Aligning departments and processes during a merger or acquisition.

p� Determining how best to implement a proposed strategy.

The elements within the model are interdependent, meaning a change in one will affect all the others. The seven elements of the model are:

p� Strategy: the organization’s alignment of resources and capabilities.p� Structure: how the organization is organized, including roles, responsibilities, and accountability relationships. p� Systems: the business and technical infrastructure that employees use on a day-to-day basis to accomplish goals. p� Shared Value: the set of traits, behaviors, and characteristics that the organization believes in, including the organization’s mission and vision.p� Style: the style of leadership adopted. p� Staff: the employee base, including staffing plans and talent management.p� Skills: the ability to do the organization’s work, reflecting on the performance of the organization.

For an organization to perform optimally, these seven elements need to be aligned and mutually reinforced. The model can be used to identify what needs to be realigned in the organization to meet the project vision. It can also be used to understand how the elements are interrelated to ensure that the overall impact of changes made in one area is thoroughly taken into consideration. More importantly, you can use the 7S model to help analyze the current situation in regard to the proposed future situation, helping to identify gaps and inconsistencies.

Structure

SharedValues

Staff

Skills

Strategy

Style

Systems




Capability Gap Matrix

The most commonly used technique for visualizing gap analysis is with a Capability Gap Matrix. Use the template on the following page and fill in the fields to the best of your knowledge to bring focus to the gaps that currently exist within your technology environment.

In the first column marked Business Service or Item, document the application type or technology element that you the organization currently lacks. This way, as you go through the matrix, any capabilities that are missing will be clear—the matrix will literally reveal the gaps. For each Business Service or Item, document the following:

p� Current Status: Document how it is currently performing. Include any issues or problems that it currently faces (e.g., inbound call centre is overwhelmed during peak calling times).

p� Timeline: How many months or years do you wish to have elapsed before the Desired Future State is achieved?

p� Desired Future State: How do you envision the Business Service or Item after you have addressed the indicated issues. What’s your ideal state? The gap lies between your Current Status and this.

p� How Realistic?: Identify how likely you feel it will be that you can actually achieve the Desired Future State within the indicated timeline.

p� Recommended Action: Based on this assessment, what should be your next steps to ensure that this work is initiated?


Sam

ple

Gap

Ana

lysi

s Te

mpl

ate

BU

SIN

ES

S S

ER

VIC

E O

R I

TE

MC

UR

RE

NT

STA

TU

ST

IME

LIN

ED

ES

IRE

D F

UT

UR

E S

TAT

EH

OW

RE

AL

IST

IC?

RE

CO

MM

EN

DE

D

AC

TIO

N

1 2 3 4 5 6 7 8 9 10

Requ

irem

ents

Exc

elle

nce

Fram

ewor

k™Ch

apte

r Fiv

e: D

eter

min

e Ca

pabi

lty G

aps

77



✓

Current capabilities identified.

As-Is capability model developed.

Desired future capabilities identified.

To-Be capability model developed.

Capability gap assessment entered into RequirementPro™ or otherwise communicated to project contributors and stakeholders.

Task Completion ChecklistWhile there are not many tasks involved in assessing the capability gaps of the organization, it is essential you perform all of the following steps:




IntroductionProject constraints, assumptions, and risks should be captured early in the project to reduce the risk of catastrophic failure. According to the Business Analysis Body of Knowledge (BABOK), the purpose of defining constraints is to identify factors other than requirements that may affect the viability of the solution. The business analyst (BA) is responsible for determining and documenting all restrictions or limitations to the solution’s design, construction, testing, validation, and deployment. At the same time, assumptions are identified so that the project may continue forward in the face of unknowns, and are brainstormed and gathered collaboratively by project contributors, project managers, BAs, business executives, and stakeholders alike. In addition to defining constraints and assumptions, risk analysis enables the organization to prepare for the likelihood that at least some things will not go as planned.

The goal of documenting project constraints is to provide some guidance to the project contributors throughout the lifecycle. Constraints ensure you do not create a solution disconnected from the reality of the organizational context. For example, if you start developing requirements for a huge new system without knowing the budget, you may end up developing a solution that costs $10,000,000, instead of the $1,000,000 that ends up getting allocated to the project. This type of situation requires a lot of costly rework that could be avoided if the project team is aware of the budget and other constraints up front. The goals of project assumptions, however, are to determine how a project will presumably be run in the face of constraints and existing knowledge.

Chapter Six: Define Project Constraints and Assumptions

Define Constraints, Assumptions, & Risks

2.6 Chapter Six



Core Concepts

Project Assumptions

An assumption is a theory pertaining to the project that has been declared to be true, as if it were true. There are four types of assumption described in Task 4.6 Gather Assumptions, but project assumptions are essential to planning—sometimes, aspects of a project have to be assumed before planning can begin. For example, the business analyst might assume that there will be enough employees to finish the project because project assumptions are assumptions made to determine how a project will be run. Project assumptions will be made by the business analyst and then given to a project manager, as they are focused around the project team and environment. There are four categories of project assumptions.

p� Project Team Assumptions: Will contain information about project contributors, such as their individual skill level and business domain.

p� Physical Space and Resource Assumptions: Will contain information about office space, computers and network, telephones, and other equipment that may be needed by a project team.

p� Time Frame and Deadline Assumptions: Will contain information about project deadlines and time frames.

p� Communications and Collaboration Assumptions: Will contain information about things like regularly scheduled meetings or reporting processes.

Project Constraint

A constraint is a restriction or limitation on the possible solution. Think of project constraints as stating the immovable limit; they’re things you cannot change but that you need to be aware of. These high-level business requirements need to be communicated to stakeholders and project contributors, because they impose boundaries and restrictions within which the team must operate.

Business stakeholders will need to take constraints into account when providing the analyst with their stakeholder needs, and developers will need to take the constraints into account before they start to build anything. When the project team is unaware of constraints, it can often cause costly rework later in the project. To avoid having to fix mistakes later, it’s important to be fully aware of any limitations on the schedule or budget of the project, as well as restrictions on how the solution can be built.




Types of Constraints

Enfocus Requirements Suite™ divides constraints into three categories: budget, schedule, and technical. For examples of all three types of constraints, perform the exercise on page 84.

Budget Constraints

These constraints refer to limitations on the budget, which is fundamental to project success. Budget constraints limit the project team’s ability to obtain resources, and they also limit the scope of the project. Ensure the budget includes allocations for equipment purchases, software licenses, maintenance, support agreements, testing, training, and staffing. Depending on the type of project, the budget may also include consulting fees and outsourcing expenses.

Schedule Constraints

Schedule constraints ensure people know what the final due date is and what the major milestones are. Although specific dates are the most straightforward way to record schedule constraints, it is more effective to use a window of time in which a certain task should be performed. Time constraints should be written as “no earlier than,” “no later than,” or “on this date” if there really is no flexibility.

Technical Constraints

These constraints refer to limitations on the architecture of the project. Technical constraints tend to be inflexible and unchanging. Document any obstacles that will impact the project design and keep in mind any required enterprise architecture standards. Technical constraints can cover many topics, such as:

p� Development Languages

p� Hardware/Software Platforms

p� Application Software

p� Resource Utilization

p� Message Sizing and Timing

p� Software Size

p� Maximum Number and Size of Files

p� Records and Data Elements

p� Enterprise Architecture Standards




Project RiskAccording to BABOK, a risk describes an uncertain event or occurrence that may have an effect on the ability of the BA, project team, or organization to achieve an objective. Another way of looking at a risk is to view it as a description of an event with a probability of causing a decrease in value to a stakeholder (CARRDS: Constraints, Assumptions, Risks, Requirements, & Dependencies by Julian Sammy). Risk analysis is defined by BABOK as the process of identifying and managing areas of uncertainty that can impact an initiative, solution, or organization. Risk analysis includes three main tasks:

1. Tolerance assessment

2. Risk identification and assessment

3. Risk response strategy

Before the project team can identify risks and determine the correct way to respond to them, there must be an understanding of the organization’s tolerance for risk. Organizations often have different risk tolerances based on the situation at hand. For example. organizations will often accept greater risks to avoid a perceived loss than they will to increase the payoff from a success. The three main categories of risk tolerance, according to BABOK:

p� Risk-Aversion: An organization with this type of risk tolerance seeks to reduce risks and prefers to approach certainty as close as possible. Often, there is an acceptable tradeoff made between potential benefits and certain outcomes.

p� Neutrality: This approach to risk means that positive benefits gained from the risk response must equal or outweigh the costs to justify action.

p� Risk-Seeking: A risk-seeking organization is willing to accept relatively high risks to maximize potential benefits. Often, there are low chances of success, but the benefits of success are higher.

Risk assessment is the process of determining the probability that the risk will occur and the impact if it does occur. Factors should be assessed on a common scale. Once assessment is complete, the team can focus on responding to the most important risks. Response strategies include:

p� Acceptance: The project team makes no effort to deal with the risk. The organization accepts the possibility that the risk may occur.

p� Transfer: Responsibility for handling the risk is transferred to a third party.

p� Avoidance: The organization actively ensures the risk cannot occur.

p� Mitigation: The organization attempts to reduce the probability of the risk occurring or the possible negative consequences.

According to PMBOK, project teams should beware of risk conditions that can contribute to project risk, such as immature project management practices, lack of integrated management systems, concurrent multiple projects, or dependency on external participants who are outside of the project’s direct control.



ProcessOne of the main differences between constraints and solution requirements is that constraints are discovered, not developed. Although there is no true set of steps to follow, the discovery process should consist of a few essential elements that ensure all constraints are documented.

Who Documents Constraints, Assumptions, and Risk?

It is the responsibility of the business analyst to discover and document all project constraints and assumptions. However, the BA cannot do this alone; he/she requires the input of stakeholders that are relevant to the project and are also aware of the constraints that will affect the development of the solution. Often times, assumptions are not documented on paper, but exist solely in people’s heads, so stakeholder input is essential to discovering project assumptions, as well. Through collaborative interviews and group discussions, we suggest seeking the advice of key stakeholders, such as

p� Technical architectsp� The project sponsor

p� The project manager

Generally, the project manager (PM) is responsible for risk management, and activities such as planning risk management. To help the PM, a risk management team is put into place. According to PMBOK, the risk management team is determined as a part of the risk management planning meeting. In the risk management plan, the roles and responsibilities related to risk management are defined. One person must take responsibility for each agreed-to risk response.

Often , BAs are responsible for supplemental risk analysis and assessment tasks. In addition to helping the PM understand the level of risk tolerance, the BA can help assess individual risks and identify appropriate responses. However, like we said earlier, PMs are usually responsible for risk management, not BAs. Individuals who truly need to understand the intricacies of risk should refer to the Project Risk Management section of A Guide to the Project Management Body of Knowledge (PMBOK).

Where Do Constraints Originate?

The information required to document the constraints is usually produced in group discussions or one-on-one interviews. Ideally, as mentioned in other chapters, we suggest setting up a focus group or workshop in the beginning stages of the project to address all of the tasks in Situation Analysis.

In this meeting, the BA and stakeholders participate in a collaborative discussion concerning the constraints imposed on the project at hand. With the stakeholders, discuss any policies regarding protocol, standards, and vendors. If the solution is to be outsourced or purchased, find out if there are any policies on approved vendors or software platforms.




Where Do Assumptions Originate?

Project managers, project sponsors, business analysts, and project members should all collaborate to write a solid set of project assumptions. Project assumptions are gathered from stakeholder experience, prior knowledge, and the information currently available, so a project meeting or workshop will be necessary. Brainstorming with mind maps is useful for fostering discussion and a healthy flow of ideas, and interviews should be conducted with project managers, project sponsors, and key project contributors to gather project assumptions. See Task 4.6 Gather Assumptions for guidelines on writing good assumptions.

Where Do Risks Originate?

According to PMBOK, project risks may exist from the moment the project is initiated. Risks can have multiple causes. Often, causes are the potential requirements, assumptions, constraints, or conditions that create the possibility of negative outcomes. One example of a possible cause of a risk is having limited personnel assigned to develop the solution, the risk being that the organization may take longer than planned to deliver the solution.




What Must Be Documented?

Constraints

After key stakeholders have identified the limitations on the project, the analyst must ensure constraints are documented and presented to the project contributors and stakeholders. For each constraint discovered by the project team, ensure you do the following:

pp Ask why it exists.

pp Question its validity.

pp Record the reasoning for including the constraint.

In RequirementPro™, you must enter a dollar amount for budget constraints and dates for schedule constraints.

Assumptions

After assumptions have been gathered, they should be categorized and documented for organization and traceability. See Task 4.6 Gather Assumptions for more information on assumption categories.

Risks

According to the article CARRDs: Constraints, Assumptions, Risks, Requirements, and Dependencies by Julian Sammy, important information should be documented about every risk. Factors such as impact and probability should be assessed on a common scale, such as High, Medium, or Low, 1-5, etc. In addition, document the following aspects of a risk:

p� Event: Describe the thing that happens.

p� Impact: Describe the expected decrease in value from the event. As risks are inherently uncertain, it may prove difficult to usefully estimate the impact of the risks.

p� Probability: Describe the chance that the event will occur within a given timeframe.

p� Timeframe: Specify the probability and impact of the event depend on the timeframe of the risk. Formally documenting and understanding the timeframe helps to avoid wasteful over-preparation and short-sighted decisions. Often, probability of the event occurring increases in certainty as the timeframe increases. In other instances, some impacts are minor in the short term and accumulate in the long term.

p� Stakeholder: Specify the person or group of people who will experience the loss of value.




p� Response: Describe the plan or set of actions that will be performed to reduce the probability or impact of the risk. Follow these guidelines for risk responses, taken from PMBOK. Risk responses should be:

pp Appropriate for the significance of the risk

pp Cost-effective in meeting the challenge

pp Realistic within the project context

pp Agreed-upon by the project team

pp Owned by a responsible person

What Do You Do After Constraints, Assumptions,and Risks Are Documented?

Constraints

After the BA has documented all constraints in RequirementPro™, the next task is to ensure the stakeholders fully understand the restrictions that are placed on the project. Remember that constraints will have an effect on how the solution gets developed, as well as the final outcome. It’s important everyone understands the constraints at the beginning of the project and how the restrictions will affect their work. This will help to avoid costly rework later in the lifecycle.

Assumptions

After the BA has documented all assumptions in RequirementPro™, the assumptions should be reviewed by stakeholders in a massive and on-going basis. The assumptions’ review will consider things like quality, accuracy, and effectiveness while identifying assumption omissions. Because assumptions could be proven wrong at any time and affect the project, it is important to validate assumptions as the project progresses. Unverified assumptions increase the chances that the assumptions are not true and will put the project at risk.

Risks

Risk analysis outputs will be used in Task 3.7 Define Business Case to provide justification for project investment. The project may be approved if the risks are within the organization’s risk tolerance profile & balances out with the benefits gained by taking the risks.

To ensure individuals involved in the project are informed of the assumptions , constraints, and risks, publish an announcement on the Project Dashboard that let’s all RequirementPro™ and StakeholderPortal™ users know the constraints and assumptions are available for their review. If you would like to draw a particular user’s attention to the constraints or assumptions, assign that individual an action item for review.




Comprehension Exercise: ConstraintsFor each statement listed below, determine what type of a constraint it is: budget, schedule, or technical. The correct answers are listed on the next page.

STATEMENT CONSTRAINT TYPE

1. If a DBMS is used, it must be Oracle.

2. System must be in place no later than the end of 2013.

3. The new process must be fully deployed by the end of Federal fiscal year.

4. There is $3,000,000 allocated to this project.

5. Pilot must be deployed by December 31, 2013.

6. The solution must use SAP functionality with no customizations.

7. Project expenditures cannot exceed $1,500,000.

8. The solution must be able to run on older versions (IE4).

9. The project can start no later than April, 2013.

10. The solution must support wireless access to mobile users.




STATEMENT CONSTRAINT TYPE

1. If a DBMS is used, it must be Oracle. Technical

2. System must be in place no later than the end of 2013. Schedule

3. The new process must be fully deployed by the end of Federal fiscal year.

Schedule

4. There is $3,000,000 allocated to this project. Budget

5. Pilot must be deployed by December 31, 2013. Schedule

6. The solution must use SAP functionality with no customizations. Technical

7. Project expenditures cannot exceed $1,500,000. Budget

8. The solution must be able to run on older versions (IE4). Technical

9. The project can start no later than April, 2013. Schedule

10. The solution must support wireless access to mobile users. Technical

Comprehension Exercise Answers




Task Completion ChecklistBefore Task 2.6 Define Project Constraints and Assumptions is complete, the following activities must be performed:

✓

Documented schedule constraints.

Documented budget constraints.

Documented technical constraints.

Documented the reason behind each constraint.

Documented a dollar amount for all budget constraints that require one.

Documented a date for all schedule constraints that require one.

Documented project assumptions.

All assumptions have been reviewed and validated by stakeholders.

Assumptions are categorized.

Assumptions discovered through collaboration.
