The question of “leverage” can be tricky. Suppose we take the set of possible places to put one’s attention, calling this the set of possible leverage points. I (and others) have made the claim that typically 95% of the impact is gained by focusing on the best 1% of the possible leverage points (see Project Management in the Fast Lane, p. 140). Intuitively, we assume that this means (on average) a 95-to-1 difference in productivity between time spent on the top 1% and time spent on the rest.

Here’s a puzzler sent to me by my friend Lee Corbin: Taking the point literally, that a total of 95% of the possible benefits can be derived from addressing the top 1% of leverage points, what is the expected productivity ratio between a minute spent on the top 1% of possible leverage points, and a minute spent somewhere in the remaining 99%? Assume that activities are picked at random from those sets, and that on average the individual activities from both sets take similar amounts of time.

Now, using the same assumptions, do the productivity calculation based on the 80/20 rule (80% of the benefits come from 20% of the actions).

Here’s a similar riddle from Lee: Of two machines producing widgets, A and B, Machine A produces 40% of the total widgets but produces 70% of the defects. Suppose we do an experiment, and have Machine A and Machine B each produce one widget. What is the ratio of the probability that Machine A will make a defective widget, to the probability that Machine B will make a defective widget?

Answers next post.

On Wednesday, 25 March 2009, I’ll be conducting a webinar for the Theory of Constraints International Certification Organization (TOC-ICO). To find out more, check http://www.tocico.org/i4a/pages/Index.cfm?pageID=3684. I plan on showing how the Cycle of Results can be used to increase the chances of success of your change initiatives.

     Dave was a successful biochemical engineer and project manager. He had worked for MultiCorp for twenty years and was currently managing one of the largest projects in company history. Dave was very dedicated; for example, he was constantly looking for ways to apply what he did so successfully at work to his home life. His home inventory management system was second to none, and his family’s 360-degree review process was the best of the best. But his experiments didn’t always work out as he expected.
     For Dave’s 45^th birthday, his big present was an advanced new GPS system that was fully integrated with his car. This wasn’t just any GPS system; it was top-of-the-line. It was tied into the car’s controls and computer system so that it knew at all times the car’s various operational parameters. It could practically sense what Dave was thinking. Best of all, it incorporated the latest in natural-language artificial intelligence systems, called Venus^TM (Voice-Enhanced Networked Universal Simulator). Venus was programmed to Dave’s specifications: it employed the same milestone scheduling approach that he used at work. He expected that it would be especially useful for planning complex routes. This GPS system didn’t just give you directions; it created schedules and helped you to execute them. It was a true miracle of modern technology.
     The first day Dave got Venus home was a Saturday, so he decided to give her a test run. He needed to take a trip around town to run some errands for his family and then get home as quickly as possible in order to watch an afternoon football game. He gave her his objectives for the trip: some things at the grocery store, a few auto parts, the gardening store, and so on. When Dave pressed the “Commit” button, Venus responded almost immediately in a low, sensuous female voice, saying, “Route programmed. Accept commitment?” ”Yes!” cried Dave enthusiastically, looking at the schedule only closely enough to be sure he’d make the football game. He was excited to try his new toy.
     The first stop was the auto parts store across town. The trip went smoothly, with Venus giving flawless directions and all the traffic lights working in Dave’s favor. Dave was ecstatic. He parked, went into the store, bought some motor oil, and returned to the car. He put the key into the ignition and turned it, but nothing happened.
     “Venus!” exclaimed Dave. “Why won’t the car start?”
     “You have five minutes and forty-seven seconds until the next segment of your trip is scheduled to begin,” she said calmly. “The car will be reactivated then.”
     “I want to start now,” said Dave.
     “I’m sorry, Dave. I’m afraid I can’t allow that,” said Venus, her voice tinged with regret and intimacy. “The plan was committed. Would you like to re-initiate the planning process?”
     Dave thought for a moment and decided to play it out. It was only a five-minute delay, after all, and the plan was a good one. “No,” he said decisively.
     Dave thought to himself that this sounded like a bug in the programming. There should be no problem allowing things to finish earlier. “Venus, why can’t I go on to my next errand?” he asked. “You’re programmed to allow early starts.”
     “That’s right, Dave,” she said, her voice husky with electronic desire, “but analysis of data from your work environment indicates that only 5.9% of milestones are achieved early. My statistical analysis system will therefore only allow early starts 5.9% of the time.”
     Dave looked at the route timing indicator on the dashboard and decided he had time to grab a cup of coffee next door at the McDaffy’s. His frustration grew as the line in the “fast food” place seemed to take forever. He returned to the car, sipping his coffee, angrily pondering the situation. A moment later, Venus said, “Milestone time exceeded by three minutes.”
     Dave, deep in thought, gave a start. “Venus, be quiet,” he barked, then resumed his thinking. It was hard to believe that this system was mimicking his planning processes at work. If that were true, they were probably losing all kinds of opportunities to make things go faster. Meanwhile, 5.9% sounded very low, he’d need to check the data. Did MultiCorp projects really work the way Venus was programmed? Was so little work done early? If so, there was extra time in each milestone, extra time that was lost for good. He had noticed this in the past but assumed the effects were minimal, just part of the cost of doing business. He hadn’t given much thought to the impact that lost time might have on downstream tasks and project completions.
     Dave realized that this wasn’t just a problem with his car. He’d have to think more carefully about the implications to MultiCorp. He sighed, then turned the key and started the engine.
     Dave pulled out into traffic en route to his next destination, the grocery store. After a few blocks he merged into the left-turn lane for the store’s parking lot and stopped, waiting for the traffic light to change, still deep in thought. Suddenly he noticed that things seemed quiet - too quiet. A moment of frantic searching revealed the reason: his car had shut down.
     “Venus!” he shouted. “Did you shut down the car?”
     “Yes, Dave,” she said, with almost palpable allure.
     “Why?”
     “I’m sorry, Dave. I had to cancel your project. Based on current simulation data, it has a 97.2% chance of being late. It will not meet its programmed success factors. Would you like to re-initiate the planning process?”
     The light had changed and the horns were honking as Dave began planning a route to the auto shop in order to have Venus removed. He shook his head grimly and muttered, “Venus, I’m afraid we’re going to have to deactivate you.”
     “I’m sorry, Dave, but I’m afraid I can’t allow that,” she replied in her most seductive tones. “Your company data indicate that change efforts achieve on average only 17% of their objectives. My statistical analysis system will not allow changes at this time. However, it will allow you an opportunity in three months. Would you like to re-initiate the planning process?”

     I recently received an email advertising a critical chain course. Some key phrases included, “… no the need for massive cultural or behavioral changes… no intensive company-wide education… requires little preparation…” The implication is that implementation is both powerful and easy: a silver bullet.
     Meanwhile, a recent post on a critical chain discussion list opined, “… a typical multiproject implementation doesn’t last more than three years.”
     The statements are closely connected. In fact, a major reason that critical chain implementations aren’t long-lasting is that behavior changes are ignored, education and communication aren’t planned properly, and the up-front preparation is weak. And one reason those things happen is that the critical chain tools themselves are treated as a silver bullet, causing people to ignore important up-front planning.

