Your Enterprise Software Implementation is Going to FAIL!

And here’s why…

(Note: This is not intended to be a profile of any one customer I’ve worked with. Nor are the examples here verbatim of what I’ve seen. These are just general patterns I’ve encountered.)

I’ve been in enterprise software for 7 years now and although I’ve seen a number of really cool success stories using a number of different software solutions, it is the failures that seem to stick in my mind. Perhaps it is because I like to learn from failures to help my customers succeed where others could not that I tend to cling those memories of disaster. Often times it is not possible to pinpoint the source of failure, although most folks try to do so. Failure usually occurs for a number of reasons, many of which can be detected right at the beginning of the implementation. In fact, projects that fail are usually setup to do so (although not intentionally) from the start.

In the spirit of redneck comedy (or “blue collar”, although I think that term is more offensive, but I digress) you know your project is going to fail when…

If you are trying to implement more than one piece of enterprise software that isn’t “pre-integrated” or doesn’t have out of the box integration…

you are in for a world of hurt. The pain increases exponentially with each additional product in the mix. I’m not saying that you shouldn’t implement multiple pieces of software to form some sort of composite application. I’m saying that if you try and do this on the first release you are taking on a lot more than you can probably chew. Why not break the project into several iterations? Breaking down the implementation by doing a short release cycle with one product first, then adding a second component in the next release followed by incremental enhancements until everything is integrated is much more pragmatic. I know this sounds obvious and I can’t tell you how many heads bob up and down when I mention this approach. However, very few organizations actually do this. Why? The thinking goes that if you try and integrate everything at once then all of the bugs will be discovered early on in the process so you’ll then have plenty of time to fix them along the way. It never happens this way because the complexity is non-linear. For example, the complexity of combining 3 applications isn’t just 3X, it is really 9X (man-hours, cost, etc) because application A and application B are twice as complex on their own and integrating them adds two more levels of complexity. Add a third product into the mix and you add one more product complexity plus two more integration points When you get to that level of project complexity (and the long timelines and huge cost associated with it) you’ll find that either you have the worlds most patient project sponsors, or the project gets cancelled.

If you choose to “go it alone” because you have “plenty of smart people” on your team to implement the software…

you are fooling yourself and setting your team up for failure. Because of this attitude you’ve only given your team one option; to succeed. When they don’t this will cause major backlash with finger-pointing going in every direction (mostly at the software vendor) and will cause some of your best people to leave your organization out of shame or frustration. As a manager, how can you have possibly gotten this far in enterprise IT without spending money on software implementation beyond your fixed labor costs? Hey, I get it, enterprise software I hard, really hard. That is why most software vendors have consulting services and have extensive partner networks. We want you to succeed and recognize the fact that you are going to need help, if just on your first implementation. Please take it. If you don’t, I’m really going to want to say, “I told you so,” but that would be in poor taste. Chances are, you’ve taken the training and read the documentation (more on that below) but in my experience that simply isn’t enough. Asking for help isn’t a sign of weakness, it is a sign of maturity.

If as part of the sales cycle you’ve only seen me, the only product expert you are going to meet (because you aren’t using professional services or an SI), twice, and the contract is already signed…

you are already weeks behind the knowledge curve. Generally, IT organizations are curious to learn as much about a piece of software as they possibly can before they have to go off and implement it. They will also try and take as much free knowledge as they can get their hands on. The smart organizations will figure out that I (and my peers) am a free resource to use and abuse until the sales cycle is complete. This means product demos, deep dives, workshops, sessions of stump the chump, and even proof of concepts (the latter being a blog post for the future) are all fair game to learn as much about the product, and my experience with implementations of it as, as possible. If the natural curiosity to learn is not there, or you are too busy to deal with this now (see below), or any of the many reasons why you choose to remain in the dark are keeping you from getting a brain-dump, you are in trouble.

If during the two meetings we had together (see above) you spend most of the time “fighting fires” or dealing with “production issues”…

you probably don’t have your ship in any sort of order and adding another piece of complicated software to the picture is only going to make things worse. What makes you think you can maintain a new application if the old one(s) keep breaking? Adding one more layer of duct-tape is only going to cause more stress to the already overtaxed system that you and your poor staff will have to deal with. Chances are, you’ll be fighting these existing issues all through the implementation of the new software, which means your team won’t be as focused on the new implementation. Today’s botched implementation is next week’s “production issue”, thus creating a downward cycle that will be very difficult to get out of.

If, after having explained to you the best practices for implementation and choose to go with a fully custom, non-standard, and non-recommended implementation on your first project…

then I hope you have deep pockets; because to actually get that beast into production you are going to end up paying a whole lot more than you initially budgeted for with a lot less delivered than was promised. Did you run that use-case by anyone with extensive product experience? Did anyone warn you not to make things so complicated on the first project? Do you have cotton in your ears or do you think you just have “really smart people”(see above)? The very first time you implement any software the KISS principle should apply. Keep It Simple, Stupid. What is wrong with getting that first one out the door, even if it has limited functionality that you can improve upon later? Won’t the quick win on your first implementation buy you more leeway down the road when you want to do more complicated things? I know I’m being rhetorical here, but I see this far too often and it just doesn’t make sense to me. I’d opt for a guaranteed quick (if simple) win over a potential disaster any day.

If you’ve asked me where the documentation is and actually intend to read it. Or, if you’ve asked me how to setup a comprehensive test framework to run the software through its paces before you start implementing…

you are on the track to success. Software vendors don’t staff teams of people and spend thousands of man-hours writing documentation just for giggles. Everyone knows engineers hate writing docs, so why do software vendors go through all of this effort? So that their customers actually read them to gain a better understanding of how the system actually works, what the best practices are, and what to avoid. It is amazing how many support tickets get opened that turn into documentation questions as opposed to real product bugs. By actually RTFM you will be in much better shape to not only implement the solution, but also so ask the right questions when problems arise.

Additionally, if you have the foresight to plan for QA on your implementation before promoting it to production (you do have a sand-box, test, and staging environments, right? Sigh.) you are probably going down the right path. Thinking about QA doesn’t actually mean you are doing it right though. Did you spend 90% of the implementation time doing development and are saving the last 10% for QA? How firm is that go-live date? Well, either your “firm” date is going to slip or you are going to release one buggy application. Ideally, you are doing test-driven development. But short of that you should plan on spending at least 1/3rd of the project in QA and performance testing (you do know how to performance test, right?) before promoting to production. If not, well, those bugs aren’t going to fix themselves.

There are a number of other reasons why it implementations fail, but I’ve already ranted for long enough. Keep in mind that any one reason is probably not enough to bring a project down, but when you start combining several of them together the snowball of failure really starts to grow and that in turn has the same chance of success as, well you know…