Building a Useful Goal Statement - Raphael L. Vitalo, Ph.D.

Introduction

Whether a task is self-assigned or assigned by another, there is a minimal set of facts one needs to perform the task successfully. These are:

• the goal of the task,
• the resources to be provided prior to starting it (inputs),
• the outputs the task must produce,
• the method that will be used to transform inputs into outputs (process),
• the test one completes to verify that the task was executed correctly (feedback), and
• a list of the individuals or groups with whom to communicate while performing the task (coordination), the information to be exchanged, and the protocols to follow with each.

This article provides you with guidance for representing the first component of this set of knowledge, the task's goal. Use it to define a goal you seek to realize or as a guide for documenting the goal someone else seeks to realize.

Goal

A goal describes the result your efforts seek to produce. It is the reference point you use to plan your work and evaluate whether you succeeded. A goal statement also enables you to orient others to what you are attempting to realize and therefore is the basis for eliciting their cooperative efforts in pursuing it. All of these benefits, however, depend on the goal being sound. If the goal is not sound, it will point you in the wrong direction, lack information you need to ensure your success, or provide erroneous criteria for your use in deciding whether you succeeded. A badly formed goal is just as potent as a well-formed goal—except that the former ensures failure while the later enables success. The process documented below and outlined in Exhibit 1 guides you in ensuring that the goal you form will enable your success, not ensure your failure.

Getting Ready Tasks

1. Document the “Why” Behind a Goal

Every goal has a reason that prompted its creation. The “why” is either to solve a problem or to advance the realization of some opportunity or larger purpose. You will use this information to define the result the goal must produce and to build and check its correctness. To document the “Why” behind the goal you are about to write, you need to answer the following questions.

• What is the problem this goal is suppose to resolve or the opportunity it is to advance or realize?
• How, when, and where was the problem or opportunity detected?
• Who does this problem or opportunity involve or affect?
• How is the problem hurting whomever it involves or affects or how can the opportunity enhance these people or groups when it is realized?
• Why does the problem exist? In other words, what are its root causes? Which root cause is the goal eliminating? What needed elements must be put in place to advance or realize the opportunity the goal was established to advance? Which needed element is the goal putting in place?
• What previous efforts have been tried to remove this root cause or to put in place the needed element?
• Why did these efforts fail?

Record this information. Keep what you record as you will use it as you proceed through this process.

2. Understand the Structural Foundation of Every Goal

Every human goal involves transforming an object from a “given” state to a “desired” state. In the case of a problem, you are eliminating something that is unwanted. In the case of an opportunity, you are putting in place something that is needed. This act of transformation defines the result your goal must realize. To build a well-formed goal statement, you first need to know what is to be transformed (the Object) and both its initial and desired final state. These elements—as well as who will do the transforming (the Actor)—constitute the structural foundation of every goal. They are: the object to be acted on, the initial state of the object and its intended final state, and the actor responsible for producing the final state (Exhibit 2). Before writing your goal statement, you must identify the beginning structural foundation of your goal. Here, learn the meaning of each of the structural foundation elements.

3. Extract the Goal’s Structural Foundation from the “Why” Information

The beginning structural elements of your goal are derived from an analysis of the reason why the goal is being pursued. In the top section of Exhibit 3 is an example of the “Why” behind the goal for someone who is assigned to produce the software specifications for a computer application. It is an abridged statement for reasons of space. In the bottom section of Exhibit 3 is the beginning structural foundation elements of a goal extracted from the “Why.”

4. Define the Result the Goal Must Accomplish

To define the result that the goal must accomplish, express the goal's foundation structural elements as an infinitive phrase. An infinitive phrase has the basic form: "To [verb] + [object]." When used as a format for restating the structural foundation of a goal, it literally reads: "To transform [object] from [initial state] to [final state]." For example, here is how the structural elements recorded in Exhibit 3 would read, if written literally: "To transform the software specifications for a computer application from not existing to existing." You should adjust this literal translation for readability. Thus, the previous statement might be rendered as: "To produce software specifications for a proposed computer application." This infinitive phrase describes the result the goal must produce.

5. Understand the Components of a Complete Goal Statement