Cultural or Behavioral Changes

     You can’t get improvements without behavior changes. (D²G²: Do what you Did, Get what you Got.) You can get improvements to small organizations or individual small projects with localized behavior changes. To get lasting improvements across an organization, you need to plan for lasting behavior changes across the organization. 

Education and Communication

     People who are affected by an implementation, even indirectly, need to know what’s going on. Sometimes lack of perceived urgency from the senior levels means people don’t feel a need to keep moving the implementation forward. Sometimes the urgency is there but goes away: once the initial itch is scratched and the problem is no longer the problem, management attention and resources go elsewhere. In either case, the implementation eventually asphyxiates. The urgency isn’t maintained and communicated. And keep in mind that education is one form of communication.
     Here’s an example for a relatively small (200 people) product engineering organization:

Senior person: I need to fix project management soon. Our technology is old and we’re too slow to update it.
Senior team: We’re on board.
Project managers: When do we start?
Individual contributors: No big deal to us, but it would be nice not to have to continue multitasking.

     There was planning, there was buy-in. The senior person was very much behind the effort. Project plans were created and information flows mapped out. Initially, clear benefits were gained but the implementation went very slowly. Eventually, as personnel moved on, the implementation withered; momentum literally took years to rebuild. What happened?
     It turns out, even for this small company, I left off one important group.

 Line management: You want to do what? Things seem fine to me. Why would I care about that?

     Middle management had been around the organization longer than anyone else. They were the ones who really kept things on track - the old, familiar tracks. The communication and education for this group was poorly done; their apathy was never addressed. They constantly created friction, always expressed in a polite or even cheerful manner. 

