Too Busy to Plan?

Lots of time since my last post, having been on the road and working with clients. 12,000 miles in two weeks - surely not a record, but a decent amount of air miles nonetheless. And during my travels there was apparent at one particular engagement a resistence to good project planning. Remarkable. A one-year project, now in month twenty, is off the rails. The client is unhappy. The vendor defensive. The implementation in a sort of controlled chaos. The prescription, after a week of solid assessment (staff interviews, documentation reviews, product demos, etc.)? Add a little discipline to the process of delivering this very complicated product. The response? We're too busy to plan!

This blows my mind, really. We all know the definition of insanity is to continue to do the same thing over and over again and expect a different result each time. Now there's a classic example.

Cut to a recent dinner with prospective clients (let's call them Tom and Fred) contemplating hiring a new systems vendor. "Why do you want to change vendors?" I asked, genuinely interested in what motivates companies to become so frustrated they're willing to scrap millions of dollars of investment, only to spend millions more for a replacement. "It takes four months, literally, to get anything modified in the system," was the response. Again, the issue is poor planning, poor execution and an abject lack of discipline. "We were encouraged with the speed at which they began the project," remarked Tom, "but then the thing just fell apart." Heard that one before? I have.

Cynics abound in the world of technology. The challenge is the knowledge held by the technical elite is often so obscure and difficult to grasp, that the businesspeople who have to work with the systems they create almost completely defer. Add the unbridled arrogance of a talented technologist and you get a recipe for disaster. That's not to say they're all bad; the Alistair Cockburns and Suzanne and James Robertsons of the world - probably the world's foremost authorities on requirements gathering (from a very practical perspective) - give us all hope. Those who subscribe to their methodologies - and no, not verbatim, as that's entirely impractical - but those who understand the value a framework, a proven approach to attacking complex systems implementations, brings to such projects, have a decided advantage.

My advice to the client at dinner? "I'd rather you get a little frustrated with the slowness of implementation up front given the thoroughness of the planning and requirements gathering processes, than be downright angry after months of missed deadlines." Speed at the beginning of the project might be encouraging, but it could also be a warning sign for things to come.