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.

High Failure Rate, Compared to What?

Failed DigFor many years now, we’ve read studies such as the CHAOS report, expounding on the relatively high failure rate of IT projects. High, relative to what – highway construction projects? The typical highway construction project is proposed, studied, risk managed, and planned for years before the first shovel of earth is turned. A massive body of laws, regulations, standards, and technical requirements drive every design. Materials, products, and processes are mature and standardized, and a coterie of safety experts, inspectors, and regulators watch over every step. With all of that, one would reasonably expect highway construction projects to have a low failure rate. Yet, these projects still fail. The Big Dig in Boston stands out as a monument to cost and schedule over-runs.

Rat's Nest CablingIT projects, on the other hand, tend to be subject to snap decisions by sponsors, with little executive oversight. There is typically limited time allowed for planning, due to short schedules driven by “competitive pressure” and ever-shorter product life cycles. Scope is frequently vague. Stakeholders are usually too busy with “business as usual” to participate in planning, defining requirements, or testing. Project team members are rarely dedicated to the project, and their work priorities are constantly shifting. Software tools are buggy, poorly documented, and poorly supported by the vendors (or “supported” by a user community). No wonder so many software development teams are using Agile methods to shorten their development cycle, limit their scope, and keep “the bar” within reach.

Defining Success

All of those constraints and challenges aside, we should assess success in terms of results delivered. Project management isn’t about budgets and schedules; those are just the means to an end. A successful project would:

  • Deliver usable results, quickly enough to be of benefit, to customers that understand how to use them
  • Delivery didn’t “break” something else
  • All non-functional requirements were met
  • Knowledge transfer was compete and effective
  • Maintenance throughout the product life cycle will be cost-effective, and major business process surgery won’t be required in order to replace it at end-of-life
  • Quality is commensurate with the criticality of the delivered product to the business
  • Organizational change management efforts were sufficient to meet adoption goals
  • The risk profile did not exceed the organizations appetite for risk, and the risk management budget was spent wisely
  • All contracts were completed satisfactorily and relations with the vendors remain positive
  • The core project team was retained, and their experience will benefit the organization in the future
  • After some reasonable period of time in operation, it looks like the ROI that will be achieved at least matches what was expected in the original business case
  • Any lessons learned have benefited other activities within the organization

You can make your own list, based on the nature of your project, but the key point in making it should be that success isn’t about the project; it’s about the results.