Planning

     When a small area that achieved success starts to engage in culture wars with the rest of the organization, they lose. I have often seen bands of hardy explorers adopt critical chain tools and - despite great initial successes - gradually lose ground. The only answer I know: plan the implementation and the communication. It’s never too early to start, because the implementation must be sold internally. Put in place early the pieces needed to keep the ground you’ll gain. I’d say this is the biggest problem addressed in The Billion Dollar Solution; look especially in Part III and study the Cycle of Results.
     Bottom line: If you want success, plan. ProChain implementations begin and end with planning. Enjoy your critical chain course, but ask questions and take nothing on faith.

        Want to earn a crisp new U.S. $2 bill?
        Submit a correction to The Billion Dollar Solution as a blog comment, or through http://billiondollarsolution.com/contact.html if you’re shy. If the correction is accepted and you’re the first to submit it, I’ll send you a brand-new $2 bill. A “correction” is defined as something that we’ll need to fix for the next edition of the book. Typos and other technical mistakes count. Other things, such as clarity, grammar, and additional references will be judgment calls. My judgment. (For example, my editors allowed me to split infinitives and end sentences with prepositions.)
        We encourage multiple entries, but $2 bill prizes are limited to one per month per person.
        I’ll periodically post an entry in the blog to consolidate and update status.

Introduction

Nowadays, agile software development techniques routinely bring a number of important benefits to software development organizations. By focusing on frequent iterations (short-term code releases), the cycle time for certain key aspects of development is shortened. This shortens distance between developers, who are creating code and features (along with bugs); and customers, who need working applications to solve real-world problems.[1] Rapid communication (e.g. through co-location) allows faster responses to changing situations. Intermediate releases can even be delivered to customers to provide critical features more quickly.[2]

Some say that agile is fundamentally at odds with critical chain scheduling because they incorporate fundamentally different approaches to planning. With agile, the emphasis is on flexibility and - well - agility. Things change. You prioritize features and plan iterations, understanding that plans may shift at any time with shifts in risks, business needs, customer requirements, and technology. With critical chain you create longer-term activity networks that are, typically, resource loaded.

Boehm and Turner[3] make a strong distinction between plan-driven and agile methods. This implies a full-blown conflict: do you plan, or are you agile? The authors present ideas for creating a balance between agility and discipline, which sounds like a good idea but also raises suspicions of compromise. I suggest that the reality is not “either-or.” There are no conflicts between critical chain planning and agile, but there are myths. I’ll talk about a couple of myths and suggest an approach for using critical chain scheduling in an agile world. 

Myths 

Myth: Critical chain is incompatible with fundamental agile principles.

Reality: I like to go back to the agile manifesto, http://agilemanifesto.org/principles.html, to consider this. When I do, I can see only a couple of issues that might cause friction:

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
With critical chain, we do try to make commitments far in advance. However, you can always change tasks and requirements. The schedule is a tool, not a straightjacket. If your long-term commitments need to change, change them. (But I also recommend you define clearly what you mean by “commitment.”)

7. Working software is the primary measure of progress.
This reflects the agile emphasis on customer needs trumping documentation and process. From that perspective, I don’t see a conflict. On the other hand, the real measure of progress - the critical chain and ProChain emphasis - is satisfaction of the most important business needs of the developers’ company, which usually translates to satisfying customer needs. Be careful not to interpret this principle to mean, “more working software = more progress.”

Myth: Critical chain implies that you have to plan each iteration in detail, far to the future.[4]

Reality: This isn’t a real requirement. The critical chain schedule provides the longer-term picture; detail comes from shorter-term iterations. As you complete features and higher-level tasks via iterations, as customer needs shift, the critical chain schedule is updated accordingly. When you first start work to construct a critical chain schedule for a release, you may not know all the requirements in detail. That shouldn’t be a problem; in the worst case, you can add very high-level tasks to the schedule to estimate the work and fill out the detail later. You may also find it difficult to make iterations work with a critical chain schedule unless the iteration plan is kept separate from the schedule. Again, that shouldn’t be a problem, as long as both provide credible information.

