Grow or die

The title is a rough quotation from an interview I read by a CEO recently. It doesn't matter who it was; it's a common business notion, I sense.

I understand the sentiment, really I do. There is a real fear that, if we don't grow, we'll be overtaken by those who do grow. Or that we'll become stagnant and stale.

Yet I'm mindful that, if we all grow, we'll surely die (or at least suffer), too. Read Limits to Growth, if you're uncertain about my statement. Note that "limits to growth" in that book is not a statement of an environmentalist's hope; it's a statement of fact. We will face limits to growth. We can choose the nature of those limits (or at least we have had the chance), but stop growing we will. You can't exceed the carrying capacity of an environment forever.

So, if it's true that we all (or most all) want to grow (our companies, our houses, ...), and if it's true that we will face (and are already facing) real limits to that growth, what do we do?

I've written about growth a number of times, but I admit that I don't have all or even many of the answers yet. Perhaps I'll find out more in the next few months, for I'm co-teaching a systems thinking course at Bainbridge Graduate Institute.

If you're not familiar with BGI yet, their vision is "To infuse environmentally and socially responsible business innovation into general business practice by transforming business education," and they've got a good reputation in this area.

As I did when I taught system dynamics at the University of Washington, I suspect I'll learn a lot here, this time with a distinct focus on sustainability and business. I'm really looking forward to this experience. (And, as I did last time, I will refrain from telling you anything that goes on in class unless I have explicit permission, but I may tell you a bit about how I grew.)

Management theory, management practice

For some now-forgotten reason, I printed out a copy of Sumantra Ghoshal's Bad Management Theories Are Destroying Good Management Practice some time ago to read. Last night, I discovered it and took the time to read it.

If you are a manager or a management educator, I encourage you to do the same. It's not something to force yourself to read today, for it likely won't tell you anything you need to do a better job on your current project. It is something to read and not ignore. It will, I hope, make all of us think.

Here's an example of his ideas (pp. 79-80). It's often said that the job of a public company is to make the maximum profit for the owners. As he notes, stockholders don't really own a corporation; they simply contribute capital in exchange for a share of certain cash flows. Employees contribute their work in exchange for their livelihood. If we were to maximize the gains of a corporation to benefit those who have invested a stake in its success, we would have to focus those gains in service of a much wider group of people. Employees would seem to have a much bigger influence than stockholders, for they typically can't change jobs nearly as easily as stockholders can buy and sell stock, and their contributions are typically much more individualized than the fungible resources stockholders provide (cash).

For another, he claims that much management theory (and thus practice) today is based on an assumption that people will try to take advantage of companies (pp. 82 ff.). Yet, he claims, experiments and evidence shows that such a belief is incorrect and tends to create a self-fulfilling prophecy (which makes me glad to have been part of the company Bill and Dave founded).

His concerns focus on two areas. First, management theories have focused (out of "physics envy") on "a narrow version of positivism together with relatively unsophisticated scientific methods" (p. 86). Second, for ideological reasons, management theory has focused efforts on "containing the costs of human imperfections" rather than on working with the broader, more complex, true nature of people.

The challenge in management sciences lies in what he calls a "double hermeneutic" (p. 77). While bad theories in physics don't change the path of electrons (they can't read, and, if they could, they wouldn't change simply because elite scientists said they should), bad theories in the social sciences (of which management is one) are read by practitioners and turned into practice.

Finally, he notes (pp. 86 ff.) that falsification, which is fundamental to to the positivism to which some aspire, is very hard to apply in the social sciences. As "many different and mutually inconsistent theories explain the same phenomenon ... nothing can be weeded out."

He has explained his ideas much more effectively than I have in this brief summary, and I do encourage you to read it and consider how it might apply to your practice of management. If you deal in any of the social sciences, I also encourage you to think about the nature of falsification as he describes it and how that applies to how one knows what one knows.

Focusing on the symptom or the cure?

I recently read Jay Forrester's "Churches at the Transition Between Growth and World Equilibrium," a paper prepared for the National Council of Churches and published as part of Toward Global Equilibrium: Collected Papers, ed. Meadows and Meadows and published in 1973 (also available from Pegasus Communications).

Forrester emphasized two points that may be worthwhile today to some of you reading this:

• When fundamental changes happen in the environment in which we operate, old rules of thumb likely no longer appply.
  
• Trying to fix problems by focusing on symptoms is highly risky, for, even in static times, our intuitions don't always work as well as we need. In times of transition and turbulence, it's especially important to ensure one understands the dynamic causes of the problem being faced before engaging in actions that could be counterproductive.
  

