7 Speeds of Fast

Posted by Rich Crowley in IT, IT Architecture, management, planning, Project Management, Projects, strategy

I once read that John “Pieface” McKenzie, a Boston Bruin in the Bobby Orr era, described Orr as having “7 speeds of Fast”.  I don’t have the actual quote but I recall the context of his comment being that he was skating up the ice one game, thinking he was going pretty fast, when Bobby glided past him, going much faster, but appearing to be barely exerting himself.

The world we live in almost always puts a premium on speed.  Business wants to bring products to market faster.  Patients want shorter wait times at hospitals.  The list goes on. (The comedian George Carlin once suggested basketball games begin with the score tied at 100-100 and the games be reduced to two minutes in length).  From a technology perspective, I’ve rarely met a business person who was wistful in their desire for IT to slow down so the business could catch up.  IT is almost always been under pressure to do things faster.  System response time needs to be instantaneous.  Batch windows need to be shorter.   Projects needs to get done more quickly.

Pieface McKenzie’s notion of “different speeds of fast” has been bouncing around in my head over the past several months.  I like it from the perspective that it emphasizes an almost universal need for speed (cue Kenny Loggin’s Danger Zone) but I also really like its acknowledgement that there can be different flavours of “fast”, and that perhaps this can be applied to project work.  Too often I see one-size-fits-all methodologies that get applied to project delivery, with expectations set on a single speed, namely “as fast as possible”.  I think this is limiting and dangerous.

Some projects could benefit from an explicit acknowledgement that speed of execution is paramount and perhaps in some cases even have this listed  as an explicit objective of the project.  Those familiar with a PMBOK-based approach to projects might suggest this implies that the triple-constraint variable “time” needs to be more heavily weighted than scope and budget.  I would argue this is too restrictive.  By speed of execution, I’m not talking about the target date of project delivery but rather the speed of the work getting done.  I can see all kinds of drivers for setting such a goal within a project.  Perhaps the project outcome is less known / understood up front, so getting to something, anything, even if the speed of execution results in a less polished outcome than by going slower, would be a positive.  Alternatively, if the half-life of the project deliverable is relatively short, and slower project execution means missing out on the business opportunity, full-speed ahead is a key project driver.  For projects where the outcome needs to be more precise, or is more foundational in nature and execution speed introduces risk to usable deliverables, perhaps the execution speed should be acknowledged  as needing to be something other than as fast as possible.  This doesn’t imply going slow but it does acknowledge the side effects of going too fast.

Several years ago, Gartner proposed a pace-layered approach to application strategy.  The premise was that different classes of applications require different management and governance processes.  I like this concept and think it fits with this notion of different speeds of fast.  The challenge to PM’s (and sponsors) is to define early in a project how important speed of execution is, given the business opportunity / goal being pursued and the underlying technology environment at hand.  I like the analogy that given a race car, and told to get from point A to B as fast as possible over two different courses, the driver would get there much more quickly over a long, flat stretch of route 66 than they would over a winding mountain road course.

“As fast as possible” is too often assumed to be the default desired project execution speed.  Instead, give some thought to “what speed of fast” is appropriate for the task/application at hand and build your project execution approach accordingly.  This will no doubt require some re-setting of expectations around how a “slower than maximum speed” is still fast when viewed in the proper context.