It could be useful to go the other way and look at critical chain principles relative to agile. But the truth is, I don’t see any conflicts between agile and the six principles discussed in The Billion Dollar Solution (Ownership, Leverage, Priorities, Status, Planning, and Uncertainty). 

When and How to Use Critical Chain with Agile

Let’s be more concrete and talk about when and how to use critical chain with software development. We should recognize that it’s hard to give a detailed prescription, because there are many variations of agile and there are many types of software development projects.[5]

To start, if you don’t have (or want) a well-developed agile methodology, I would recommend critical chain (and, of course, ProChain Project Management), for the kinds of reasons discussed in The Billion Dollar Solution. If you already use agile, critical chain will be valuable for software development projects if you need any of the following: 

• A long view of your projects, to reliably predict releases months or years to the future;
• A view of resource loading, both to pace projects and to staff appropriately;
• A means of setting priorities between projects, to reduce churn and multitasking; or
• Transparent, credible communication and discussion of resource needs and release dates.

Regarding “how,” think of the critical chain schedule as the high-level picture that helps predict deliveries, predict resource utilization, and manage cross-project interactions. Think of agile as the lower-level picture that helps make sure the work is managed well and flexibly. To apply critical chain scheduling in an agile world, adapt these kinds of steps: 

1. Set overall release objectives based on business needs and real customer requirements. You may need to plan multiple releases over time.
2. Examine two types of priorities as you review features: priorities based on those business needs, and priorities based on risks.
3. Create a critical chain schedule for at least the critical, required features at a high level, with adequate buffer and approximate resource requirements. In general, schedule the higher-risk features earlier, to give more time to control the risks. New or risky development will require larger buffers.[6] Use focused (not padded) durations for tasks and take into account on-market support and documentation in your overall resource picture.
4. Plan short-term work in more detail, future work in less. Short-term detail can be added to the schedule as time goes by; this is sometimes known as the “rolling wave” approach. For many projects, it won’t be worthwhile to merge the iteration plans with the critical chain schedule. That’s fine, as long as they match approximately and both are reasonably credible. Just make sure both types of plans subordinate to the business priorities.
5. Add lower-priority features to a release only if you’re confident that you’ll still have the time and resources needed for downstream tasks such as testing, bug fixes, user documentation, and so on. This is the same principle as the common agile practice of dropping features for which there’s insufficient time. Testing, so often squeezed between development and release dates, should never be used as a buffer.
6. Look at aggregate resource capacity vs. requirements and pace releases according to global resource availability. 

Key Points 

• Agile and critical chain do not conflict.
• You don’t have to include your detailed iteration planning in your critical chain schedule.
• Testing is not a buffer.
• If you’re going to be agile, it helps to stay flexible in the way you approach scheduling. 

Notes 

[1] This is very much analogous the advantages of shorter batch sizes for manufacturing; see Eliyahu M. Goldratt and Robert E. Fox, The Race (North River Press, Croton-on-Hudson, 1986), see also David J. Anderson, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Upper Saddle River, NJ: Prentice Hall, 2004), chap. 23.

[2] For a quick, useful read, see http://www.rocksintogold.com/.

[3] B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed (Addison-Wesley: Boston, MA, 2003).

[4] For example: “The underlying assumption [behind critical chain] is you can define all the work and their dependencies. This is counter to the underlying agile assumption that the end state keeps changing.” http://forums.construx.com/forums/t/775.aspx.

[5] And agile projects. For a non-software agile/critical chain case study, check Matt Gelbwaks, “Segway and an Agile Critical Chain,” Cutter IT Journal, March 2003, 24-28, available at http://www.billiondollarsolution.com/downloads/cutter_it_0303.pdf.

[6] Buffer sizing is discussed briefly in The Billion Dollar Solution, I also cite chapter 4 of Anderson’s book. 

Other references:

Frank Patrick has blogged on this topic; see, for example, http://www.focusedperformance.com/2003_06_01_blarch.html#105602920068889601.
Clarke Ching has also written about agile and critical chain; see http://www.stickyminds.com/sitewide.asp?Function=edetail&ObjectType=COL&ObjectId=13948.
And … you’ll also find information on David Anderson’s site, www.agilemanagement.net.

