Quality and Innovation

President-Elect Obama has hired a quality manager, and her name is Nancy Killefer. She is the newly appointed “Chief Performance Officer” whose mandate is to manage budget reforms while eliminating waste in government processes, ultimately making it more effective. An MIT & McKinsey alum, Time calls her the “first official waste watchdog.”

From the Washington Post:

“We can no longer afford to sustain the old ways when we know there are new and more efficient ways of getting the job done,” Obama said during a news conference this morning at his transition office. “Even in good times, Washington can’t afford to continue these bad practices. In bad times, it’s absolutely imperative that Washington stop them and restore confidence that our government is on the side of taxpayers and everyday Americans.”

This is a fantastic indication of our new administration’s commitment to quality, and its recognition that the current economic crises can only be solved by fiscal pragmatism and solid foundations.

Regardless of what happens next, I am pleased to see that our new administration’s attitude is so positive:

As he named Killefer, Obama promised to scour the federal budget to eliminate what doesn’t work and improve what does to “put government on the side of taxpayers.” He said: “We can no longer afford to sustain the old ways when we know there are new and more efficient ways to getting the job done.”

Nancy, you should join ASQ (if you’re not already a part of the organization). There are 100,000+ of us, more or less, that not only support you but want to help you develop a high-performance government. We come from all industries, are adept at process improvement at creative solutions for increasing efficiency, and can be effective advocates for your mission. Let us know how to help!

Temperatures in central Alaska have been 60 below zero (degrees F) for two weeks now:

Extreme temperatures — in Johnson’s case about 60 below zero — call for extreme measures in a statewide cold snap so frigid that temperatures have grounded planes, disabled cars, frozen water pipes and even canceled several championship cross country ski races. Alaskans are accustomed to subzero temperatures but the prolonged conditions have folks wondering what’s going on with winter less than a month old.

This is not an isolated event. Just last week, a record snow event in Washington state and British Columbia caused roofs to collapse.

What does it mean when “extreme events” happen more and more often? Are we really succumbing to global warming, or has global warming stopped, putting us on the threshold of a new ice age? I’m not interested in assessing the scientific validity of these speculations, especially since in many cases the observed data doesn’t match earlier predictions – collectively, we still have a lot to learn about the true impacts of anthropic climate change.

What I do want to focus on is one way in which our expectations influence decision making in quality management, and how this relates to climate change and the prospect of global warming. We don’t construct buildings that can withstand such heavy snow in Washington state, because historical weather records indicate that such weather is not likely to occur. Similarly, we don’t fortify buildings to be earthquake-proof in New England, because we don’t expect that a damaging event will ever happen there. Our expectations of environmental conditions influence the technical specifications that we establish.And our ability to conform to those specifications is one factor that determines quality of output.

Juran’s definition of quality as “fitness for use” implies that we understand the typical environmental conditions that characterize the context of use. We also have to be cognizant of the extreme events that might occur, and when these extreme events are outside the bounds of our expectations, failures can occur.

So from the quality perspective, it doesn’t matter if the polar ice caps melt or if they advance as far as Florida. A major unspoken risk of climate change is that we will be required to adapt to new environmental expectations, and it will take some time for us to make our manufacturing systems respond. For example, airplanes are air-worthy because they are fit for the expected context of use (flight altitude, expected outside air pressure, turbulence that’s not severe). This week in fact, many planes in Alaska have been grounded because they weren’t built for the extreme conditions.

If the environment changes significantly (whether it’s through global warming or global cooling), the assumptions underlying the technical specifications for many of the products that support our economy may have to shift. In the meantime, we can expect frequent and potentially serious quality problems to emerge.

On my drive home tonight, a giant “Maersk Sealand” branded truck passed me on the highway. It got me thinking about the innovation of the shipping container, and how introducing a standard size and shape revolutionized the shipping industry and enabled a growing global economy. At least that’s the perspective presented by Mark Levinson in The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger. A synopsis of the story and a sample chapter are available; Wikipedia’s entry on containerization also presents a narrative describing the development and its impacts.

Here’s how impactlab.com describes it:

Indeed, it is hard to imagine how world trade could have grown so fast—quintupling in the last two decades—without the “intermodal shipping container,” to use the technical term. The invention of a standard-size steel box that can be easily moved from a truck to a ship to a railroad car, without ever passing through human hands, cut down on the work and vastly increased the speed of shipping. It represented an entirely new system, not just a new product. The dark side is that these steel containers are by definition black boxes, invisible to casual inspection, and the more of them authorities open for inspection, the more they undermine the smooth functioning of the system.

