I made a mistake yesterday. Although I started with the best of intentions, my error was apparent within minutes. In fact, as soon as my first mouthful hit my digestive track, it was obvious that I had eaten food that was on the verge of spoiling. Unfortunately, by the time my brain processed the bad news, I was a few mouthfuls into my gastric disaster. I’ve been paying for my error ever since.
Usually, nature provides an excellent early warning system to keep us away from spoiled food. Bad smells and visual signs of spoilage are clear indicators that we should give up on that food and try something else. In my case, the food looked fine and didn’t smell bad. Consequently, I didn’t realize that I was on the road to pain and should turn around immediately.
We’re regularly told that fail fast and often are key to successful Enterprise 2.0 deployments. Those of us who are trying to do it right look earnestly for signs that our current effort may be in danger of riding off the rails. We check usage, we seek out anecdotal evidence, we read the tea leaves. But what if we can’t tell if we need to quit? What if the signs are ambiguous or, in the case of my bad meal, misleading?
Dion Hinchcliffe, Peter Kretzman and Michael Krigsman have been thinking about the role of failure in IT projects generally and Enterprise 2.0 deployments specifically. I’ve provided links below to some of their writing, as an amuse-bouche. However, I’d encourage you to dive into their blogs. You’ll find lots of learning there.
In the meantime, I’ll leave you with the following observations from Peter Kretzman’s blog post, The IT project failure dilemma: how to get early warnings:
One of the problems, as I’ve pointed out before, is that it can actually be surprisingly difficult to tell, even from the inside, how well a project is going. Project management documents can be appearing reliably, milestones met, etc. Everything looks smooth. Yet, it may be that the project is at increasingly large risk of failure, because you can’t address problems you haven’t identified. This is particularly so because the umbrella concept of “failure” includes those situations where the system simply won’t be adopted and used by the target group, due to various cultural or communication factors that have little or nothing to do with technology or with those interim project milestones.
Moreover, every project has dark moments, times when things aren’t going well. People get good at shrugging those off, sometimes too good. Since people involved in a project generally want to succeed, they unintentionally start ignoring warning signs, writing those signs off as normal, insignificant, or misleading.
********************************
Further Reading:
- Dion Hinchcliffe, 14 Reasons Why Enterprise 2.0 Projects Fail
- Michael Krigsman, Six Types of IT Project Failure
- Michael Krigsman, Three Truths of IT Success
[Photo Credit: stevendepolo]