Creative Breakthroughs And Project Management

I recently had a chance to read a paper by Allan L. Scherr of IBM on managing highly effective software projects. In brief, the premise of the paper is that creative breakthroughs can be induced by setting a highly aggressive schedule and doing whatever is necessary to meet deadline. Basically the method calls for inviting project participants to commit to delivering quality work on or ahead of schedule.

Photography by fdecomite.

After the project participants are on-board, the idea is to make a declaration pertaining to the delivery schedule. “The project will be completed within 18 months using only the staff on-hand and at 70% of the original budget estimate.” Like Babe Ruth pointing to the fences before a homerun, the managers in the organization call their shot. Every member of the project commits not only to the details of the project delivery, but also to whatever else is important to each member of the team (vacation time, limiting overtime, etc.)

Next comes the inevitable slippage. When project participants start to notice that their results are not aligned with the desired schedule this is called a “breakdown”. As counterintuitive as it might seem, a breakdown is actually a good thing. The paper asserts that only when a breakdown is encountered can a “breakthrough” occur. Inducing these breakthroughs is the entire reason behind this new process.

Where There’s A Will, There’s A Way

So, in brief then, a breakdown is basically a gap between the declared/expected results and the actual progress of the project. A breakthrough is what happens when creative and committed people force a solution to the breakdown, almost by pure force of will alone. It’s like that old saying “where there’s a will, there’s a way.”

Upon first read, the process seems pretty fluffy, actually. I mean, what are we really changing here? As far as project ownership is concerned, how is inviting people to make a commitment any different than ordering someone to make a commitment, honestly? It just sounds more polite. I mean, who is that person who refuses an invite to an aggressive project schedule? In most organizations, this person is probably labeled as “not a team player”, and eventually cycled out.

What actually does seem significantly different about this approach is that the project team realizes that they are a team from the get-go. Anyone that has had the displeasure of working on a large and failing software project probably has encountered the situation where several groups are firing on all cylinders while a single group encounters a roadblock and holds up the entire project. Typically, in this situation, the political risks involved in throwing resources at assisting the failing organizational unit are too high to offer a lending hand. It is akin to a career kamikaze mission. After all, why throw yourself under the bus when the safe thing to do is sit back and keep a safe distance from being associated with failure.

Going To The Moon

In contrast, managing for breakthroughs in software projects inspires team members to work in an almost socialist atmosphere. All for one and one for all. It also inspires team members to work creatively to solve problems. The paper specifically references one of the most famous declarations in American history – when John F. Kennedy declared that the United States would send a team to the Moon and back before ushering in the 1970s. JFK announced “I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the Moon and returning him safely to the Earth”. This goal was achieved on July 20, 1969 by Neil Armstrong and Buzz Aldrin as hundreds of millions around the world watched with bated breath.

The Apollo mission is still considered one of the most monumental successes of the human race, but it also suffered from its share of breakdowns. Three astronauts lost their lives in the early Apollo 1 mission due to engineering failures causing a fire upon launch. Then there was the famous Apollo 13 situation where commander Jim Lovell along with fellow astronauts John Swigert and Fred Haise had to abort their visit to the moon, narrowly escaping from death’s grip to return to Earth. The Apollo 13 mission is a fine example of breakdowns leading the way to engineering breakthrough.

Tom Hanks plays the character of Lovell in the Hollywood version. The movie barely glosses over the engineering genius that was required to safely return the crew to our home planet unharmed, but the message stands. Only when smart teams are able to think outside the box under high pressure situations are these breakthroughs are possible. The complete details of the breakdown and the eventual breakthroughs of the Apollo 13 mission are outside the scope of this article — but in brief, an explosion caused the team to abort their Moon landing, and engineers at ground control in Houston had to scramble to find a way to get the team home in one piece. One particular breakthrough which was highlighted in the movie involved jury-rigging the Lunar Module’s carbon dioxide scrubbers to provide enough air for the team to breathe during re-entry.

Five Times Faster, Better, Bolder, Bigger

One particular point that should be made is that it may be dangerous to speak in terms of productivity gains in relation to the normal operating baseline. The paper continuously makes assertions like “using the process, the teams realizes a three-fold increase in productivity versus the normal business-as-usual process”. This is dangerous for two reasons. Firstly, it may not be the case that the organization has been operating long enough to have even developed an adequate baseline to use for comparison. But perhaps more significantly, these metrics can be dangerous because “three times as effective as business as usual” doesn’t really mean much. It’s so fuzzy. Ultimately, you must deliver ahead of schedule, under budget, and produce better quality work for these metrics to be truly meaningful. It’s too easy to say “we delivered 6 months ahead of schedule” while overall quality has suffered and the team has blown out the budget.

Ultimately it just feels like the value in this process is in inspiring and motivating the team. Like Fredrick Brooks said in The Mythical Man Month “There is no silver bullet.” It seems that software project tradeoff matrix still exists — time, quality, or cost — Pick two. Hopefully your takeaway from the paper should be about building highly-motivated software teams. Teams that believe so strongly that excellence in engineering is possible. That obstacles can be overcome through ingenuity. That a truly fulfilling work-environment is desirable and achievable. Let’s stop looking for silver bullets and start inspiring highly productive teams.