Although some people like to debate whether the introduction of the shipping container represented an incremental improvement or a breakthrough innovation, I’d like to point out an entirely different aspect of this story: a process improvement step yielded a plethora of benefits because the inspection step was eliminated. Inspection happened naturally the old way, without planning it explicitly; workers had to unpack all the boxes and crates from one truck and load them onto another truck, or a ship. It would be difficult to overlook a nuclear warhead or a few tons of pot.

To make the system work, the concept of what was being transported was abstracted away from the problem, making the shipping container a black box. If all parties are trustworthy and not using the system for a purpose other than what was intended, this is no problem. But once people start using the system for unintended purposes, everything changes.

This reflects what happens in software development as well: you code an application, abstracting away the complex aspects of the problem and attaching unit tests to those nuggets. You don’t have to inspect the code within the nuggets because either you’ve already fully tested them, or you don’t care – and either way, you don’t expect what’s in the nugget to change. Similarly, the shipping industry did not plan that the containers would be used to ship illegal cargo – that wasn’t one of the expectations of what could be within the black box. The lesson (to me)? Degree of abstraction within a system, and the level of inspection of a system, are related. When your expectations of what constitutes your components changes, you need to revisit whether you need inspection (and how much).

This is the fourth and final installment of my collaboration with John Hunter and friends on the Year-End Management Improvement Carnival, where we review the best management improvement blogs and share which posts we found to be the most insightful or helpful. Today I have the privilege of bringing you a few gems from the iSixSigma blogosphere.

PART 4 of 4 – The iSixSigma blogs are written by a cast of columnists who share their experiences with the practice of quality improvement. The favorites I’ve picked out here are only the tip of the iceberg… there are many more on the site.

Innovation and Six Sigma (5/9/2008) – This article aims to answer the question “Does Six Sigma kill innovation?” In addition to being a thought-provoking article, the collection of comments is worth reading as well. I particularly liked this perspective: “I’m reminded of a story I was once told about an author who decided to write an entire novel without using the letter E. You’d think this would be incredibly limiting, but in fact the author ended up learning many, many new words and taking his writing in entirely new directions. The structure forced him to break old habits and think in new ways.”

The iPod Did Not Come From a Focus Group (3/3/2008) – Development of the iPod is an example of customer and market-driven innovation. The author of this article notes that “your company probably knows more about what is possible than most of your customers; but the lesson I take away from the Apple example is this: some of our customers know a lot more than we do, and we ignore them at our peril.” There’s also a pointer to an excellent 2002 article in the Harvard Business Review.

Six Sigma: The Laissez-Faire of Politics (1/28/2008) – In this article, the author explores how to solve a real public policy issue using Six Sigma: reducing the consumption of plastic bags (like the ones you get at the grocery store) on the national level. “If there is one area in society that definitely needs an injection of Six Sigma, it’s politics. Just like the working world of business, people want a silver bullet quick fix that sounds good and will make people feel good. Politicians often open their mouths without performing due diligence and as a result only partially address an issue.”

What You Measure is What You Get (12/22/2008) – This post reflected on the role and meaning of measurement (one of my favorite issues). “Perhaps what you measure is what you get. More likely, what you measure is all you’ll get. What you don’t (or can’t) measure is lost” – H. Thomas Johnson

Six Sigma Project Failure (7/28/2008) – What’s required for a Six Sigma project to fail? Conflicting definitions are explored in these survey results. (This is somewhat related to Eight Reasons Why Projects Fail (4/24/2008), another good post.)

Return to Part 1 of 4 –>

Return to John Hunter’s Management Improvement Carnival: 2008 Year in Review –>

This is the third installment of my collaboration with John Hunter and friends on the Year-End Management Improvement Carnival, where we review the best management improvement blogs and share which posts we found to be the most insightful or helpful.

PART 3 of 4 – Clarke Ching’s stream-of-consciousness blog covers random musings, cartoons, links to useful articles, recipes, mathematical puzzles and games, and thoughts about quality-related techniques including Theory of Constraints and software development.

Testers – the worst thing that happened to software development? (5/30/2008) – This story describes a first-person view of how software quality can be achieved more easily – by studying the successful approaches used by good maintenance teams. “There’s a huge amount that development managers (i.e. those that work on bigger projects) could learn from the way good maintenance teams work. The first would be to break down their work into smaller chunks.” (Again, this reminds me of “stackless thinking”which really appeals to me.)

