Perfection is Overrated

Since I retired, I’ve rekindled my fondness for working with wood. My workshop consists of the 43 inches between the front bumper of my truck and the east wall of my garage, although the truck moves when I need more room. Still, space matters, and I depend almost entirely on hand tools. And because space matters, I built a Dutch tool chest to store and protect them.Dutch Tool Chest

This is a classic design, with a lid that slants forward to discourage using it as a place to set things down “just for a few minutes,” and a fall-front door in a lower section. I also built a rolling cart, with a similar fall-front door, to keep it mobile. Loaded with tools, it weighs nearly 200 pounds.

I won’t bore you with the details of the mistakes I made, from lumber selection to design flaws, to flaws in the dovetails and dadoes I cut to join the case together, to rework as I learned to mix and apply milk paint. I’ll just say that, as I introduced errors, I corrected them. After thirty years in project management, I’m used to things not working out as expected. I even left a few errors exposed, to remind me that perfection is not only unachievable, but overrated.

Looking down into the chest A wise man once observed, “It isn’t a mistake until you can’t correct it.” And we’ve been acting on that sage advice for thousands of years. You simply have to accept the notion that good designs evolve, that adjustments are desirable, and that the result matters more than the process.

I could point out dozens of flaws in this project, but what people look at is the totality of the end result. From the Eddie Van Halen paint job to the intricate tool racks to the wainscotting on the back, to the bottle opener on the left side, it’s decorative as well as functional. And that is what matters.

Back

“The relentless pursuit of perfection has been my problem over the years. It’s maybe held me back.” Ronnie O’Sullivan had it right. If we fear making mistakes, we won’t get started. Even worse, we won’t finish anything. And since we spend time and money on projects to deliver benefits, we have to define acceptable quality based on the benefits we want to deliver, not the egos of the personalities involved.

In Praise of Constraints

Peter Saddington is an Agile coach and certified Scrum Trainer, who is on my short list of preferred Agile thinkers. He blogs at Agile Scout, and is the author of “The Agile Pocket Guide.” Peter posted an interesting article on removing constraints over at Agile Scout earlier this week. In it, he says:

Removing constraints to delivery will allow speed of delivery to increase, but not for the sake of speed. Speed becomes an outcome of the removal of constraints.

Well, that can be one outcome. But there can be others. The trick is to remove constraints that impede the goals of the business, without adding risk or reducing quality.

Knight Capital – Deployment Constraints

On August 1, 2012, market maker Knight Capital deployed an untested software configuration to a production environment. The cause? A technician forgot to copy the new Retail Liquidity Program (RLP) code to one of their eight production servers, which were Knight’s automated routing system for equity orders. When released into production, Knight’s trading activities caused a massive disruption in the prices of 148 companies listed at the New York Stock Exchange, resulting in 4 million executions for more than 397 million shares in approximately 45 minutes, at the wrong price. Losses for the day cost Knight Capital far more than their market capitalization (which fell dramatically by the end of the next day), and the company was acquired a few months later.

Firefly – Process Constraints

Firefly RestaurantThe best restaurants are run not to optimize throughput (unless you’re a big fan of drive-through windows), but to optimize the dining experience. That’s why they operate under process constraints for everything from cleanliness to the temperature at which food is stored. Small changes in a restaurant operation can make a huge difference in the dining experience, for better and for worse. When a stressed-out employee at a tapas restaurant here in Las Vegas called Firefly decided to minimize the time for his bathroom break by not washing his hands, about 300 customers got very sick with Salmonella. John Simmons, Firefy’s Head Chef, later said, “We’ve hired a food safety consultant with over 30 years of experience to double and triple check our methods and we’ll operate in the mode of continuous improvement, constantly upgrading our practices with new technology, new methods, and additional training.” In other words, applying constraints to the food preparation process. They’re still in business at a different location, but revenues have not recovered.

Mindfully Managing the Process

Some constraints can and should be removed, as part of maturing the process; others should be added, as part of the same maturing. Mindful management frequently reviews and tailors the process to optimize for the desired outcomes, usually with the active participation of the people doing the work. Mindless management does … well, other things. If your management is doing other things, maybe you need to find a better organization.

Image of Firefly restaurant copyright Las Vegas Sun, 2013.

Faux Compliance

Crappy BumperOne of the nice things about living on a golf course is that there’s plenty of well-maintained scenery. Since we don’t play golf, we’re able to take nice, long walks unencumbered by clubs, balls, bags, and the need to keep score. While on our walk this morning, we passed by a car had apparently encountered an inattentive driver. Bumpers are legally required here in Nevada, so the owner removed the outer portions of the smashed rear bumper and used a hank of clothesline to support the inner plastic core, now in two pieces. I’m not sure whether the Metro Police Department will object to his handiwork or simply chuckle and drive on, but it plainly isn’t going to absorb the impact of his next collision.

True Compliance

Most of my projects over the last thirty years or so required compliance with some regulation, standard, or guidelines published by some external authority. In many cases, it was administrative rules interpreting some legislation; in others, it was standards like GAAP. In all cases, compliance was one of our critical success factors. In many cases, we were self-auditing; in others, we had inspectors or auditors review our work. But compliance testing was a part of every plan. To that end, we tried to understand the nature of the regulation – what is it trying to accomplish, or prevent? It isn’t enough to just go through the motions of compliance. Your subject matter expert has to think like the inspector, and ensure that you are truly in compliance with both the letter and the spirit of the regulation.

Mitigating Bad Outcomes

The impact of a finding of non-compliance in an inspection or audit is a business risk in itself. In some cases, the bad outcomes that the regulations were designed to prevent or mitigate are also an operational risk. This is especially true when safety or privacy is at issue: the organization has a stake in preventing bad outcomes during the project and in operation. Consequently, compliance should be part of your project risk analysis. Think of the regulation or standard as a proven risk response; your goal should be to make it effective, so the organization doesn’t have to assume additional risk.

Like risk management, compliance management is part of a practicing IT project manager’s professional tool kit. You don’t have to be the subject matter expert on the regulations; you simply have to manage the efforts taken to comply, and ensure that compliance is effective, rather than merely cosmetic. Like that trussed-up bumper, for example.