To reduce the pain of failed projects, get small

I enjoyed Gretchen Gavett's post last week on the HBR Blog Network entitled "The Hidden Indicators of a Failing Project." In it, she discusses how to determine whether projects are going bad (before costly, late public failures, such as the launch of the healthcare.gov website).

Gavett rightly points out that we have biases that prevent us from admitting that our project may not be going as well as we'd like - such as the urge to avoid the recriminations and criticism that comes with calling a project that is going off the rails. The "quiet fixing" mentality also rules, as one of Gavett's sources states: "people actually think they can turn [a failing project] around, so they don’t bring it up." She passes along several pieces of advice to help diagnose problem projects: e.g., cast a wide net of knowledge, revisit requirements regularly, etc.

In my view, the most effective way to prevent big, expensive project failures is to break projects up into smaller chunks. Large projects have large, abstract goals and take a long time to complete - and a long time before end customers get a look at what was delivered (see: healthcare.gov). In uncertain situations (i.e., most projects), it is better to have clear goals than a completely defined plan.

When projects are decomposed into smaller deliverables, each chunk can be specified at a level to deliver value to the end-customer - instead of abstract deliverables such as diagrams, specs, etc. The customer (as opposed to project team members) determines whether the project meets requirements. Smaller projects with clear objectives are easier to measure. Due to this clarity, failures are not only less frequent, but are discovered more quickly and are more contained. The inevitable changes to project requirements are absorbed more easily because smaller pieces can be adapted cheaply. The epitome of this type of approach is the Toyota Production System, which pushes improvement responsibility to the lowest possible level on the factory floor, and through many many iterations of tiny projects, adapts a highly complex production process to the changing needs of the global car market.

So, to reduce the cost and pain with large project failures, do one thing: get small.

Anita Tucker of Harvard Business School tests how nurses handle mistakes in business processes

Anita Tucker from Harvard Business School has just published the initial results of a fascinating experiment testing how nurses handle problems they encounter while executing a process ("Fostering Organizational Learning: The Impact of Work Design on Workarounds, Errors, and Speaking Up about Internal Supply Chain Problems" link - PDF). Do they speak up about issues, or do they “quiet fix”? And what actions can management take to try to increase people’s willingness to speak up about problems?

Tucker created a simulation of a nurse's tasks in administering medication to a number of patients. Certain errors were embedded in the experiment - such as missing medication for one patient - as well as opportunities to work around the errors - medication for a patient that wasn't on the nurse's list (i.e., "extra" medication) or extra equipment that could be used for the task, but may be considered inappropriate (e.g., a syringe with different unit markings). This is an example of a complex operational process.

As folks such as Amy Edmondson (a frequent collaborator of Tucker’s) and Deborah Ancona have written, working around problems without reporting them obscures larger process issues, reduces the learning of other employees, and can even contribute to much larger disasters.

While we’ve written often about people’s unwillingness to report problems due to their self-protective instincts to avoid criticism and blame, Tucker adroitly focuses in another important issue: that management’s drive for high productivity is in direct conflict with the value of reporting problems quickly.

Tucker's paper is loaded with insights and observations about how humans deal with process issues that come up during the work day, and it'll take us several posts to cover the bases.

Here's the first insight: in her pilot test, Tucker found that the problems she had engineered into the process had a major impact on patient treatment. Only 36% of the participants (all professional nurses) successfully worked around the problems. The remainder refused to work around the issue, or did the workaround improperly.

The workarounds were in one case nontrivial (requiring the nurses to convert from one unit to another) and in the other created downstream problems (borrowing medication from another patient who didn't need it right away).

Nonetheless, these results are striking. Nearly 2/3 of the "patients" did not get their medication or got an improper dose (in certain cases 10x the intended dose). One can imagine how, in a busy hospital setting with nurses responsible for large numbers of patients, and much transfer of responsibility across this supply chain, these errors can happen and not be noticed as part of the bigger picture.

The next question is, how did the nurses do in reporting these issues so that the root causes could be investigated and fixed? That's the subject for our next post on the topic.