Forrester was a bit more direct than I was in my paraphrase. "One should never attempt to find a solution without first establishing the dynamic causes," he wrote, and system dynamics was his tool of choice for testing whether one had found the underlying causes or not.

Today we face increasing energy costs, increasing population density, increasing effects on climate and on the inhabitants of the Earth from the by-products of our industrial and private activity, fundamental shifts in the distribution of production and wealth, a scarcity of resources that were abundant in the past, and the fall-out from overextended financial markets. No matter your type of organization, the complexity of these changes taxes our understanding.

In a time of such changes, how do you make sense of the challenges your organization faces? How do you determine which actions to take to achieve the sustainable successes you want?

If you'd like to discuss ways in which you might make more sense of those issues, ways you might understand the likely causes of the dynamics you face, and ways you might test your proposed actions faster and at less risk than by just trying them, get in touch. Perhaps I can be of help as you seek to fix problems and not just reduce symptoms. Of course, there's no charge or obligation from such an initial discussion.

One way to lose focus

Losing focus can be so easy. I understand. When I was growing up, I used to play the horn and didn't stop until I was well into my twenties. When I focused on making music, I really enjoyed it, but, if I ever paid attention to the presence of an audience or the state of my performance, I would get lost in a mild case of the nerves. Professionals know how to deal with such things; I was not a professional musician.

In Unschlüssigkeit bei Toyota?, Paul Bayer wonders about Toyota's president Katsuaki Watanabe's recent speech at the Detroit auto show. He translates part of Chet Richards' Ford: Faint signs of life, in which Richards wonders if that's a sign that Toyota has taken its focus away from making the best cars to being the biggest company.

My purpose here is not to criticize (or even analyze) Toyota (or Ford or any other company); as Bayer notes, there are other explanations for Watanabe-san's speech that don't bode ill for Toyota. My purpose is to use those comments to note how easy it is to shift one's focus from that which brought success to the trappings of that success and the risk that such a shift might destroy both the success and its trappings.

How to get ahead

"I love a challenge!" Those are the words of a young boy quoted by Dr. Carol Dweck, the Lewis and Virginia Eaton Professor of Psychology at Stanford University, words typical of the mindset that, according to her research, helps people achieve more, a mindset, she claims, we can learn and we can teach.

I found Attribution theory and Shreddies today, that led me to Guy Kawasaki's "The Effort Effect", which led me to The Effort Effect and to an interview with Dweck at Tech Nation. A bit more Googling turned up How Not to Talk to Your Kids.

If you manage people, if you teach students, if you raise children, or if you have responsibility for your own contribution and results (there: that should cover everyone who reads this!), read and consider her ideas. If her research is good (and, while it seems to be, I do encourage skepticism as part of learning), consider how you can apply her ideas in your work and life.

A problem in policy or implementation?

There's a discussion about different approaches to solving organizational problems on a mailing list to which I belong. I posted the following follow-up:

Problems in policy implementation may be due to problems in policy design.

(In this context, a policy is a set of rules or guidelines by which we make decisions. )

While it's taken totally out of context here, I think it's very consistent with Deming's ideas, with the lesson that problems in the user manual for a product may really be a problem with the design of a product, with what I've learned as a manager leading change, and with what I've observed as a consultant: if you get the "system" designed well, the implementation may well become significantly more straightforward.

So if you're not getting the results you want out of your organization and if you're tempted to think the problem lies in the people implementing your policies, think again, just to be sure. It's possible that the problem lies in your policies.

That's actually good news, for it means the problem lies in an area you really do control, one where you really can make meaningful, effective changes.

What do you think?

High-performance organizations

Do you want your organization to perform dramatically better than it does today? What's holding it back? What's holding you back?

Ralph Sink has an idea, based in his experience, and he describes it in My Unfashionable Legacy in strategy+business. I've led that sort of organization before, and I found it amazing what such an approach can accomplish.

Thanks to Fred Nickols for bringing this to my attention via the ODnet mailing list.

Testing the speed limits

In the Fall 1990 Sloan Management Review, Christoph-Friedrich von Braun published "The Acceleration Trap," calling into question our focus on shorter time to market. He later published the related The Innovation War (Prentice-Hall International Series in Industrial and Systems Engineering) (a book still on my reading list).

Tom Peters blogged about it (briefly). Brice Dattée and Dr. David FitzPatrick published The Acceleration Engine: Pattern of Technological Development, a mathematical exploration of the topic from a slightly different perspective. Barry L. Bayus of the University of North Carolina at Chapel Hill wrote an interesting review of his book. Eugene Garfield wrote another review. Alexander Kandybin and Martin Kihn quoted von Braun's work in The Innovator's Prescription: Raising Your Return on Innovation Investment in strategy+business.

