Trying to Practice What I Preach

Posted on 13. Jan, 2009
Categories: Consulting, Enterprise Systems, IT Project Failures

One of the points that I make in Why New Systems Fail is that organizations have a choice when faced with project delays. To awkwardly quote myself:

Usually, system functionality is not a binary; systems have levels of functionality. Features can be enabled at different points. If a module or significant feature of a system does not make the cut for Phase I because of delays, budgets, or lack of successful testing, then the organization should revisit it in Phase II.

I had to face this reality this week as a result of a “miscommunication” between my publishing house and me. (I am intentionally using the passive voice here, lest I anger the very people who are working on my book as we speak.) Suffice it to say that my publishing consultant and I had a difference of opinion on the book’s release date.

This divergence left me with three choices. I could:

1. Significantly modify the content of the book to meet my mid-February deadline. This would have allowed me essentially no time to review the final format and content of the book, increasing the chance of errors.
2. Accept the “compromise” of a two to three week delay.
3. Opt to go to another publishing house and hope for the best.

I chose the second option.

Am I happy about this unexpected delay? To put it mildly, no.

That which doesn’t kill me makes me stronger, as they say. What can I learn from this? How does this relate to system implementations? While the scope of publishing a book and implementing an enterprise-wide system are miles apart, there certainly are some major parallels.

As I contend in the book, organizations should go live with well tested systems, even if that means a short delay. It’s much worse to activate a system (or, in my case, launch a book) without adequate testing and review time. The additional time allows for errors to be fixed. What’s more, in both cases, that bell really cannot be “unrung.”

Second, by planning in advance for unexpected issues, I will be able to still meet my general deadline. I didn’t make any commitments that will hinder my overall objective. Senior management should heed this advice during system implementations and activations.

Third, it’s better to “fail” mildly than spectacularly. Could I have pulled off option one? Perhaps, but the risks didn’t justify the rewards. The publishing house is not going out of business on February 15th. It’s better to have a short delay with a successful launch than a scheduled launch with the likelihood of major issues.

Related posts:

1. The Technology Adoption Life Cycle
2. Cover for New Edition of Why New Systems Fail
3. The Practice Mentality
4. Doing Things Right and Doing the Right Things
5. The Role of the Project Manager on a Failing IT Project

Tags: Implementations, Why New Systems Fail