Each useful goal statement includes six components: a "to" statement that tells the result to be produced, a "for" statement that tells who is to benefit from accomplishing the goal, a "by" statement that names the task or process to be implemented to produce the result, a "so that" statement that lists the benefits to be produced for each benefiting party, a "conditions" statement that lists the constraints that one must abide while achieving the goal, and a "success criteria" statement that lists the benchmarks that define success (Exhibit 4).

	Exhibit 4. The Components of a Complete Goal Statement
	Component	Contents
	To	States the result the goal must produce. Always begins with "To," identifies the object to be created or transformed and the final state it should be in when the goal is realized. Example: “To produce Widget A” or “To make Product X more customer satisfying.”
	For	States for whom the result is being produced—the beneficiaries of the goal’s achievement. Example: ”For customers, the business, and all its stakeholders.”
	By	Names the method that will be used to accomplish the “To.” An example is: “By eliminating unwanted features and adding wanted features.” To be correct, the “By” activity must be capable of accomplishing the result specified in the “To” while satisfying the “Conditions” listed below.
	So That	Lists the immediate benefits the result should produce for each beneficiary of the goal. Each benefit identifies how a beneficiary of the goal will be better off once the "To" is achieved.
	Conditions	States other requirements that the pursuit of the goal must satisfy. These may: limit resources used (e.g., time, money, people), state requirements specific to taking a certain action—e.g., use a specific tool or involve specified people or abide by a certain protocol in pursuing the goal (‘must do’ contstraints), or set as "off-limits" certain decisions or actions (‘must not do’ constraints).
	Success Criteria	The benchmarks that must be met for the goal to be judged as achieved. Always includes criteria that test whether the efforts expended: produced the result specified in the "To," delivered the benefits specified in the "So That," and satisfied the constraints recorded in the "Conditions."

Exhibit 5 presents an example of a complete goal statement defined by management of the XYZ Software Solutions Company. This company builds computing solutions that enable the secure and reliable archiving, transfer, and retrieval of business-critical data for its customers. A number of these solutions incorporate Netlink API calls. The company has noted that these applications have experienced many bugs that can be traced to how their kernel software developers implement code accessing the Linux Generic Netlink API. These bugs either are caught in testing and require fixes that add cost and delay the release of a customer required application or slip through testing and reach customers causing our customers unreasonable difficulties that compromise their performance and our standing as their software solutions vendor. To reduce development cost; speed release of stable, well performing solutions; and eliminate customer-experienced breakdowns in our products, the company's kernel programmers need to greatly reduce the number of accidental programming mistakes in their code that are due to incorrect practices in using the Linux Generic Netlink API. It appears that while programmers are schooled in how to implement this API, they do not apply the correct rules for using the API at the point of their programming.

Doing Tasks

1. Draft Your Goal Statement

Follow the steps defined below to represent your goal. Use the clarifying questions presented in Exhibit 6 to assist you in defining each component of the goal statement. Obtain the answers to these questions by analyzing the documented "Why" behind your goal. Use the tips provided in Exhibit 7 to locate what information in the reason why the goal is being pursued relates to each component of the goal statement.

1. Use the result you define in Getting Ready Step 4 to document the “To” component.
2. Record for whom the result is being produced—the beneficiaries of the goal—in the “For” component. Search the reason for pursuing the goal for all acknowledged parties connected to the problem being solved or the opportunity being realized. Each such party is a potential beneficiary from achieving the goal.
3. Name in the “By” component the process or task that will accomplish the “To.” The task must be able to eliminate the root cause of the problem or put in place the element needed to realize the opportunity the goal is to advance.
4. List the benefits in the “So That” component that the result should produce for each person or group identified in the “For” component of the goal. Flip each negative affect experienced from the current state into a positive benefit realized once the final state is produced.
5. List other requirements the pursuit of the goal must satisfy in the “Conditions” component. See Exhibit 6 for added guidance in identifying conditions.
6. List the benchmarks that must be met for the goal to be judged ‘achieved’ in the “Success Criteria” component. For now, state what should be checked and what state it should be in. Detailed guidance for building success criteria is provided in Doing Step 2.