His words haven't been accepted universally, as anyone in a wide range of industries may attest to once they leave work at 9 or 10 in the evening. On the more literate side, Preston Smith wrote From Experience: Reaping Benefit from Speed to Market. It was the subject of a debate (Die Innovationsfalle) at the 2001 CeBIT.

If von Braun is right, there's another risk to growth besides running out of natural physical resources: there's running out of time. It's analogous to an addiction: we need to keep getting more and more of the substance in question (reducing time to market, in this case) to remain satisfied. If we can't maintain our "supply," we crash and go into withdrawal.

In this case, the risk von Braun pointed out was the limit to how short one can make product cycle times and the risks to any financial success that's built on steadily decreasing time to market. Perhaps we can eventually cycle through product generations faster than our customers will accept them (do you want to replace the computer you bought yesterday with a new generation today and then do it again tomorrow?). Perhaps we'll begin to hit physical limits to speed (zero time to market would seem to be a very hard limit to exceed). If we try to break through that limit, whatever it is, and fail, we lose the business benefits we've been sustaining based on constantly improving time to market in the past.

I'm sure many of us are tempted to say, "We don't know if there's a limit or not; we should push forward as hard as we can, and we'll let the real world tell us if there are limits." Unfortunately, if von Braun is correct, hitting those limits won't mean a leveling off; it will mean a crash, and that could have a ripple effect that none of us will enjoy.

Does this mean I'm against reducing time to market or cycle time in general? No. There are many places in our organizations where reducing delays can help, likely including the delay from a customer perceiving a real problem to being able to obtain a product or service to address that problem. Without thought and testing, though, it's hard to make generalizations.

I perceive that time to market reduction is like growth: neither serves as an eternal, prime goal, but each may have its place in at the right time and in the right situation. I do encourage you to do your own reading, think about it, and draw your own conclusions.

How do you know if it's the right time and situation for you? If you'd like to explore ways to discern whether now is such a time and this is such a situation for your organization and how you might create policies that further your goals, let's talk.

Leadership and systems thinking

Colonel George E. Reed, director of command and leadership studies at the United States Army Way College in Carlisle, Pennsylvania, has some interesting things to say about leadership and systems thinking in his article by that name.

His ideas seem related to many of my posts on systems thinking as well as my post on the lazy employee.

Thanks to the Curious Cat Management Improvement Blog and the Ackoff Center Weblog for the pointers.

Finding a consultant - remotely

In less than a month, Facilitated Systems will have been in business for eight years. I've worked with people in Asia-Pacific, Europe, and the Americas, and yet I've rarely seen a client, for I work mostly from my office.

In today's world, that has distinct advantages. For those of you not used to working remotely with a consultant, I'll list a few:

Responsiveness

If I came to your site to work, I'd likely save up tasks until I had half a day, a full day, or perhaps several days of work at once (depending upon how far away you are), because it's more economical. That's a delay for you.

If I work remotely, you can get my attention in the size chunks you need: minutes, hours, days, weeks, or months. The delay from asking a question to getting an answer drops; if I'm available when you call, you'll start getting help immediately. If you do have to wait, the wait will likely be shorter.

Speed

You can get my help now, without waiting for me to fly, drive, or take a train. If I'm working on someone else's tasks, you need to wait for me to finish those. That's where responsiveness kicks in: if it's appropriate, you may well get some of my time starting today, rather than having to wait until I have full days available.

Lean

If I'm traveling, I'm not working for you. Sure, I try to work on planes when I can, but there is much to the travel experience that represents pure muda. Moving me to you is the essence of transportation and waiting waste.

Cost

If there's no travel, you don't pay for travel. Simple.

Carbon friendly

If I'm not traveling, I'm not generating as much CO₂.

Petroleum friendly

If I'm not traveling, I'm using less petroleum.

Congestion friendly

If I'm not traveling, I don't add to traffic congestion.

Resources

If you need a team, assembling a remote, distributed team from my contacts world-wide to help you brings all these benefits in spades.

How did I discover this? You folks taught me. When I started out, I expected to spend significant time in a car or on a plane, even as I expected to do some of my work remotely using the phone, email, and other online tools. With rare exceptions, you who hired me were quite happy to have me sit here and work there. As times have changed over the last eight years, your insights seem wisely prescient.

Some tasks do require a consultant at your site. I've done that, I will do it again, and I do enjoy working together with you in person. So call if you think that's what you need.

