Share/Learn
Main Ask an Expert Member Information Home
Body

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

  Contents
Introduction
Goal
Getting Ready Tasks
1. Document the “Why” Behind a Goal
2. Understand the Structural Foundation of Every Goal
3. Extract the Goal’s Structural Foundation from the “Why” Information
4. Define the Result the Goal Must Accomplish
5. Understand the Components of a Complete Goal Statement
Doing Tasks
1. Draft Your Goal Statement
2. Define the Goal's Success Criteria
3. Test the Goal's Correctness
Following Up Tasks
1. Document the final, verified goal.
2. Use the goal statement to plan, execute, and achieve the goal.
  Special Circumstance—An Assigned Task or Purpose
  Download a PDF of This Article
  Feedback Please

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.

Top

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.

Top

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.

Top

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.

 

Exhibit 2. The Elements That Constitute the Beginning Structural Foundation of Any Goal

 
 

Object

Any logical or physical thing—e.g., a car, a software design, an audience of people attending a seminar  
 

Initial State

The current or found state of the object before the actor begins performance. This state will be either that the object does not yet exist or it exists in a way different from what is desired—e.g., we have no car or our car does not start  
 

Final State

The end or transformed state of the object after the actor completes his or her performance—e.g., we have a car or our car starts  
 

Actor

The identity of the performer that must produce the final state (may be a person or machine; must be either a class of performers—e.g., Software Engineers or a member of that class—e.g., Miguel Valenza, Software Engineer)

 
     

Top

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.”

 

Exhibit 3. An Example of Extracting the Beginning Structural Foundation of a Goal From the Reason Why It Is Being Pursued

 
 

Example of the "Why" Behind a Goal

 
  Software Engineers at the XYZ Software Solutions Company build tailored computer solutions for businesses experiencing computing-based problems. Their work takes a problem a customer is experiencing due to the absence of an adequate software solution to their computing needs and uses that information to design and build a computer application that accomplishes the task the customer needs done thereby eliminating the barrier to success that the customer is experiencing. One link in this process is the production of software specifications. This document translates the customer's needs as described in a software requirements document into guidance that programmers use to build the software solution that will meet the customer's needs. A software engineer must create this software specifications document. Without such specifications, the development of a software application of any significance is almost certain to fail and with that failure the XYZ's software business itself will fail.  
 

Beginning Structural Foundation Extracted From the "Why"

 
  Object The software specifications for a proposed computer application  
  Initial State Does not exist  
  Final State Exists  
  Actor Software engineer  
     

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.

Top

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.

 

Exhibit 5. An Example of a Complete Goal Statement

 
 

Component

Example

 
  To "To reduce the accidental programming mistakes contained in software applications using the Linux Generic Netlink API"  
  For Kernel programmers, our customers, our company and its owners  
  By Equipping programmers with point-of-use guidance that eliminates their errors in using the Linux Generic Netlink API  
  So That
  • Programmers focus more on advancing product development and less on correcting problems caused by their errors in using the Netlink API such as Namespace collision of protocol families and Demultiplexing messages.
  • Customers get a better product, faster.
  • The company's reputation as a quality software solutions vendor is preserved
  • Owners have lower development costs and shorter development cycle times
 
  Conditions
  • Must use the 2.6 series kernel.
  • Must register with the kernel component every use process to be sent unrequested messages or data
  • Must recognize that, in user space, the API is socket based and program accordingly
 
  Success Criteria1
  • Programming mistakes related to using the Netlink API are reduced
  • Programmers' time spent focusing on the problem to be solved relative to fixing Netlink API coding errors increases
  • Quality of code produced using Netlink API is elevated
  • Development time for code using Netlink API is produced faster
  • Development costs for components using Netlink API are reduced
  • Programmers apply the guidance only with code using the 2.6 series kernel
  • Code registers with the kernel component every user process that must be sent unrequested messages or data
  • Coding is consistent with the understanding that the API is socket based
 
 
  1. The statements recorded here are abridged versions of the success criteria. Each has the anchor of a success criterion and the final state is should possess. They are used to accommodate the space available in a goal statement. See Exhibit 11,below, for the complete statement of each success criterion identified above. Every goal statement should have such a table attached to it.
 
     

Top

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.)

 
 
  1. 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.  
       

Top

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.

 

 

Exhibit 9. An Example of a Success Criterion

 
 

Anchor

Measure

Target

 
  Tells what the evaluator wants to know the status of Tells how the evaluator gauges status Tells the value on the measure that defines success  
  Revenue growth Each month, subtract current quarter revenues as reported in financial statements from revenues earned in the same quarter last year. Divide by revenues earned in the same quarter last year and multiple by 100%.

