« Communications in Performance Management | Main | Strategy vs. Governance vs. Alignment »

August 6, 2005

When your Objective is to define Objectives

One of the best sets of definitions I've seen to distinguish goals, objectives and actions is a Planner's Guide having nothing to do with IT or business strategy but simply with organization. Getting to the point immediately, the guide states, "Objectives are more concrete than goals. They represent results we want to achieve within a specific time-frame."

It's seemingly a simple, efficient definition, but looking into it carefully, there are several points worth elaboration.

For one, the idea that "we want" means agreement amongst all parties. It is assumed, furthermore, that the relevant parties have some form of authority. The interesting question to ask here is, which came first -- the relevance, or the authority?

For another, the idea of "results" must be defined. This is most often where things get really confusing unless some standard or categorization is in use. For example, either of the following could be seen as the path to results we want to achieve:

- meet a specified requirement (would be "agreed", but could still be arbitrary)

- satisfy a critical dependency (would be logically mandated by a model, but the model might be hypothetical)

Although those two paths can account for virtually all instances of "results" we might consider, they both typically leave plenty of room for debate or negotiation amongst stakeholders about how important the result is to each stakeholder's perspective on fulfilling the ultimate purpose. Why is this the case? Because the truth is that depending on the active perspective, all "requirements" are not necessary, and many "dependencies" may be unknown or overlooked.
This points to the need for first reaching agreement on what the meaning is of the stated ultimate goal or purpose. From there, defining objectives is a step that begins to build a model of fulfillment for that purpose.

The general experience of practical science is that many phenomena are observed before they are understood. When a mechanism has been observed that succeeds at fulfillment, it tends to be adopted as the model until something else appears to do the job better. Comparing the dynamics of the two different approaches can yield an explanation of why one works better than the other. If obtained, that explanation typically becomes adopted as an "objective" of the fulfillment effort.

Modeling fulfillment is an exercise that runs in two directions -- analytic (diagnostic) and synthetic (inventive). But in management, based on the example above, more objectives are likely to be iteratively discovered than theoretically conceived -- because in management, "good enough" is largely dictated by "on time." In business, this means further that it is typically less expensive in the end to do trial-and-error based on known precedents.

Analysis is a method of attempting to discover precedents in order to make them known; this is generally called "business intelligence". In this way we can see that defined objectives may be the result.

A famous example of this is the original "Chaos Report" from the Standish Group in 1994, which studied the performance of project management in fulfilling the goal of "successful project". A standardized working definition of the goal -- "success" -- was applied for all projects studied. Projects were evaluated for success or failure. Then, reasons for failure were catalogued. Since the moment that the information was published, the "failure-reasons" have been dealt with as project management "success factors" -- where avoidance of failure is predicated on meeting the requirements of eliminating those errors that lead to failure. The Chaos Report ranked these success factors in order of highest criticality to lowest:

Project Success Factors
1. User Involvement
2. Executive Management Support
3. Clear Statement of Requirements
4. Proper Planning
5. Realistic Expectations
6. Smaller Project Milestones
7. Competent Staff
8. Ownership
9. Clear Vision & Objectives
10. Hard-Working, Focused Staff

So -- are those ten items "objectives"?

As an experiment, let's group those items into a smaller number of categories.
- Buy-in: items 1, 2, 8, 10
- Stakeholder Communications: items 1, 3, 5, 9
- Technical competency: items 4, 6, 7, 10

It's not difficult to imagine that timely, persistent buy-in would result from successful communications about relevant capabilities. Since that logical interaction is a way of modeling support of projects and thus adding assurance to the project's potential fulfillment success, then are the three categories "objectives" ?

The answer is Yes, from the perspective of "project support"...

But how about from the perspectives of "project control" and "project development"? Those are two equally important aspects of project management. Each aspect may need a respectively different group and grouping of success factors, which might lead to differing higher-level requirements or dependencies being identified.

But in any case, this generally suggests that a diagnostic approach to performance will yield success factors that roll up into objectives, with objectives being categories of desired effects.

In quickly surveying (via Google and Teoma) a history of related terminologies, the term CSF (Critical success factor) is generally synonymous with "Objective", while the measurable execution of action and events underlying the CSF is typically referred to with the concept of KPI (Key Performance Indicator).

Yet the problem persists that a logical distinction of underlying issues largely depends on what "goal" is considered to be the top-level starting point and who sets that point. How do we bring a standardized discipline to branching or cascading from the starting point, regardless of where it is?

An important related observation fitting the bulk of those here in Archestra's content is a simple one: acts and events underlie execution, and execution underlies performance. Said another way: behaviors have effects, and effects change states. Objectives are typically concerned with important states. In parallel to that:
- the ten sins of project chaos that Standish uncovered would be seen first as execution items (KPIs, effects) needing better underlying behavior (operational success factors);
- and the three derived categories of effects are performance-level success-factors (Objectives) representing positive states or conditions needed for success.

For another extended discussion of this issue, visit BPMMag.net

Posted by Malcolm Ryder at August 6, 2005 12:37 PM

Trackback Pings

TrackBack URL for this entry:
http://www.malcolmryder.com/cgi-bin/mt-tb.cgi/96

Comments

Post a comment