Drifting Goals

The Drifting Goals Archetype applies to situations where short-term solutions lead to the deterioration of long-term goals.  Also known as Eroding Goals, this is a special case of Shifting the Burden.  This Systems Archetype was formally identified in Appendix 2 of The Fifth Discipline by Peter Senge (1990).  The Causal Loop Diagram (CLD) is shown below.

When a gap exists between the current state of the system and our goal (or desired state), we take action proportional to the gap to move the system state toward our goal.  There is always a delay between the action we take and the effect on the system.  Simultaneously, pressure is exerted to instead adjust the goal to close the gap.  Adjusting the goal leads to a situation where the goal floats independently of any standard.  It often leads to goals being reduced, or eroded.

Classic examples of drifting goals include:

• Reducing quality targets to improve measured quality performance (relative to goal) or to improve delivery schedule
• Reducing quality of ingredients or parts below company standards to improve profits
• Increasing time to deliver to match existing capacity and save on overtime
• Reducing a new product’s feature set to meet deadlines; this works the other way also, i.e., extending the deadline to include all of the features
• Reducing pollution targets when reduction implementation costs are too high
• Increasing budget deficit limits rather than decreasing spending (or increasing taxes)
• Adapting to unacceptable social circumstances rather than leave that environment
• Reducing entrance requirements because not enough applicants meet them
• Reducing level of patient care below recommended minimum due to understaffing
• Reducing margin to spur sales and meet revenue targets
• Lowering your own expectations in life, leading to lower personal success

Note that in many of these cases, there are competing goals and one is held more sacred than another.  Drifting Goals is an insidious process that seeks to lower your standards to the level of the current state of the system.  Stay aware of not just how the state of the system adjusts to your goal, but also of how your goal varies over time.  Changing a goal should be a conscious decision that does not undermine other objectives.

Exploring Drifting Goals in Sales

A policy that leads to drifting goals is often subject to many competing pressures, as well as a historic baseline performance level for that goal.  From the description of drifting goals, it should be clear that policies that are partly based on historic performance can be particularly troublesome because as the goal drifts in response to historic performance, so, after a delay, does the historic performance.

The following model, available here, looks at the impact of reducing price to increase sales in response to falling behind sales targets.  If price reductions will help you meet your targets, why not lower the price?

This model looks at performance across quarters rather than the aggregate performance over long periods of time.  This mimics the extra pressure put on sales people at the end of each quarter rather than applying constant pressure because annual targets are not met.

Note there are three important feedback loops:  A minor balancing loop that adjusts price to help meet sales targets (adjusting our goal of achieving that price and, presumably, a certain revenue from selling a certain number of units), the minor balancing loop that increases sales as a result of the price change (by changing time for decision to buy, the residence time in the sales pipeline), and the minor balancing loop that adjusts the market’s perceptions of our product’s value (the longer we persist in offering a low price, the more the market will expect a low price).  The fundamental solution is not modeled (and presumably requires a broader systems perspective instead of pressuring the sales department to treat their local goal as the company’s primary goal).

The model is initialized with a sales goal that can be met without reducing the price.  We then set unrealistic sales targets (by dramatically increasing monthly sales goal) to see what happens.  What would you expect to happen?

As shown in the graph above, without intending to, we permanently lower our price below our target price (called normal price in the model).  In addition, because we overused that policy lever, the market responds (changing their goal of what a fair price is) and starts to expect this lower price, putting the company’s viability in jeopardy.  Since the market expects the lower price, lowering the price no longer has any effect on speeding up the rate at which sales close:

We did not specifically examine the impacts of draining the sales pipeline prematurely due to aggressive pricing and sales tactics.  This will put further pressure on the sales team to reach their targets, creating more downward pressure on the price.

This model, like some sales departments, does not consider unit cost when deciding how far to lower the price to drive sales.  Note that losses will be incurred if the price is driven too low, further accelerating the demise of the company (the so-called death spiral).

You may wish to experiment with changes to this model:

• Varying the transit time of the conveyor doesn’t quite do what we intend.  We are trying to model sales closing faster which would mean that sales in the pipeline would exit sooner.  However, the conveyor never changes the transit time of something already on it.  What we are doing instead is varying the length of time it takes new leads to close.  This is not quite right as it pushes the sale we’re trying to close at the end of the quarter into the next quarter, but on average, with continued pressure to close, this approximates the behavior we desire (it’s basically offset a quarter).  To make this more accurate, you would need to add a second leakage flow (people buying early) that has a leakage fraction that varies with the price.  You could also replace the conveyor with a stock and use a draining process instead (the continuous formulation).
• The sales arrival rate is stochastic.  What if it were continuous?  Would these same behavior patterns continue?
• The sales goals are quarterly and the price incentives move to a quarterly beat.  What if these were continuous?  Would the same behavior patterns emerge?  Hint: Instead of quarterly sales and quarterly sales goals, you can accumulate total sales and cumulative sales goals and use their gap to drive prices.  However, be a little careful as the goal itself will typically also drift if it is repeatedly missed.

Exploring Drifting Goals in Project Management

Many product development projects start with goals for features included, development cost, deadline, and product quality.  In many cases, the deadline may be arbitrarily determined by a feeling about what the market expects (rather than how long it should take given the assigned resources).  In these cases, there will be strong pressure to deliver the product by the deadline, often at the expense of other goals, most commonly the feature set and the product quality.  In situations where the company preannounces the availability of an improved product, sales of existing products may stagnate as people wait for the new product to arrive.  This will further increase the pressure to sell the product by the original deadline, or, in some cases, earlier.  This can also make it difficult to remove features to reach the deadline, as the feature set has already been exposed to the market.  Many times, the impulse to ship early becomes so strong that quality assurance is only performed in a cursory manner.

The model below, available here, shows a simplified rework cycle:

Note that to simplify the model, the processes that lead to drifting goals are not modeled.  We start with a fixed amount of Work to Do on our project.  The development staff accomplishes work based on their productivity.  Some of that work is done correctly (and ends up in Work Done), but some will have errors in it (Undiscovered Rework).  The errors are not found right away, and usually, we do not assign testing staff until later in the project, so the errors will grow over the length of the project.  As the testing staff is assigned and tests the product, errors are discovered and return to Work to Do to be corrected.

Our idea of project completion is based on the work we believe to have been done.  In the diagram above, this is Work Done + Undiscovered Rework.  Recall that in reality, we don’t know the levels of either of these stocks.  Another way to think about it is that the project is complete when Work to Do becomes close to zero.  At that point, and ignoring errors, we have implemented everything that was requested for this project.

In a situation where marketing has promoted a product, and/or sales thinks the product will get them a lot more sales, there will be pressure to release the product as soon as possible.  Even in the face of strict quality control measures, if revenues can be bumped by releasing something sooner – and there is some pressure to boost those revenues, perhaps due to poor sales performance for some time – then the product will be released as soon as someone thinks everything’s been done, regardless of established quality control processes.  In this case, we have eroded our goal of delivering a high quality product to satisfy our goal of increasing revenues by shipping the product sooner:

Based on Work to Do, the product is finished by month 33 and the company ships the product, even though only 80% of the work is done.  The other 20% is in Undiscovered Rework, which will certainly be discovered by customers.  Management is convinced this drop in quality will only happen this one time (i.e., it’s a temporary drift).

However, once this happens, customers will start complaining, which affects both reputation and sales.  More pressure will be created to release new versions quickly with the result that the goal permanently erodes with no one consciously making the decision to change it.  In addition, the people in the company will become accustomed to this new lower level of performance, further entrenching the lower goal.

There are, of course, other tradeoffs that can be made in project management:  extending the release date, increasing the budget (while also extending the release date), decreasing the feature set, etc.  However, especially with regards to software, management often views sufficient testing to be a luxury and therefore low-hanging fruit in the quest to deliver a product sooner.  Thus, the quality assurance goal frequently erodes in software projects.

Summary

Drifting Goals is problematic because the drift happens slowly and without either a conscious decision or an awareness of it happening.  It arises from slowly adapting to our surroundings and therefore changing our concept of what is normal or acceptable.  Arguments such as “We’ve always done this” or “It worked for our parents” point to established norms that might want to be examined to see if they reflect what is truly desired or what we have merely adapted to over time.  Identifying lowered standards can help point the way toward raising them again.