=>12%

 
  Together, the components provide an evaluator the information needed to judge whether the element of a goal specified in the anchor has been successfully accomplished.  

 

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.

 

Exhibit 11. Success Criteria for the Standards Section of the Goal Depicted in Exhibit 5 (continued)

 
 

Anchor

Measure

Target

 
  Programming mistakes related to using the Netlink API Ratio of the average number of coding errors related to Netlink API use observed when coding does not use the guidance as compared to when it is used Ratio is greater than 1  
  Programmers' time spent advancing the product relative to time spent fixing Netlink API coding errors Ratio of average percentage of development time for code using Netlink API spent fixing Netlink API coding errors to baseline established prior to use of guidance Ratio is less than 1  
  Quality of code produced using Netlink API Ratio of the average incidence of coding errors for components using Netlink API before introduction of this guidance to the average for components using Netlink API after the introduction of this guidance1 Ratio is greater than 1  
  Development time for code using Netlink API Ratio of the average development time for components using Netlink API before introduction of this guidance to the average for components using Netlink API after the introduction of this guidance1 Ratio is greater than 1  
  Development costs for components using Netlink API Ratio of the average development cost for components using Netlink API before introduction of this guidance to the average for components using Netlink API after the introduction of this guidance1 Ratio is greater than 1  
  Programmers apply the guidance with code using the 2.6 series kernel Count the incidences where the guidance is applied with code not using the 2.6 series kernel 0  
  Code registers with the kernel component every user process that must be sent unrequested messages or data Count the incidences where a user process that must be sent unrequested messages or data is not registered with the kernel 0  
  Coding is consistent with the understanding that the API is socket based Count the incidences of coding statements that are inconsistent with the understanding that the API is socket based 0  
 
  1. Comparison adjusts for the average size and complexity of the components being compared.
 
         

Top

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.

 

Exhibit 12. Verifying the Correctness of a Complete Goal Statement

 
 

Component

Contents

Test

 
  To States the result the goal must produce. Always begins, "To" and ends with naming whatever the task must generate.
    If the "To" correctly represents the object to be created or transformed and the final state to be produced,
    Then the "To" is verified.
 
  For States for whom the result is being produced—the beneficiaries of the goal.
    If the "For" identifies the primary beneficiary and every other party who is to benefit from the goal's achievement,
    Then it is verified.
 
  By Names the task or process to be implemented.
    If the "By" specifies an action that one might reasonably expect will produce the result specified in the "To" given the "Conditions" stated in the goal,
    Then it is verified.

(Note: Correct any problem by either adjusting the constraints or seeking an alternative method for producing the result the goal must generate.)

 
  So That States the benefits the result should produce for each beneficiary. Identifies how the beneficiaries of the goal will be better off once the "To" is achieved.
    If there is at least one benefit identified for every party specified in the "For" statement
    and each benefit is a likely immediate consequent of accomplishing the result listed in the "To,"
    and the benefits listed in the "So That" component satisfy the gains desired as stated in the "'Why' behind the goal?"
    Then it is verified.

(Note: If the first condition is passed and the second is failed, then fix the "To." If both are failed, then fix the "So That" and retest.)

 
  Conditions States other requirements the performance of the task or process must satisfy. These may:
  • limit resources used (e.g., time, money, people),
  • require a performer to do certain actions—e.g., use a certain tool or involve specified people, or
  • set as "off-limits" certain decisions
    or actions.
    If the "Conditions" list all the constraints expressed in the "Why" behind the goal
    and every constraint that owner of this goal expects its accomplishment to satisfy,
    Then it is verified.
    (Note: If the Conditions fail, correct them and then retest the "By.")
 
  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."
    If each success criterion has an anchor, measure, and target stated,
    and there is an anchor to judge whether the "To" was accomplished,
    and there is an anchor to judge whether each benefit in the "So That" component was delivered,
    and there is an anchor to judge whether each constraint in the "Conditions" component was satisfied,
    and for all measures, it is true that each specifies a metric, method of measurement, and a method for evaluating the information measurement produces,
    and for all measures, it is true that the measure, if implemented as described, would produce information that one could reasonably use as evidence that the anchor was satisfied was also achieved,
    and for all measures, it is true that each generates a result that can be used to test whether the target has been realized,
    and for all targets, it is true that each expresses a result that, if realized, would reasonable justify concluding that the anchor was realized,
    Then the success criteria component is verified.
 
     

Top

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.

Top

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).

Top

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.


Top

©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.