Top postings of 2007

In the last 12 months (to be precise, from last December 28, the day after the Top postings of 2006 entry through December 26, 2007), you have chosen ten top postings on Making Sense With Facilitated Systems as ranked by unique pageviews in Google Analytics.

As I noted last year, there are potential statistical problems with this list. Those who read my blog every day using the main URL don't get counted; both last year's and this year's tallies were made from those who landed on specific URLs as reported by Google Analytics (but excluding visits I may have made). That may be okay; those who linked to specific pages may have cared more about them. Recent entries have a more difficult hurdle, as they haven't been around as long to be viewed. The dates don't quite line up with the calendar year, although I suspect that makes little difference in the results. If you know of a better way, let me know.

10. For some time now, I've been using an open source simulator for my system dynamics work because it seems to help me think more effectively. That doesn't mean I've given up on commercial tools; I still use iThink for creating interactive environments, and I will be teaching IMT 586 at the University of Washington using Vensim PLE (and I may be using it in professional applications, as well). Last April, I combined my interest in the arts with my interest in this new approach to system dynamics in a public article about marketing program for symphony orchestras. You selected TAFTO 2007, the pointer to that article, as number ten on the list.
    



9. I've written several articles about data and numbers. Making more sense with numbers part 3 offered an easy process to plot data you receive in email or reports.
   



8. The words we use can be vitally important in helping us think productively about key business, organizational, and social challenges. In A systems language for business, number eight on the list, I described one team's evolution towards a better language for discussing business issues, thanks to a course they took from me in system dynamics modeling and simulation.
   



7. Good data helps us ground our thinking in reality. Still more on data, a pointer to several online sources of data, captured the number seven spot.
   



6. Growth can create problems (witness any of the bubbles that have occurred over history), but where are good examples of successful companies that intentionally don't grow? Number four on the list is Small Giants: the American Mittelstand?, pointing to a book that answers that question.
   



5. Sometimes old technology still has utility; sometimes it still attracts interest. At number five, Technology comes full circle, a description of my continuing use of a slide rule in my work, certainly fits that description. For those who are interested, it points to a source for new slide rules.
   



4. When I first started work as an engineer, PERT charts were done using mainframe computers or hand-drawn charts. Today, project management has become a profession with a certification process, and automated tools with graphical user interfaces have long since replaced tables of numbers and dates. Your sixth-most-popular entry was Critical chains: a decade later, my revisiting of Eliyahu Goldratt's critical chain theory that linked to Tom von Alten's revisiting of his views on the approach.
   



3. Productivity is obviously important to you. Your third most popular posting of the year was a surprise to me: If you can say it, it's done, an entry about the array programming language J.
   



2. Barry Richmond has a deserved place as an educator and thinker on system dynamics and systems thinking. I posted a link to an article he wrote about systems thinking and followed up with "Scientific thinking" the modern way, a differing view on the application of modern scientific thinking in system dynamics. That was your second favorite posting from 2007.
   



1. The 2007 posting you viewed the most was the series Making musical sense by email, showcasing a conversation between music critic, composer, author, professor, and consultant Greg Sandow and me that used a system dynamics model to explore the aging of audiences for symphony orchestra concerts in the USA. Now I'm curious: was its popularity because of the topic (music), the approach (a somewhat novel approach to using system dynamics), or the fact it was a real conversation between two people? Let me know.
   

All of those postings were made in 2007. It wouldn't be fair to finish this list without noting that some postings from prior years did rank higher than some of these. Here's the all-time top ten list of postings from Making Sense With Facilitated Systems as measured by your viewings in the last twelve months:

15. TAFTO 2007 (2007)



14. Making more sense with numbers part 3 (2007)
    



13. A systems language for business (2007)
    



12. Still more on data (2007)
    



11. Small Giants: the American Mittelstand? (2007)
    



10. Technology comes full circle (2007)
    



9. System Dynamics for Cheapskates (November 2006)
   



8. Critical chains: a decade later (2007)
   



7. If you can say it, it's done (2007)
   



6. "Scientific thinking" the modern way (2007)
   



5. Making musical sense by email (2007)
   



4. System dynamics with MCSim (November 2006)
   



3. In praise of the lazy employee (April 2005)
   



2. System dynamics and program evaluation (June 2005)
   



1. Making sense with numbers (November 2006)
   

That list includes the top ten postings written in 2007 plus the five entries written in prior years that were at least as popular as the top ten 2007 postings.

As 2007 draws to a close, I want to thank you who read Making Sense With Facilitated Systems and to invite you to continue with me in 2008. If you have suggestions or feedback for this blog, contact me.

I would be honored to be of service to you or your organization in 2008. If you're trying to make sense of tough business or organizational challenges, curious how I might be able to help, or just want to talk about some of the issues you face or that I write about, get in touch.

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?

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.

Evolutionary project planning

Rick Davies just posted Evolving storylines: A participatory design process?, a fascinating description of the evolutionary process of iterated variation, selection and retention applied to project planning, to project evaluation, and to storytelling. He raises more questions (for me, at least) than he answers, for he points at a range of variations one can try to see what works best in any one situation.

I think I'll look for opportunities to try it out.

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.