Events What's new?
Services Questions? Comments?

Strategy & Alignment Operational Problem Solving Project Management Implementation & Change Management

Consumption of Effort and Conservation of Energy for Project Success

There's been a commercial I've been seeing on TV recently (late 1999) that leaves me with a questionable response to the company presenting it. It's for a system development company and features a vignette showing someone preparing a sandwich for a co-worker while chatting with another person. They talk about the fact that their friend is in "crunch time," preparing for the roll out of some new e-commerce system in a day or two. They then deliver the sandwich by flattening it and passing it to their "crunched" co-worker under his door.

I'm not sure what kind of message this company was trying to send with this ad (I think they mention something about commitment to their customers), but I got a couple different, less flattering messages from it. What I got from it was that they either were ineffective in managing and delivering projects in a timely manner without last minute heroics, or that they didn't care a lot about the satisfaction of their employees by depending on those heroics.

I've come across this sort of thing personally a number of times. I once did a presentation on Critical Chain Scheduling and Buffer Management to a bunch of folks in a software/hardware development environment. There have been units in this organization that have been known to require mandatory 7-day weeks and mandatory 10-hour (minimum) days of everybody to accomplish projects. I have heard an executive in another unit of this organization say that he expects his people to be "sprinting" all the time.

These comments usually come as a response to my suggestion that task estimates be predicated on performing work with a full level of focused effort that can be maintained as a sustainable pace, stressing that unending long hours are not sustainable.

The new comment that came out of the group I spoke to this time was "The profits of our XYZ Company come out of the unpaid overtime of our developers and engineers." That was surely an exaggeration, given the prices they get for their products, but the pressures on people to kill themselves to minimize the amount of scope cut or overshoot of promised due dates (they had seemingly long ago given up on expecting to meet such commitments) certainly made it feel to the folks in the trenches that it was coming out of their hides.

My response to the comment about the profits was two-pronged.

First I pointed out the view that for an organization to succeed, it has to satisfy at least three specific necessary conditions (that coincidentally, relate directly to the three basic categories of stake holders of an organization).

  1. It must make more money (for the owners) now and in the future.
  2. It must satisfy customers (and solve their problems) more now and in the future.
  3. It must provide a more satisfying and secure workplace for its employees now and in the future.

Usually one of these becomes the primary goal for the organization, but for long term success, the satisfaction of the other two must not compromised. If you let down a customer in the now, they probably won't help you make money in the future. If you burn out your employees now, they will respond by either subtle or not-so-subtle means that will require you to spend more money to keep them happy or to replace them in the future. A burnt-out work force won't be able to provide the extra "oomph" necessary to take advantage of a new opportunity or to satisfy an important customer.

That makes sense in the long run. But there is also an aspect related to projects in the short run that weighs in against the growing expectation of long hours in such environments as software development.

What is needed to do work?

Capacity.

If projects are structured (or if people are mis-managed) to rely on long hours to complete their appointed tasks, then there is no protective capacity in the system. If the organization carries out a downsizing every time it identifies some unused capacity sitting around, the result is a very heavily loaded remaining work force. Unavailable capacity is required to take on new initiatives as they arise.

The Theory of Constraints uses a logical communication tool known as an NBR (Negative Branch Reservations) as the cause-and-effect, if-then description of why something doesn't sound like such a good idea. Let's use it to examine this situation (the numbers help to keep track of statements that have been introduced earlier in the logic) . . .

If (10) it is a necessary condition for success to make more money now and in the future,

and if (20) controlling costs is a primary focus of management,

and if (30) unused capacity is equated with wasted cost,

then (40) the organization strives to eliminate unused capacity

 

If (40) the organization strives to eliminate unused capacity,

and if (50) there is often little consideration given to capacity when taking on new projects

then (100) often existing resources (capacity) are run at 100%+ -- full out.

 

If (100) resources are running full out,

then (200) there is no reserve.

 

If (250) projects tend to fall behind at some point in their life,

and (280) catching up when behind requires energy and effort,

and (200) there is no reserve,

then (300) you can't catch up when you fall behind.

 

If (300) you can't catch up,

then (400) you'll disappoint a customer who is waiting for your output.

 

If (400) you disappoint customers,

then (500) you'll lose money at the top line.

 

Also...

 

If (100) often existing resources (people) are run at 100+ -- full out,

then (600) you'll burn out your employees.

 

If (600) you burn out your employees,

and if (700) burnt out employees suffer from low morale.

and if (800) employees with low morale are prone to find other employment.

then (900) you'll lose employees.

 

If (900), you lose employees,

and if (200) there is no reserve,

then again, (300) more and more you can't catch up

(notice the self-reinforcing loop, perpetuating the undesirable situation)

 

Also...

 

If (900) you lose employees,

and if (200) there is no reserve,

then (1000) employees must be replaced.

 

If (1000) employees must be replaced

and (1100) employee recruitment, acquisition and training are expensive

then (1200) you lose money to employee costs

 

Also...

 

If (600) you burn out your employees,

and if (700) burnt out employees suffer from low morale.

and if (850) burnt out employees with low morale are prone to error.

then (950) project efforts are more subject to error.

 

If (950) project efforts are more subject to error,