Critical Chain Scheduling (8/22/2008)- Clarke wrote an article, published over at stickyminds.com, covering how to use the critical chain method to improve scheduling in agile development environments. “Critical Chain, as I’ve described, is a great way of rebuilding trust between managers and their staff. In fact, it is THE best way I’ve found. It’s also sorely needed, judging by some of the comments.”

Lord Kelvin (9/13/2008) – Why measure things? On a trip to Scotland, Clarke reflected on this question as he pondered the intro to Douglas Hubbard’s book, How to Measure Anything: “When you can measure what you are speaking about, and express it in numbers, you know something about it; but when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind; it may be the beginning of knowledge, but you have scarcely in your thoughts advanced to the state of science.”

Go to Part 4 of 4 –>

This is the next installment of my collaboration with John Hunter and friends on the Year-End Management Improvement Carnival, where we review the best management improvement blogs and share which posts we found to be the most insightful or helpful.

PART 2 of 4 – Europe’s ”#1 Blog for Software Development Managers” has posted an excellent review of the most popular 2008 articles from their site, based on the site traffic throughout 2008. Here are my personal favorites.

A Theory of Everything for Software Development (8/7/2008) – Physicists pursue the grand unified theory to explain space, time and everything in between… while noop.nl attempts to reconcile the myriad of approaches to software development by reminding us of context-dependent approaches. Here’s a sample: “Unix and Windows are both proper solutions, though each in its own limited cultural context. And they cannot both be the best solution at the same time and place. (And might I suggest that, in the case of operating systems, a Theory of Everything has already been found with the invention of virtual machines? Just a wild thought.)”

Simple vs. Complicated vs. Complex vs. Chaotic (8/20/2008) – You can have predictable, complex, and chaotic systems that are simple – or, you can have predictable, complex and chaotic systems that are complicated. This is the best description (and collection of online references) I’ve seen to explaining the differences between these concepts. “My computer is complicated. My software project is complex. My house is complicated. My household is complex. My blog is complicated. My thoughts are complex. Your dinner is complicated. Your dog is complex.”

Thank You, Stupid Americans (4/23/2008) – This is an interesting blend of software development insights and politics! Although I don’t personally equate simplicity with stupidity, and I realize there are plenty of smart Americans too, I found this to be a lighthearted and stimulating read.

How to Handle Many Simultaneous Projects (9/30/2008) is also an excellent commentary. I don’t know any manager who doesn’t have this issue – whether they are a quality manager, a technology manager, a construction manager, or a manager of software development.

Go to Part 3 of 4 –>

I’m privileged to be partnering with John Hunter and friends to produce the Year-End Management Improvement Carnival. Our goal is to review the best management improvement blogs out there, and find out what gems were posted during 2008 – then take you on a guided tour of the past year’s most intriguing management insights.

PART 1 of 4 - The first three favorites on my list come from David Anderson’s http://www.agilemanagement.net, a blog that focuses on effective and productive implementation of agile methods in software development and management.

Providing Value with Lean (3/31/2008) – One of the most important considerations while implementing a quality program or process improvement initiative is that you focus on the right aspects of the problem at the right times. This is much easier said than done, especially since the problem solving environment is socio-technical – and as a result, complex. But David makes the excellent point that “doing lean” means more than just eliminating waste. You have to take a systems perspective, and first consider how value is to be added, then analyze the process for flow, and then work on eliminating waste. Sometimes, to get a better process, you have to add waste before the improvements can be realized in a sustainable fashion.

Recipe for Success (9/5/2008) – David says: “This is the mechanism I use to achieve sustainable pace and to implement a pull system which provides a nice mechanism for simple prioritization. Prioritizing becomes easier when you have demand balanced against throughput of work items.” In addition to the two variants on the recipe he presents, another reason I like this post is that it reminds me of how the concept of “stackless” programming languages can inform efficient workflow.

Personal Hedgehog (11/2/2008) – What are you uniquely good at? What are you passionate about? What motivates you economically? The most productive people are in roles that fit them well, and the Personal Hedgehog concept can help you find your niche. (Might also be good for managers who want to help their team members find a good fit.)

(I’m also intrigued by David’s concept of an unconference.)

Go to Part 2 of 4 –>