As should be clear to you from this exercise, the better developed your description of the reason why the goal is being pursued is, the better the quality of the goal you can build.

	Exhibit 6. Suggested Clarifying Questions for Drafting a Goal Statement
	Component	Clarifying Question
	To	When this goal is accomplished, what should be changed? How should it be changed?
	For	Who is affected by this goal? Who should benefit from the result it will produce?
	By	How shall I name the task that accomplishes this goal?
	So That	What benefits should this task produce for each benefiting party?
	Conditions	Is there a time period within which this task must be completed? Where or when may this task be done (settings, contexts)? Where or when may this task not be done (settings, contexts)? With whom or what should the task performer coordinate during task implementation? What information should be exchanged? What communication protocol should be followed? What access to information is permitted during task performance? What access to information is denied during task performance? What resources will the performer have to work with in getting the task done? Consider people, training, tools, equipment, facilities, budget, etc.1 What resources are off-limits to the performer? What authority will the performer have for making decisions about direction, approach, resourcing, and the application of resources during task execution? What authorities are denied to the performer during task execution?
	Success Criteria	How should the successful achievement of this goal be judged? What features of the expected result should be measured? How? What values must be found to claim success? What features of each promised benefit should be measured? How? What values must be found to claim success? What features of each condition should be measured? How? What values must be found to claim success? (For more assistance in specifying success criteria, see Doing Step 2.)
	Adjust this language for machine performance. For example, with regard to computers doing the performing, one might think about accessible RAM, available storage, or the types of input or output devices or for non-computing devices. If the performer is an non-computing machine, one might consider operating temperature, speed, power consumption, breakdown rate, etc.		——

	Exhibit 7. Using the “Why” Information in Building the Components of Your Goal
	Information	Potential Use(s )
	What is the problem this goal is suppose to resolve or the opportunity it is to advance or realize?	Helps define the structural foundation of the goal.
	How, when, and where was the problem or opportunity detected?	Helps you uncover who is affected. May also assist in focusing the location where the goal's result must occur.
	Who does this problem or opportunity involve or affect?	Helps define the potential beneficiaries from achieving the goal.
	How is the problem hurting whomever it involves or affects or how can the opportunity enhance these people or groups when it is realized?	Helps identify possible benefits the goal's realization should produce.
	Why does the problem exist? In other words, what are its root causes? Which root cause is the goal eliminating? What needed elements must be put in place to advance or realize the opportunity the goal was established to advance? Which needed element is the goal putting in place?	Helps define the structural foundation of the goal. Also, provides information important to defining the action that will be implemented to achieve the goal.
	What previous efforts have been tried to remove this root cause or to put in place the needed element?	Provides information important to defining the action that will be successfully produce the result the goal must generate.
	Why did these efforts fail?	Provides information that relates to identifying conditions one should include in the goal statement. Basically, avoid what failed or include some specific action to prevent repetitions of prior failures.

2. Define the Goal's Success Criteria

Success criteria tend to be the most difficult goal component to define. As stated above, they are the benchmarks that task performance must meet for it to be judged successful. You need a success criterion for judging whether you have:

• produced each expected output,
• provided each benefit your task was to deliver, and
• satisfied every condition with which your performance was to comply.

Each success criterion is composed of three elements—an anchor, a measure, and a target (Exhibit 8). Exhibit 9 provides one example of a success criterion. The remainder of this guidance will describe each component of a success criterion in greater detail and build the success criteria for the goal specified in Exhibit 5.

Anchors

The anchor identifies a focus for evaluation—the who or what the evaluator will measure the status of. It names a result, benefit, or condition specified in the goal and the feature of it to be evaluated. For example, given the goal specified in Exhibit 5, the possible anchors would be:

• Programming mistakes related to using the Netlink API,
• Programmers' time spent advancing the development of the application as compared to time spent fixing Netlink API coding errors,
• Quality of code produced using Netlink API,
• Development time for code using Netlink API,
• Development costs for components using Netlink API,
• Programmers apply the guidance only their code uses the 2.6 series kernel,
• Registration of user processes that must be sent unrequested messages or data with the kernel component, and
• Consistency of coding with the understanding that the API is socket based.

Typically, more anchors are specified in a goal than the goal's manager will evaluate. How many anchors have success criterion written for them depends on the importance placed on correct goal achievement and the cost associated with completing the evaluation. An anchor's importance presumes that someone will make meaningful decisions based on its evaluation. Clearly, if no one will make meaningful decisions based on the evaluation of a particular anchor, then its evaluation is waste. Naturally, if someone should be making decisions based on the anchor's status, as judge by his or her fiduciary responsibilities, then that person's behavior should be adjusted and the anchor included.

Measures

The measure tells how you will detect the status of the anchor. Each measure specifies a method for calibration (metric) and the time period for making the calibration—e.g., count the number of work processes for which standards are documented monthly, sum the dollar amount of cost savings produced annually, compute the average level of satisfaction with training people report quarterly, or determine the percentage of actions finished on or before their "complete by" dates annually. It also explains how observed data is processed to produce the value needed to compare against the anchor's target (see example in Exhibit 8).