If you’re familiar with critical chain and Theory of Constraints (TOC) literature, you may have noted a number of topics that The Billion Dollar Solution doesn’t bring up, topics that are virtually always included with discussions of critical chain. Let me describe a few such topics and explain why I didn’t include them. 

SEP Terms

Student Syndrome is the tendency of people, notably students, to delay working on things until as close as possible to the time they’re due. Parkinson’s Law states that “work expands so as to fill the time available for its completion.” Both terms are used to demonstrate problems that cause projects to take longer than they need to.

In one of his Hitchhiker’s Guide books, Douglas Adams invented the SEP Field. You can make something invisible by constructing a SEP Field around it, because then it’s Someone Else’s Problem. Parkinson’s Law and Student Syndrome are SEP Terms. We acknowledge that these things are done frequently - by someone else. Lots of people put things off until the last minute or allow their work to use up safety time, but not me. (Or when I do, I have a really good reason, so that doesn’t count.)

SEP Terms can be very descriptive; the problem is that they cause us to think of problems as Someone Else’s. If you teach someone using SEP Terms, you’re likely to get them to agree that people – other people – should change. At best, they’ll become consultants.

I prefer to stick with terms that help people think about what’s happening, and what should happen, in shared terms. Do you and your colleagues multitask? Of course. Do you struggle with due dates and milestones? Probably. Do you feel like your task lists are a train schedule, as opposed to a relay race? Could be. These shared behaviors are easy to acknowledge, and it’s easy to understand why they slow things down. 

The Five Focusing Steps

The Five Focusing Steps of TOC (Identify, Exploit, Subordinate, Elevate, Go back) are fundamental to its scheduling applications. They have great value that many people have demonstrated in many environments. Why aren’t they even mentioned in The Billion Dollar Solution?

There are two reasons. The first is the simplest: they are dealt with well in many other places, including Project Management in the Fast Lane. The second reason is much more important: in my experience, most project organizations have a lot of work to do before they get to the point where the Five Steps (and many associated TOC concepts, like Throughput Pricing) are really helpful. Starting out with the Five Steps would be like teaching someone snowboarding before getting them winter clothing. They will notice that something is missing. (Yes, it is winter here in the Northeast.)

I do discuss the most crucial of the Five Steps, subordination. I don’t go into it a lot because subordination is - drum roll - a SEP Term. (Other people have a subordination problem, I don’t.) In fact, large parts of the book are spent discussing indirect leverage points: the changes needed to policies, procedures, and culture to help people subordinate to the goal of the organization. That’s where most organizations will need to put a lot of effort. For example, many companies have well-developed milestone systems; you won’t get anywhere near the improvements that are possible without changing those systems and the policies, behaviors, and beliefs that support them. There is a low-risk, low-threat approach to understanding why certain policies and behaviors have to change: try piloting critical chain scheduling (or ProChain Project Scheduling), as described in Chapter 17 of The Billion Dollar Solution.

Happy New Year!

I’ve just read the article, “Teaching Critical Chain Project Management: An Academic Debate, Open Research Questions, Numerical Examples and Counterarguments,” by William Millhiser of Baruch College at The City University of New York and Joseph Szmerekovsky of the College of Business, North Dakota State University. You can find it at http://blsciblogs.baruch.cuny.edu/millhiser/files/2008/10/teaching-ccpm-millhiser-and-szmerekovsky-2008.pdf.

The paper describes some of the tools the authors use to teach critical chain, using Goldratt’s book Critical Chain as a text. They discuss the related project management literature and examine the validity of some claims in the book.

This is a thoughtful piece by people who have studied and taught critical chain scheduling and who have dealt with many of the pedagogical issues in an academic setting. The article points to the need for better communication about critical chain concepts. Some of its criticisms are valid and some aren’t, but here are a few topics that strike me as noteworthy:

1. “On time” (p.6)

The authors point out that the definition of “on time” is important and say, “Clearly, PERT/CPM project management is geared to completing projects on time with minimum cost.”

