Wednesday, February 24, 2010


My takeaway from the Toyota situation is the trap that infallibility can be.

For a couple of decades Toyota has been praised for the results of its engineering and production systems. Writers, analysts and  business leaders of all stripes have examined Toyota's processes and philosophy in the hope of achieving similar results in their organization. Most fail.

But that amount of positive feedback can build a sense of being infallible, that ones engineering is failure-free, that your systems will detect every problem before it is a problem. It can breed a culture that has a hard time accepting that the process might be generating errors.

This is not to defend Toyota, as it is clear that they have some engineering issues to work out. There are allegations that choices were made that were good from the financial view, but not the best from the view of the customer or the public at large.

Toyota finds itself at a rare moment. It can open itself to close scrutiny not only by the public, the press and government, but also to itself. Every step in the process of design and manufacturing should be open to change, to work out problems. Where in the system do problems rise? Can anyone, regardless of rank, point out a problem, or must it "go through channels"? How quickly are problems declared problems, and are they solved?

We all have processes, and we all regrettably produce errors. How quick are you to identify the source of an error? How quickly is it fixed?

Stay busy.


Sunday, February 7, 2010


I have had a run of projects that have a surprising number of questions unanswered at the start- things that would become expensive changes down the line.

Every industry has it complexity, but there is just a dizzying number of options in a video edit. With the news that using a checklist cuts down on surgical deaths, I imagine that using a similar, standardized format can reduce confusion, delays, overruns, and most importantly, looking like you don't know what you are doing in front of the client.

A checklist would be doubly beneficial for the sales department, who are usually long on enthusiasm but short on technical knowledge. In the excitement of a new sale, it would be very easy to not ask the important questions that the technical staff will need to know. What format is the project being shot on? By who? What are the deliverables? When are they due? Who gives final approval?

This doesn't have to be a twenty page legally binding document- projects always change a bit from beginning to end. A simple one or two sheet summary of the important details will answer 95% of the questions, and will hopefully cut down on the email loops one gets sucked in to.

What would you put on your checklist?