I have also discovered that it's possible to share ideas, build trust, work on problems, and make a joint contribution without being there in person. If that's what you seek, call me, too.

Which serves you best?

A manager's job

Here's a philosophical question for you on a Friday. What is a manager's job?

Is it to lead a group? To direct people's actions? To manage and control the progress of an organization? To make decisions? To solve problems? To follow directions from above?

While all of those may fit in the typical manager's day, I think the foremost responsibility of a manager is to create and manage human and organizational systems that will get the correct things done.

As managers, we have the responsibility to get things done through our organizations (as a one-person company, I'm counting myself as a "manager without portfolio"). If we believe the mantra that events are part of patterns and patterns are caused by structure, then our task is to create the structures that will lead to the sort of patterns and events we seek.

If we focus on individual problems and decisions, we're focusing on events. That will lead us into the perpetual task of trying to address more and more events, and we risk being overwhelmed. We're perpetually pushing against the tendencies of the system that's there.

If we make it our business to create and maintain an organizational system that gets the right work done, we create a "machine" (a system) that gets the work done for us with less effort and fewer problems. That's how I helped an organization reduce its budget variance by 95%, and that's part of what I meant by praising "lazy employees." While you're working on this system, remember that it has business, technical, and people dimensions, which all demand attention!

So if you are a manager, your real role is that of a (human and organizational) systems engineer.

Critical chains: a decade later

I first read Eliyahu Goldratt's Critical Chain : A Business Novel in 1998. I was sufficiently intrigued by the critical chain approach to project management that I summarized my notes for an internal Web page at my company in March 1998. Tom von Alten worked for the same company and also wrote up his thoughts on critical chains; we cross-linked our pages to give people two somewhat differing views of the approach.

It's now almost a decade later, and Tom and I have been discussing project management again. We decided to post slightly edited and reformatted versions of our original pages to let you see what we were thinking back then and to provide a reference for those of you who might want to know more. I've integrated my three pages into one long post so that it's easier to find as a whole.

---

Project Management Revisited: The Theory of Constraints

Eliyahu M. Goldratt's book, Critical Chain, applies the theory of constraints to project management. He implies ~25% improvements in project duration are possible the first time it is applied.

The basic steps

1. Draw the project plan in PERT chart form; make sure each activity has a time estimate. Assign resources to the steps, and shuffle steps in time until no resource conflicts (i.e., two steps needing to be done at the same time by the same resource) occur. Identify the critical chain (the longest chain of dependent steps, including path and resource dependencies).
   
   
2. Cut the time estimates of each step in the critical path in half (this approximates the median step duration). Add a project buffer at the end of the critical path equal to half the time you cut from the critical path.
   
   
3. For each path which feeds into the critical path (so-called feeding paths), cut the times of the individual tasks in half and place a feeding buffer just before that path feeds into the critical path.
   
   
4. When a person or group is a week away from entering the critical path, send them a reminder. Repeat that reminder at 3 days and 1 day prior to their projected entering of the critical path. When the time comes for them to start a step on the critical path, they are expected to drop whatever else they are doing to focus on the critical path step (this provides a resource buffer by ensuring that the critical path won't have to wait for them to come free).
   
   
5. Set up a daily (one colleague suggested that weekly might be more appropriate) metrics collection and reporting program.
   
   
   
   
   • For each step in the critical path, capture the number of days until that step hands off to the next step.
     
     
   • If that number increases by x, remove x days from the project buffer. If it decreases by x, add x days to the project buffer.
     
     
   • Do the same things for each feeding path.
     
     
   • Report those numbers daily (weekly), prioritized by those steps which are decreasing the project buffer and then by those which are decreasing a feeding buffer.
     
   
   

This cuts ~25% off the current plan without a change in work content or resources. Future improvements are possible and expected; see the next section for more details.

The five steps of the theory of constraints

These steps restate the above process with more focus on TOC terminology. Any book or paper on the theory of constraints will reference these five steps using Goldratt's unique terminology.

1. Identify the system's constraint.
   
   For project management, the constraint is, to a first order approximation, the critical path from the PERT chart. By incorporating resource needs, one arrives at the critical chain, the precise constraint.
   
   
2. Decide how to exploit the system's constraint.
   
   Make sure it stays busy. First, remove time buffers from the individual steps by using 50%, not 80% or 90%, confidence values for expected durations. Cutting traditionally estimated times in half is the suggested heuristic.
   
   Next, install feeding buffers to ensure lateness in a non-critical chain step won't impact the critical chain and resource buffers to ensure that resources are available when their contribution is needed to the critical chain. The suggested length of such a resource buffer is half the amount that was removed from the path it's protecting, thus giving a 25% savings on each feeding path.
   
   Finally, because there is variation (uncertainty) in the estimates for the durations of critical chain steps, install a single project buffer at the end of the project to buffer the scheduled completion date (and the customer) from that uncertainty. Use the same algorithm as for feeding buffers, giving a 25% savings on the overall project duration.
   
   
3. Subordinate everything else to the above decision.
   
   Don't work on something just because you think you have to keep busy or be more efficient or productive. Ensure you have excess capacity in all the feeding paths to keep the constraint (the critical chain) busy and to catch up from any delays in the feeding path steps.
   
   
4. Elevate the system's constraint.
   
   Increase its capacity. Add resources in ways that shorten the critical chain; improve processes along the critical chain.
   
   
5. Repeat the process.
   
   If the constraint has been elevated successfully, it may very well no longer be the real constraint. When the constraint has been elevated, re-assess the current critical chain, which may lead to repositioning and redimensioning buffers.
   

A change in work philosophy

In the traditional way of managing projects, people are expected to stay busy, and departments are expected to avoid wasting money by eliminating excess capacity. This presumes that having uniformly busy people contributes directly to faster project completion and better business results.

The TOC approach calls for a focus on the system's constraint (the critical chain). The parts of the organization on the critical chain should be running at capacity.

The difference is how one treats work off the critical chain. Those areas should be running explicitly at less than full capacity, because they need reserve capacity to make up for the unavoidable slips which occur due to activations of Murphy's Law.

A change in metrics

The fundamental changes are to stop measuring what percentage of the total work is done, how busy everyone is (area capacity utilizations), and when individual steps should be and are completed.

The fundamental and perhaps only measure becomes how much of the various buffers (project buffer first, then feeder buffers) remains. Changes which reduce those buffers are warning signs; changes which increase them increase the likelihood of completing the project by the scheduled date.

Assumptions

I have listed the assumptions which seem to underlie the critical chain approach to project management here for people to attempt to disconfirm them. Lack of success at such disconfirmation attempts would seem to indicate strength in this approach. I've tried to list them as major points with underlying corollaries capable of being derived from those major points.

• Traditional business philosophy says improving any parts of the whole provides equivalent benefits to the whole; in reality, a very few parts have an overwhelming contribution to the performance of the whole (much more concentrated even than the "80-20" rule).
  
  
  
  
  
  • Monitoring the percentage of work completed causes a focus on tasks which works against on-time completion of the project.
    
    
  • Focusing on ensuring that each step completes on time will not ensure the project completes on time.
    
    
    
  • You don't protect the integrity of the project schedule by protecting the integrity of the schedule of each step (by adding safety factors at each step); you must protect the goal of the project schedule by putting in safety factors (time buffers) just in front of the customer (at the end of the project) and just in front of the project's constraint (the critical chain) (i.e., putting feeding buffers where any path in the PERT feeds into the critical chain or where any resource constrain threatens the critical chain).
    
    
  
  
  
• There is excess time in most project schedules (analogous to excess inventory on most production floors) which can be removed by proper focus.
  
  
  
  
  • We inflate our normal task (step) estimates to
    
    
    
    • account for interruptions and multi-tasking, and to
      
    • give ourselves an 80% or 90% chance of completing the task on time.
      
      
      
      
      
      • Given the skewed right nature of the probability distribution of most task duration estimates, this easily translates into about a 200% inflation in time when compared to the median of the distribution.
        
        
      
      
      
    
    
    
  • We often waste safety buffers we give ourselves by
    
    
    
    
    • not starting a task until any such buffer has gone by (procrastination),
      
      
      
      
      • Since we don't know until we're well into a task whether there are unfortunate surprises ahead, by waiting to the last minute to start, any surprises we find affect the completion date directly.
        
      
      
      
    • trying to do multiple tasks simultaneously (multi-tasking), and
      
      
    • allowing dependencies between tasks to accumulate delays and waste advances.
      
    
    
    
  
  
  
  
• Local efficiencies and productivities don't count.
  
  
  
  
  
  • People don't have to stay busy all the time.
    
    
  • People shouldn't stay busy all the time, because then you don't have the excess capacity you need to protect the system constraint.
    
    
    
    
    
    • If you don't protect the system constraint (in project management, the critical chain), your overall goal will suffer, even if your metrics at individual steps appear in order.
      
      
      
      
      • Measuring individual steps, unless they are a part of the constraint, is likely to lead you to do exactly the wrong thing.
        
      
      
      
    • There is a new work philosophy:
      
      
      
      
      • If it's too early to start a step (on the PERT chart), do nothing.
        
      • If it's not too early, work as fast as possible on that step.
        
        
        
        
        • By having removed the safety from each step, you have nominally only a 50% chance of completing the step on time.
          
          
        
        
      
      
      
    
    
  
  
  
• Conflicts are a clear indication that someone has made a faulty assumption and not a signal to compromise. (This is a lesson Goldratt claims to have taken from the scientific world into the business and sociological world.)
  
  
  

To find out more

The original article listed several references. I've already listed Critical Chain and some of the others elsewhere. I once pointed to a Robert Newbold article I can no longer find, but there is a long list of papers he and others have written on the subject.

For Tom Tom von Alten's insights on the critical chain approach, see his book review of Critical Chain, which includes snippets of PERT charts showing this more graphically.

---

That's what I thought almost a decade ago, and you can find out what Tom thought back then, too.

I'm curious: have any of you tried critical chains in your organizations? What have you learned?

What moves us forward?

What moves us forward? According to a recent article in the NY Times, The Unsung Heroes Who Move Products Forward, it's the creation of innovative processes and infrastructure.

Thanks to the TP! Wire Service for the tip.

Project management revisited

I've written about project management before multiple times. A new tool has become available, and so I thought it time to provide an update.

Project management was part of my professional life as an engineer from the start. My first manager took a course in Netzplantechnik and had me manage my design project using a paper PERT chart. At my second company, mainframe computers produced PERT data in tabular format, which I found far less user-friendly but certainly more voluminous. At my third company, I discovered and used MacProject, one of the friendlier and more intuitive project management programs I have seen.

Yet my third company also introduced me to process management and continuous process improvement. I started in manufacturing engineering and heard many a statement about improvement being continuous, having no end. I saw and participated in the great strides such approaches could make, even as we did run specific projects to accomplish specific objectives.

When I returned to a product development organization as R&D productivity manager, I struggled with what I saw as a project vs. process dilemma: projects seemed to be closed systems on far too many levels to be the unifying organizational approach. While certainly highly useful, they didn't seem to capture the reality of the world nor enable the strides I had seen a process focus capture. My manager was patient, reminding me of the business advantages of a project orientation that focused on achieving a specific goal with specified resources over a specific time frame.

With a few more years to reflect on the process vs. project issue, I now see the ideal as both-and, not either-or. To manage a business, there are many times when we are best served by dedicating fixed amounts of resources and schedule to achieving defined goals, and those call for projects and project management. Yet, to be competitive and to make a sustainable contribution requires a steady focus on getting better, a focus that isn't limited by a project release (or completion) date. I discovered an early statement of the idea of blending a project and a process focus in Experiences with Defect Prevention in the IBM Systems Journal from 1990, and I applied their notion of an action team to a project that reduced the prototyping time of printed circuit assemblies by 83% ("Emphasis on Business, Technology, and People Cuts Turnaround Time at Hewlett-Packard's Lake Stevens Division," National Productivity Review, Winter 1998-99).

I've updated the Project Management section of my Links page for new software that has become available. While GanttProject and TeXProject are still useful (TeXProject more for those who use LaTeX regularly), there's a newcomer to the scene: OpenProj™ by Projity. Some see that as a possible adjunct to OpenOffice.org; others see it as a tool that works with Microsoft Project files.

There are other solutions, especially for online collaboration. eProject offers a well-known commercial solution, and Projity offers its Project-ON-Demand™ SaaS. PHProjekt is a free alternative.

Whatever tools you pick, it's most important to think. As I related in the first links above, paper and pen with good project management approaches can work quite well; complex tools with poor approaches may get you nowhere (of course, complex tools may be necessary to manage the complexity of large projects). Certainly get the basics of project management down, but keep an eye out for new ideas such as critical chain theory (a decade old now) which may help you do better, and integrate project and process approaches in ways that serve your organization well.

Incidentally, chapter 11 of the novel Critical Chain by Eliyahu Goldratt is available online.

Scenario planning

Scenario planning is a business process we got largely from Royal Dutch Shell. If you just read The Art of the Long View: Planning for the Future in an Uncertain World, you should know things haven't stood still. Martin Börjesson has a very good reference site worth checking out.

If there's one thing I've learned about scenario planning, it's that it's a literary and creative process, not a mechanistic one. Those scenarios that offer the most value, that help me think the most, are also those that qualify as true stories, not as mechanical selections of various events.

Do you manage people who program?

Do you manage programmers or software engineers, people who write code for a living? If you do, check out Paul Graham's Holding a Program in One's Head. It explains the importance of getting a program into a programmer's working memory ("head") and the damage to results and productivity that can be created by distractions. I think the same applies to certain other fields, too. I know that modeling and simulation work quite resembles programming in that regard; perhaps you can list other fields where it takes significant time to get all the pertinent information into our heads before we start real work.

As an aside, Graham recommends succinct languages for more powerful results. J is one language that's quite succinct and quite powerful. It's easy for many of us to use as aids in our current work; that's why I recommend it for managers and knowledge workers, not because we're dense but because our primary contribution isn't programming, and I find J augments my capability without making me a programmer. I also recommend J for serious programming work, for I've seen what true J experts can do, and it's both impressive and leverageable.

Management style

Recently I discovered A love affair with micro-management,
courtesy of the TP! Wire Service. That led to The ins and outs of corporate control and Why Companies Love Micromanagers. The basic premise is the same: managers are increasingly hiring micromanagers, and that is hurting their companies.

Then, this morning, I read Dear Boss: You're a jerk; see you in court, an Associated Press article about states giving workers the rights to sue their superiors for creating abusive work environments. Perhaps you've seen that in your news, too.

Years ago, there was emphasis on theory X, theory Y, and, eventually, theory Z as ways to manage. Theory X was seen as the way to get poorer results, but these news stories seem to be saying it's making a comeback.

I'm curious: do you see this trend in your organizations? If you're a manager, what's your approach to management? Why did you pick it? How is it working for you, your organization, and the people who report to you?

If you're managed by others (that should be most everyone), which approach is used by those you report to? Why did they pick it? How is it working for you, your organization, and those to whom you report?

For each case (many of you are, no doubt, in both situations at once), would adjustments to the current style be an improvement or not? If so, is there anything keeping you from experimenting with a change?

Rehearsing

I often help people with presentations, and I've noticed that those who rehearse seem to be those who do better. Now Garr Reynolds of Presentation Zen has done an excellent job of explaining the creative process of presenting ideas to others in his Steve Jobs and the art of the swordsman.

Note the two keys to presentation success:

• Intense rehearsal in a team setting
  
• Absolutely no attention to technique or form in the actual presentation
  

Reread Garr's comments, if you need to, and note comments such as, "...once we allow our mind to drift to thoughts of success and failure or of outcomes and technique while performing our art we have at that moment begun our sure decent." [sic]

How can we possibly get through a presentation while following the second key? By following the first key until we have internalized what we want to say, how we want to say it, how others will hear it and respond, and what we can do if something goes differently than we expect. Then we have to rehearse it some more.

As someone once noted, we often rehearse something until we get it right. That means we may have done it wrong 20 times and right once; which do you think will stick with us better?

I think the same thing applies in other areas of our professional lives, and I think Dietrich Dörner and Harald Schaub might agree. That's why I wrote A somewhat unified view of decision making: to suggest the importance of spending time wrestling with what we do at a time that's apart from the actual doing. Whether we use computer simulation, scenario planning, role playing, or something else, the opportunity to rehearse what we do professionally before we do it and to learn from what we actually do afterwards to improve for next time is exceedingly valuable. And it's the cyclic action learning that helps us improve and helps keep us from getting fixated on a bad idea.

If you're still thinking of presentations, check out Garr's presentation tips.

Is innovation overrated?

Innovation builds strong business. I think most would agree with that statement. It's just the old "The early bird catches the worm," which many of us have heard since we were small, recast in professional words.

Most, except perhaps Utz Schäffer and Manuela Stoll, the authors of the study reported by manager magazin in Innovation lohnt sich nur selten (Innovation is only seldom worthwhile). Schäffer and Stoll, of the European Business School, discovered no statistical relationship between a company trying to structure the market in which it operated (innovation) and business success, while 43% of business success could be statistically attributed to adaptation to the market.

While I haven't read it, Stoll appears to have presented her results in Success in Changing Environments.

Thoughts?

Perceptions count

One of the features of many system dynamics models created to make sense of complex situations is the differentiation between the real thing and the perception of the real thing. We people don't often react to reality; we react to what we perceive as reality. That perception typically comes with some distortion and after some delay. To understand the system that created a problem we now face, we need to attend to those perceptions as well as to that reality.

Now there is Wharton's Out of Stock? It Might Be Your Employee Payroll -- Not Your Supply Chain -- That's to Blame which gives an example of how this works in retail. You can download the research paper by Marshall L. Fisher, Jayanth Krishnan, and Serguei Netessine, too.

Thanks to the TP! Wire Service for this lead.

Thinking about large

Chris Nel has an interesting essay on the tompeters! Dispatches From the New World of Work blog called Purpose beyond Profit.

Whether your organization is large or small, I encourage you to read this and take some time to think about it.

I sense some sort of connection to my More on growth from a year ago, although there is a distinct difference.

Project management: free advice, a free tool, and two good books

My first real introduction to project management and network planning (PERT and Gantt charts, for example) came at Kienzle Apparate GmbH in my first real engineering job. Hr. D. Ulbricht, my manager, had me create a PERT chart for the design project assigned to me. I drew it using pen and paper and passed it to him for review. He lengthened a few of the tasks to match his expectation of a realistic schedule and approved it.

He then had me post a copy of the finished PERT chart on the wall next to my desk. Every Monday, he'd review my progress against that PERT chart with me. For the first few weeks, I was right at or a bit ahead of schedule.

Then, one day, it happened: I missed an intermediate task completion deadline. It looked as if I could complete it within the week. In my enthusiasm, I promised I could finish that task before the next Monday and catch up in the future so I could finish on time.

That's when Hr. Ulbricht taught me the lesson that has stuck with me ever since. He said I'd have to slip the entire schedule a week. I had given the best estimate I could, and the only data points he and I had so far was that I was right on or (one time) overly optimistic. Unless I could point to a specific spot later in the schedule and convince him that I had been overly pessimistic there, he had to conclude that the best guess was that each task from then on out would take the originally scheduled time, and so I'd finish one week late.

As a new engineer, eager to please, I was embarrassed, but I did as he said and annotated the PERT chart to show the one week slip. I then met each and every task deadline through the end and completed the project, as predicted, only one week late.

What I learned from that was the importance of each and every deadline in a project schedule. It's not good management to let all the early deadlines slip and hold people to the end date; good management calls for equal attention to early and late critical path deadlines.

That was the free advice. The free tool is Imendio Planner. I first found it on my Linux system and used it for a small project or two. I've now discovered it's also available on Windows and promptly put it to work planning a small project I was working on. It won't do everything, but you may find it useful. It's even got a beta feature that lets it import XML files created by Microsoft Project.

Finally, the books. Years ago, I got a copy of Franz-Josef Heeg's Projektmanagement. I rather like it, for it talks about the range of tasks involved in project management, not just how to create a work breakdown structure and a PERT chart. Of course, you may need to learn German first.

If you're past the basics, you may want to read Eliyahu M. Goldratt's Critical Chain. It's an innovative approach to finishing projects faster, with increased predictability, and without increasing the number of resources applied.

In praise of the lazy employee

Fast Company just published a feature on Extreme Jobs, noting that, while only 17% of managers worked in excess of 60 hours a week in 2004, the 50 to 60 hour workweek had become the norm, and some work more like 90 to 100 hours a week (my peak was in excess of 110 hours, I'm a bit embarrassed to note, and that was well before the current trend). A quick search on Google turned up a number of references, most indicating that having a lazy employee was a problem.

Years ago, I read an article saying that every organization should have at least one lazy employee. No, they weren't advocating hiring and keeping people who didn't want to make a contribution. They were talking about that breed of lazy employee who didn't want to do more work than necessary to get the desired result. They want to think, plan, and then do rather than just doing.

They want to know why it takes five signatures to get something approved when one should do. They want to know why the forecasting effort should take two weeks each month when a bit of rethinking could cut 50% out of the work and possibly get better answers. They want to know why they're tied up in bureaucracy when simplifying work would leave them more time to attend to customers' needs and to come up with creative new ways to make progress for the company. They're lazy enough not to take "We've always done things that way" for an answer; they want to figure out how to do more with less. They want to make more contribution than the 80-hour-a-week employee supposedly does and to do it with far less stress and strain.

If you're fortunate enough to have one of those lazy employees, I suggest you remember:

• They may not always be right, but they're worth listening to; they are on your side.
  
• They may well be the ones who give you the sustained contributions you need and the breakthroughs you dream about.
  
• It might be a good thing if their approach rubs off on others.
  
• If they're contributing in 40 hours what you expect from someone who works 60 hours, don't push them to the 60 hours; they may need time for ideas to percolate.
  
• If you don't have any such lazy employees, why not? What is it costing you?
  

As one demonstrably highly effective manager I knew has said (my paraphrase), "The effective people are those who put in a solid six hours a day working on the right things and then spend another couple of hours listening to people and to ideas; they typically are much more effective than those who work late into the evening."