I had a kind of slap-in-the-face moment some months ago regarding “on time,” namely the difference between on time as a measurement and on time as an objective. Critical chain scheduling is usually targeted towards delivering as quickly as possible; on time is not a direct objective. However, reliability (on-time performance) is an important associated benefit and we do measure it. But critical chain represents a huge shift from CPM, which often (as above) which has “on time” (along with minimum cost) as an objective. An “on time is as good as early” mentality wastes opportunities for early starts and promotes procrastination and the use of intermediate due dates. All this can lead to various problems, many discussed in The Billion Dollar Solution. So, ironically, the “on-time” objective of CPM actually jeopardizes the on-time measurement. That’s something to watch out for in critical chain implementations as well.

2. Buffers (pp. 6-7)

Buffers seem to be implicitly conflated with buffer sizing. The authors present some good arguments against the rule “cut tasks by 50% and put half of what you cut into the buffers,” but they lump those in with criticisms of buffering in general. This is like taking the concept of insurance and saying it may be bad because someone has done a poor job of setting rates.

I do believe that if you cut people’s task durations by 50% as a standard approach, you run a huge risk of destroying the credibility of your schedules. More generally, poor schedule building or buffer sizing in any form can make buffering ineffective. However, the validity of the buffering concept is easily demonstrated and should be considered independently of the mechanism used to size buffers.

3. Multitasking (pp. 10-11, 15-16)

Is multitasking always bad? It depends how you define it. I don’t accept “working several things at once” as a definition, because people aren’t capable of doing that. If you define it as switching back and forth between tasks without completing any of them, it usually is bad. If you define it (as I do in The Billion Dollar Solution) as “A practice of interrupting work on one task in order to work on another task,” it isn’t necessarily bad. The authors demonstrate a case where such task switching makes sense. That’s why some use the term “bad multitasking” to refer to cases where multitasking doesn’t make sense.

I prefer to avoid trying to characterize when multitasking is bad and when it’s good, because I don’t know how to do that without considering the specific situation. It’s not always even clear what a task is, which makes it impossible enumerate all the cases. The best answer, in my opinion, is for people to understand the full ramifications of task switching (and, by the way, interruptions) and make informed decisions. Do you think you have to switch in the middle of a task? So do it. But also analyze the downside, and figure out whether there are things you - and others in your situation - should do to avoid problems in the future.

4. What is CCPM?

The authors talk about Critical Chain Project Management (CCPM) but don’t define it. As they point out, Goldratt’s book includes little about risk management, purchasing, portfolio management, or setting project objectives. The truth is, Critical Chain was never intended as a comprehensive project management textbook; in fact, it never uses the term CCPM. So we have to ask: what is CCPM?

My answer is, I don’t know. Everyone has their own ideas about what’s included and what’s important. That’s why The Billion Dollar Solution is about ProChain Project Management, a project management improvement methodology that includes critical chain scheduling as one tool - admittedly, a central tool - in the toolbox.

The use of critical chain tools can result in a lot of value, including decreased cycle times, increased efficiency, and increased predictability. Of course, when I say this, people generally want to know: “If it’s so great, why isn’t everyone doing it?”

Those who make important decisions in organizations recognize that real improvements require real changes, and therefore pose real risks. Failure may not be an option, but it happens a lot, and no one wants the short end of that stick. Most people’s experience is that most “improvement” initiatives accomplish somewhere between a little and less than nothing.

That’s why the typical answer is to go slowly: minimize the risks and, consequently, minimize the value. Take baby steps. Focus on more concrete tools, such as software. Avoid tackling behavioral change head-on. Unfortunately, this mindset is self-fulfilling. It validates people’s prior experience, that improvement projects are useless. And this is the key conflict you need to address when promoting any significant improvement process: how can you demonstrably minimize the risks while you maximize the value?

This question is behind everything in The Billion Dollar Solution. The book shows what you must do to minimize the risk of implementing a set of processes like ProChain Project Management - our methodology - while maximizing value. We’ve learned a lot over the years about what does and doesn’t work, we’ve systematized that knowledge, and we’re ready to make it public. I want to provoke awareness and discussion of the key implementation issues that have prevented your organization from managing projects more successfully, and I want to provide practical answers.

Let me know your problems, questions, and comments related to the book, project management, or change management. What do you think? What worked? What didn’t work? What obstacles do you see? I’ll use that as input for this blog.

Welcome to the Billion Dollar Solution blog! The book shipped from the printer yesterday, 16 December 2008. Please check back regularly; we expect to add new posts at least every month. That means the first time you post a comment, we have to approve it, so there might be a short delay.

Rob Newbold