Create a business goal model

Construct a measureable business goal model using a Collaborative work session. You'll use the basic 1-2-3 - Plan-Perform-Communicate approach. What follows are things to think about and specific actions to perform planning your work session, carrying it out, and consolidating and communicating your model.

Plan a goal modeling session

1. Identify scope of concern to appropriately constrain the model

Goals can occur at a variety of different levels. Starting at very high levels like: happiness and world peace, to very low or detailed levels like: get to work on time. Set a scope of concern for the goals you're about to model by writing a short statement about that scope. A good statement might be:

To help focus scope consider the product or business area of focus and the timeframe. A single product for next release for example. Other example might be an entire business unit over the next year or a single team developing a single set of features for the next internal release of a software product.

Given the session goal of creating a simple goal model, and the goal scope you'd like to target, you're ready to move forward to identify best participants.

2. Identify participants

An effective goal modeling session might include 5-8 participants. Start by identifying the participants of the session.

If you're unable to assemble a team balanced with business stakeholders and design and development team leaders, you may assemble others that can make assumptions about business goals. But consider it a risk to the quality of the results. Try to obtain feedback on the resulting model from the business stakeholders and expect that feedback will likely result in change to the model.

You may elect to Interview business stakeholders and bring the distilled data from those interviews to the modeling session. One or more members of the team should study this data, preferably the person who conducted interviews and distilled the data. They will function as information suppliers. Plan time in the meeting to review this data prior to building the goal model.

3. Prepare collaboration supplies to use for capturing results during the modeling session.

You'll likely need index cards to model, pens, tape, and poster paper.

4. Set a time and place for the meeting.

Expect the meeting to be as short as 30 minutes, but don't plan to spend longer than 90 minutes. Ahead of time set up the room with supplies, parking lots and feed forward bins, and Pace keeping signals help groups self-regulate.

Conduct the modeling session

1. Kickoff modeling session and set goal context

Kickoff the modeling session.

Making sure the group knows each other. Allow them to introduce themselves if they haven't worked together before.

Describe to the group the process you'll be following.

Discuss the scope of concern for the goals you'll be modeling. Adjust the scope of concern as necessary based on the discussion.

2. Brainstorm Goals and Problems

Start by creating a candidate list of business goals and business problems to solve. Brainstorm the goals and problems on to index cards using CardStorm to get ideas on the table. If usually try a private brainstorming approach followed by public consolidation. When identifying business goals or pain points, I'd rather not have a stakeholder's position in the organizational chart affect their ability to participate - and private brainstorming helps mitigate that.

For the purpose of brainstorming business goals, consider problems or pain points as interchangeable with goals. We'll have opportunity to consider the language we choose to express them later. Coach the team brainstorming goals and pains to give both goals and pains.

3. Refine Goals

Once brainstorming has slowed or stopped, cluster the goals and pains using an Affinity Diagram.

For each cluster of goals and pains, as a team write a new card that best summarizes the goals and pains in the cluster. If it's difficult to write a goal statement splitting the cluster may help separate out ideas that are making it difficult to summarize.

4. Prioritize goals

Gather the cards that summarize each cluster of goals. These will be the refined list of goals we'll prioritize.

Use the scope of concern to help set foundation for the prioritization. It's good to restate that scope, along with questions that frame the prioritization exercise. Questions like: "which of these goals are most critical to achieve for this product for the scope we're considering?" are helpful.

You could lay the goal card on the table to perform simple prioritization. Or, you may choose to prioritize goals using a voting approach as in democratic prioritization.

Hopefully your session contains a mixed group of business stakeholders responsible for defining goals and setting priority, and development team members responsible for designing and building the product to meet those goals. You may choose to allow only the business stakeholders perform the prioritization while others look on and ask questions.

At this point a good prioritized goals list has 1-3 goals that are easy to agree on as high priority. The goal list could be fairly long, but it's difficult to manage the design and development of a product with too many goals to consider. Choose the highest priority goals to single out and emphasize. One to three are ideal. Try to choose no more than five. These become our focal business goals.

5. Question goals and capture metrics for focal business goals

To make these goals more tangible and allow us to make better downstream design choices it's important to identify metrics that help us determine if we're making progress towards these goals.

For each goal ask the question:

Brainstorm and capture the answers to these questions on index cards as candidate metrics for each goal.

For example given a goal like: "decrease need for customer support"

possible metrics might be:

• "number of support calls relative to products sold."
• "average duration of support calls"
• "number of email requests for support'

Defining measurable goals like this might compel us to do further analysis on the nature of support calls we're getting today. Areas of the product that have the highest frequency and duration of support goals may be best areas to focus design and development efforts on.

Allow subjective metrics along with a more objective way of gathering an measuring change in them. For example let's assume we're upgrading software used in our internal call center. Today our agents claim that they really hate the software. It's often mentioned in exist interviews as a factor in quitting.

Given a goal like: "increase user satisfaction"

Possible metrics might be:

• "satisfaction rating 1 to 10, 10 being very satisfied"

Take a measurement today by polling the current agents of the software. The same question might be asked of agents testing interim released of the software, and of agents after the software is released and installed. Changes in this measurement will give some indication of increases or decreases in user satisfaction.

After writing out possible metrics for a goal, eliminate obviously bad ideas. As a group discuss the metrics. Do they really help us determine if we're making progress on this goal? Are there other factors that influence the metric such that if may give us inaccurate measurements of our goal? Multiple metrics per goal better give a picture of progress on the goal. If one metric is influenced by other factors, possibly the other metrics will help give better indications.

Rewrite or eliminate goals that can't easily be measured

Often the discussion of metrics results in the realization that a goal is difficult or impossible to measure. It's at this time we need to ask if this is a reasonable goal. If our organization can't detect if we're making progress against it, then it'll be very difficult to let this goal guide us in making detailed design and scope decisions.

For each goal identify one to three metrics you might use to measure progress on the goal.

Feed forward product feature ideas

Often when defining metrics for goals you may detect that the software may need functionality that captures and reports on these metrics so that can be observed. You might realize that someone in management would be very interested in seeing these metrics on a regular basis. This information is useful to place in a feed forward bin labeled "product feature ideas."

As ideas come up for possible software features, park them in a feed forward bin for later consideration. Then continue on with your discussion.

6. Summarize and reflect

Close the modeling session by reviewing the prioritized focal business goals. Ask a business sponsor or other business stakeholder to do this review. There should be one to three goals, ideally no more than five. For each goal review the metrics that measure progress towards that goal. If possible use a camera to record a video of the review.

If the model wasn't completed before the end of the timebox, discuss times to continue the session.

Identify the team member who will be responsible for documenting and posting the goals where they can be seen and used.

Suggest that one of the stakeholders verbally summarize the model to the camera in a model movie.

Close by circling around the group for parting takeaways.

Distill, document, and communicate goals

For these goals to be relevant and leveraged, they must be accurately captured and displayed in a prominent location.

Record the names of the modeling session participants.

Take a Model photo to help participants recall what happened during the session.

Document the model as a Model poster, electronic distillation, or in some other document that can be easily used by the project team and external business stakeholders.

Along with the focal goals and metrics, the documented business goals should contain the names of the group responsible for arriving at them and model photo to help others relate to the process used to arrive at these goals.