Published in Spectrum Magazine, May/June 2007
Since the dawn of time, people have been looking for that all-elusive “sure thing”. Gamblers look for a sure thing as a mystical path to the ultimate jackpot. Teenagers look for a sure thing in every aspect of their lives to ensure they can maintain perception, status, and whatever else teens crave. Even business people – or perhaps especially business people – look for a sure thing in making the perfect deal to set the business up for the future. Yet while everyone searches, that old bit of sage advice tells us that the only sure thing is that, well, there is no sure thing.
But what about a good strong likely? What if something was so likely that you could accurately predict a result most of the time? And what if by accurately predicting that result you could put a TON of money in your pocket? Would you want that skill? More importantly, would you USE that skill?
As a technology consultant and educator I have found something so likely that by observing a few key indicators one can accurately predict the end result most of the time. But we’re not talking Vegas; in fact, there’s a lot more money at stake than what a typical person might win (or blow) in a Vegas weekend.
Believe it or not, we’re talking about Information Technology project failure. Observe any one of the following indicators and there’s about a 20% chance of project failure. Observe two and it jumps to 40%. Should you actually be so unfortunate as to observe all of them at the same time, be assured: failure is a near guarantee.
Indicator #1: No clear definition of the problem
We’ve all heard the story of the boss who came in to the room of programmers all excited after having closed a great deal. “But what is the project?” asked one of the programmers. “I dunno”, responded the boss, “but you guys start coding and I’ll go see what the customer wants”.
Though we chuckle at this kind of story, perhaps there’s some truth in the every day real life of a typical IT department. All too often coding begins before there’s a clear definition of the problem being solved. Then when the problem actually gets defined there will be a lot of meetings and even more stress in adjusting – or scrapping – the work completed to date.
Rework is expensive. Starting over is even more expensive. Even worse, when something truly needs to be started over but is left to languish through rework, there’s a good chance that buckets of money are going to be wasted.
Indicator #2: No clear understanding of the solution
Okay, so maybe the problem is well defined, and maybe there’s even a solution on the table, but does everyone involved understand how the solution actually solves the problem? It’s one thing to know the solution to the problem of 4 – 2 = ?, but the answer is largely meaningless without understanding why that specific solution is best for that specific problem.
An IT manager was walking through the halls of a university when he was approached by a Dean. The Dean asked the IT guy if he had something to keep a record of important academic meetings. The IT guy proceeded to describe the latest whiz bang conferencing service, how it could record the meetings, cross-reference the notes from the participants, and even publish the meeting on the web for the world to review. The Dean, looking somewhat puzzled, replied “Let me rephrase: Do you have a pencil?”.
Indicator #3: No clearly defined path between problem and solution / no milestones
Understanding the problem and solution is important, but it’s equally important to know how to get from one end to the other in the straightest and most direct path possible. Yet, all too often the best laid plans get derailed by meandering. Basically, when all you know is the beginning and end, how can you be assured that every step is going in the right direction?
Basically, milestones are the answer to that all important question “what’s next?” Make that next step unclear and it’s like meandering though the living room at 4am; you never know when someone’s moved the coffee table, and it’s likely going to hurt.
Indicator #4: Inadequate training
“Doctor, the patient is ready”. Surrounded by a team of medical professionals, you’re just about to start counting backwards and drift off into a medication-induced deep sleep when you recall that you know nothing of this physician. “Doc”, you quickly ask, “have you ever done this before?”. “Well,” he replies, “not actually. But I read a book about it once!”
Many complex IT projects are staffed by people with exactly this level of experience. Certainly there are excellent technology books and resources, and one can learn a great deal from them. But what books typically don’t do is draw a map through the unexpected, and without an experienced tour guide the project can quickly turn into a walk through a minefield. By training with someone who’s walked that path before, you can save lots and lots of time, money, and stress.
Done properly training only has to happen once, whereas without training costly mistakes and meandering might happen again and again. If it takes a person 3 hours to do something that could be done in 10 minutes with proper training, which has the greater risk – to train or not?
Indicator #5: Deficient teamwork and/or communication
No matter how sophisticated the technology, people remain the key to making it all work. People have the problems. People define the solutions. People draw the path between the two. But past all these people, real people actually have to use the solution, otherwise the problem remains unsolved.
Throw the most talented people together on a project and unless they can a) work together, and b) speak each other’s language, much of that talent might not ever be leveraged. I’m amazed at the phone calls I get – sometimes a thousand miles away from a customer’s office – asking me to relay a message to another team member who might sit within a dozen feet of the caller!
Effective teams are comprised of people who know and understand what the other team members are doing. And even more importantly, they’re actually okay with the assignments because they know how each role fits into the overall project puzzle. By contrast, ineffective teams bicker about the smallest meaningless thing and are first to cast blame when anything goes wrong.
While this is clearly a 40,000 foot view of IT project failure, the fact remains that this kind of failure is significantly more expensive than success, and yet it’s a whole lot easier to achieve. So to ensure success we have to be on the watch for these indicators and take action before things start going up in smoke. Or better yet, proactively implement the exact opposite at the start of your project and watch how easy it is to get a fully completed project on time, on budget, and on target.
Kevin King is the President and Chief Technologist with Precision Solutions, Inc., a leading technology solutions provider in Longmont, Colorado. He can be reached by email at Kevin@PrecisOnline.com or by voice at 303/651-7050.