Five ways to destroy a software implementation
Liam Durbin, CIO of GE Fanuc Automation, writes in CIO magazine about five common scenarios that can cause software implementations to fail:
1. Just replace the homegrown system with a package—no need to involve the functional teams.
Saying “no” to customization is bitter medicine for your business partners. They will make contorted faces and whine ad nauseum. But it is for their own good. While most IT professionals understand the serious pitfalls of customizing package software, the business teams will not. You must help the functional project leader to understand these pitfalls so he or she can be the first line of defense.
2. Business leader wants it now! We don’t have time to find a project leader.
The scenario for me was a brand-new vice president who wanted a dashboard reporting tool. Eager to please and make an impression of being a “can-do!” person, I found it very hard saying “no,” or even “wait.” Now was not the time to introduce the new business leader to the elegant rigor of our toll-gate process. Now was the time to impress with action! I figured, what the heck, I know it is wrong, but maybe we can get in and out quickly, no strings attached. Eighteen months later we still had no functional spec and were still playing bring me a rock.
3. The IT person in this area knows the system better than anyone else. Let them lead the project from both sides
If your company makes refrigerators, it is safe to say that the engineering department knows the refrigerator better than anyone. Yet you won’t see businesses suggesting sales and product management and marketing do not need to be involved in new refrigerator development. In fact, it is a given that a business person will lead the effort and engineering will deliver the solution.
4. It is just a data warehouse—it doesn’t do anything! How hard is that?
The IT project lead must spend weeks with functional teams understanding sales and product hierarchies, territories, go-to market organizations, pole structures—poking on every exception that has been baked into the business over years. IT project leaders know how to ask the questions but we simply can’t do it alone. If you try to, your data warehouse will be clogged with code intended to fake the wrong business model into acting like the one you should have designed in the first place. It won’t scale. It will cost a lot to support. Spend the time with the functional experts to get the data model right and it will rain reports.
5. We will do even better—we will have several functional leads.
Multiple functional owners = no functional owner. Listen, one key purpose of the functional lead is to boil all the issues to the surface, get the right people in the room and drive to a decision. That is much easier to accomplish if one functional owner is empowered above all others to be the deciding vote if necessary.
Difficult or complicated situations sometimes tempt managers to rush in with immediate action, creating a highly visible whirlwind of activity for all to see. Unfortunately, knee-jerk responses can mask a situation's driving complexity, accelerating the momentum toward failure. These five scenarios represent half-baked reactions that don't properly address all facets of the particular problem at hand. And that's why they cause implementations to fail.