A Fortune 500 manufacturing company spends millions attempting to implement a new enterprise resource planning system. Across the globe, a marketing firm with only 150 employees builds and tries to implement proprietary customer relationship management application.
For two very different companies doing two very different things, the outcomes were virtually identical. In each case, the organization failed to activate and utilize its system as initially conceived by senior management, adversely impacting each business.
And these two organizations are hardly alone. On the contrary, research indicates that more than three in five new systems fail. Many miss their deadlines. Others exceed their initial budgets, often by ghastly amounts. Even systems activated on time and under budget often fail to produce their expected results and almost immediately experience major problems.
While the statistics are grim, there is at least some good news:
These failures can be averted.
Organizations often lack the necessary framework to minimize the chance of system failure before, during, and after system implementations. Why New Systems Fail provides such a framework with specific tools, tips, and insight from the perspective of a seasoned, independent consultant with more than a decade of related experience.
The book examines in great detail the root causes of IT project failures. Detailed case studies, examples, and lessons from actual system implementations are presented in an informative, straightforward, and very readable manner. More than a theoretical or technical text, the book offers pragmatic advice for organizations both deploying new systems and maintaining existing ones.
After nearly a decade of working on large-scale IT projects, I had reached a crossroads. I had kept repeating the same exercise: organizational politics, data issues, technophobes, questionable practices by software vendors and consultancies. The end result: expensive and frustrating system failures.
If I didn’t write this book, I would have needed to see a shrink.
I wrote about what I knew. It’s pretty common for a non-fiction writer to do this. I had seen so many IT projects blow up, why not write a jargon-free book about them? So I did.
Published in February of 2009, the book didn’t do particularly well until mid-July of that year. A Slashdot review catapulted the book to #91 on Amazon that month. I nearly broke my finger hitting the F5 key (refresh) on my browser, watching that number climb to amazing heights. As Bill Murray said in Groundhog Day, “That was a pretty good day.”
The original subtitle was “Theory and Practice Collide.” In hindsight, this was great imagery, but not too SEO-friendly. The original cover is on the right.
Learning from a historically awful IT debacle.
A good read and as insightful as any I have read about enterprise software project management and the obstacles to success.–David F. Carr, independent journalist and former writer for Baseline Magazine ”
Projects are multi-dimensional. They’re technical, political, financial, personal, emotional, logistical and more. Great project leaders anticipate these dimensions before the project begins. Read Phil’s book to recognize the pitfalls and minimize the impact of them on your organization and your career. You can’t work the plan until you’ve really planned the work.–Brian Sommer, founder of TechVentive and Vital Analysis. ”
This book offers practical advice on why IT projects run late, over-budget, or do not achieve planned results. The framework is clear and the examples compelling, making this book a manifesto for success.–Michael Krigsman, ZDNet Blogger on IT Project Failures ”
Simon’s book should be required reading for all CIOs, IT project managers, and involved business managers prior to starting any such enterprise project. It’s clear that Simon knows exactly what he’s talking about and knows where all the bodies are buried.–Bruce Webster, Principal and Founder at at Bruce F. Webster & Associates ”
Simon's book honestly portrays the many small, but crucial, aspects of system failures that too many people in the industry don't want to admit.–Jim Harris, Founder of OCDQBlog, independent consultant, speaker, and writer. ”