A measure may calibrate status in terms of quantity, quality, timeliness, or efficiency.

• Use quantity metrics to register whether some expected result exists, how much or how many units are produced, or how completely some set of activities are done or components of a product are implemented.
• Use quality metrics to register how correctly or how usefully some product or service outcome is rendered; how consistent it is with policy, guidelines or specifications; how satisfying it is to its recipients; or how improved it is over time.
• Use timeliness metrics to register whether schedules are met or resources are available when needed.
• Use efficiency metrics to register whether an expected rate or ratio is realized—e.g., the number produced per unit of time or the relationship of monetary cost and benefits either to each other (e.g., cost benefit ratio) or relative to some benchmark (cost effectiveness ratio).

Exhibit 10 suggests which metrics are useful to consider given the focus of your anchor. Exhibit 11 lists the measures used to calibrate the status of anchors specified for the goal depicted in Exhibit 5, above.

	Exhibit 10. Examples of Metrics for Anchors Having Different Focuses
	If the Anchor Focuses On ...	Then Consider These Metrics ...
	The presence or absence of an object or feature	"Yes" or "Present" and "No" or "Absent"
	The amount or size of something	Count Area Weight	Length, width, or height Volume Sum
	The typical amount of something produced multiple times	Mean (or average) Median	Mode
	The degree to which a quality indicator is realized or improvement has occurred	Percent Difference from expected	Difference from baseline Slope of the line of best fit for a time series
	The timeliness of occurrence	Percentage of on-time deliveries	Difference between expected and actual delivery dates
	The efficiency of performance	Cost per unit produced Number produced per unit of time Ratio of cost to benefits (ROI)	Ratio of old to new cost Ratio of unit cost to a benchmark (e.g., industry average)

Targets

The last element of a success criterion is the target. It states the value on the measure that indicates whether the anchor's status meets expectation as defined by the goal—e.g., 25 work process standards documented, $5,000,000 in cost savings realized, "expenditures do not exceed budget" or "report contains all requested information." Exhibit 11 presents the complete statement of each success criterion named in the success criteria section of the goal depicted in Exhibit 5, above.

3. Test the Goal's Correctness

Use the guidance in Exhibit 12 to verify the correctness of your goal statement. Correct any goal component that fails. Retest the corrected goal to ensure that the proper changes were made. Once done, document the goal in its final form.

Following Up Tasks

1. Document the final, verified goal.

Record your tested goal. Use the format depicted in Exhibit 5, above. It permits you to create a visual display that can be mounted and shared with others involved in pursuing the goal. Be sure to add a table as depicted in Exhibit 11, above, to document the complete success criteria that must be used to judge the success of your efforts.

2. Use the goal statement to plan, execute, and achieve the goal.

After aligning yourself and others to the goal that must be realized, use the goal statement to prepare an action plan for accomplishing the goal. An example of an action plan can be seen here - Action Plan. Guidance for building an action plan is provided in the Kaizen Desk Reference Standard (Vitalo, Butz, and Vitalo, pp. 345–348).

Special Circumstance—An Assigned Task or Purpose

When a task or purpose is assigned to you by another, there is additional work one must do in defining a proper goal. Since supervisors, managers, and executives rarely provide the information needed to understand the work they assign, you must ferret out what it is they want you to accomplish through dialog with them and by comparison of the "Why" behind the assignment and the apparent content of the request as made. Usually, there will not be a match between these elements because the person assigning the goal is unlikely to be skilled in building goals. As a result, the goal statement derived from a correct documentation of the reason for pursuing the goal will not match the statement derived from the verbal or written guidance provided by the person assigning you the goal. For assistance in addressing this particular issue, see Leading a Kaizen or Lean Initiative: First Task. While the article addresses specifically the circumstance of being assigned a task associated with implementing Kaizen or a Lean initiative, it is straightforwardly applicable to any task or purpose assigned to a performer. It provides guidance for documenting the goal of an assignment made to you by another from the perspective of the person making the assignment. Use the guidance in this article to document the goal as it should be defined based on the actual reason the goal is being pursued. Work through any discrepancies between the two with the person assigning you the work.

©1990-2020 Vital Enterprises - Hope, Maine 04847 - Published July 2008; Revised October 2010, December 2010, October 2012, February 21, 2013, June 27, 2019, December 12, 2020

Help Us Provide You Better Content.
Tell us your thoughts about this article.
Be sure to name the article in your feedback.