and if (1050) project errors must be fixed,

and if (1150) fixes require rework from current resources,

and if (200) there is no reserve (for rework),

then (250), projects tend to fall more and more behind.

(another devastating spiral of death)

 

Also...

 

If (950) project efforts are more subject to error,

and if (1050) project error must be fixed,

and if (1150) fixes require rework from current resources

then (1250) you lose capacity/resources/money to rework.

 

So...

 

If (10) it is a necessary condition for success to make more money,

and if (500) you lose money at the top line,

and if (1200) you lose money to employee costs,

and if (1250) you lose capacity/resources/money to rework,

then (1300) success is in jeopardy, to say the least.

 

There seems to be a penny-wise-pound-foolish story buried in the ridiculous overwhelming focus on costs (to the detriment of throughput and capacity) that is at the root of this situation.

This calls into question whether statement (30) -- unused capacity is equated with wasted cost -- is really valid?

Protective capacity is required to allow a project to recover from a setback. Projects are, by nature, uncertain. Things go wrong. Unexpected things happen. If project commitments are to mean anything, the system/organization/project must have, as one arrow in its quiver, sufficient capability/capacity to occasionally sprint to bring the project plan back into line. The system may need the reserve provided by having a few extra people on the rolls. The system also needs the reserve that is inherent in the use of overtime and weekends. Working long is only appropriate when the situation truly demands it.

So if one sees only wasted cost in unused capacity, the possible reaction of trimming it can do more damage than keeping it around for when it is needed to keep project promises. Part of the root of the undesirable scenario (statement 30) is based on an invalid view of unused capacity as a wasted cost. (Chapter 11 of Eli Goldratt's book, Critical Chain, has more to say about this.)

Another question that arises is around statement 50 -- "there is often little consideration given to capacity when taking on new projects." Why do so many project organizations take on so much work that it jeopardizes their ability to deliver them effectively?

Part of this pressure stems from the attitude of needing to keep resources busy all the time, which we've already called into question. And part of this pressure to have too many active projects at any point in time comes from another belief that could be called into question -- "the sooner you start a project, the sooner it will finish," so launch as much as you can. This may be valid for single projects, but in the typical multi-project environment, the interaction of multiple priorities muddies the water for project resources and typically results in behaviors that eat capacity without providing positive results. (See "The Sooner You Start, The Later You Finish")

These two statements are at the root of the cause-and-effect scenario described above. One points up the need to manage resources in a way that assure sufficient protective capacity so that organizational throughput is not jeopardized. The other requires a process to manage resources and workload in a way that minimizes the unnecessary wasting of capacity in the way work is managed and performed. These are not mutually exclusive objectives. They are the reason for and the basis of TOC Multi-Project Management.

Effective multi-project management requires the stagger of projects in a way that does not put strains on the resources available to the organization but yet maximizes organizational throughput. The synchronization schedule of the TOC Multi-Project Management process provides the mechanism to do just this. By having fewer active projects at any point in time, resources can address their focus to what is important to meet commitment in an effective manner. Fewer active projects result in a faster and more reliable stream of completed projects in this way. A faster stream of projects results in more project complete in a given timeframe. So fewer projects result in more projects for the organization - more throughput - more profits, and at the same time provide more satisfaction and quality of work life for its employees.

Never confuse movement with action. - Ernest Hemingway

Discuss Critical Chain - An email-based discussion group

Frequently Asked Questions about Critical Chain-based project Management

Top 10 Sources of Project Failure -- A list you probably won't see on Letterman.


Related links:

Check Out the Following Links for More About the TOC Approach to Project Management:

Critical Chain and Risk Management - Protecting Project Value from Uncertainty -- Project management is the practice of turning uncertain events into certain promises. If so, then project management is an extended excersie in risk management. The core concepts underlying Critical Chain-based project management directly support risk management and are described in this paper, expanded from one presented at PMI's 2001 National Symposium.

Getting Out From Between Parkinson's Rock and Murphy's Hard Place -- This first link will bring up a paper based on a poster presentation originally given at the 1998 New Jersey PMI Chapter's annual symposium, honored with a "best of the show" award by attendees, and later turned into an article published in PMI's PM Network magazine.

Program Management -- Turning Many Projects into Few Priorities with TOC -- This link will lead to a paper on the key attributes of a TOC Multi-Project Management environment. (Most projects are performed by resources shared with other projects. It can be deadly to ignore the resulting interactions, no matter how well you manage single projects.) This paper was originally presented at PMI's Global Symposium in Philadelphia in October of 1999 and is included in the proceedings of that conference. Audio tapes of the presentation are also available from PMI.

Project Portfolio Management - The First Cut is the Kindest Cut - One of the common problems faced by project-oriented organizations is having too many projects relative to their capacity. Therefore, one of the first things that needs to be done is to determine what can be done is to determine what should be done . . . and what should not be done . . .


Critical Chain Basics

A Critical Chain Schedule

The Sooner You Start, The Later You Finish

Multitasking Multiplies Lead Time

Who is FP?
Web Log
You can reach Focused Performance at:
601 Route 206, Suite 26-451, Hillsborough, NJ 08844
Voice: 908-874-8664
Contact Focused Performance