Tech Implementation Failure Cost Me My Job

Anon - At least you have experience of failure to help you know what not to do next time. Thanks for sharing your insights. Too many folks are too proud to admit their defeats. Company I worked for over 2 years ago, just finished a few weeks ago implementing an ERP convergence with another software, that was started 2 years before I left. Total time investment of 4 years, multiple programmers, hundreds of thousands of dollars later they have something relatively similar to what they want. ERP implementations and customizations are rarely a 6-month process.

Also, be patient the whole time.

Something I would add to the list, research what other companies in your sector and revenue range are using, then adjust slightly for revenue growth. For instance, if you're a small general contractor with the growth potential, don't buy the box version of QuickBooks, get something like Timberline, Foundations, or something comparable.

I have seen ERP failures also. Some more for your list:
-Don't try to replicate everything from a legacy system.
-Don't put people on the ERP project that have only worked with the old legacy system

Great list and sorry for your outcome. As someone that evaluates, selects and implements 10-15 packages per year, we often consider the following:

1. an ounce of package selection will save you more than a pound of implementation
2. package selection and implementation with out streamlining your processes is one of the best tasks you can do to increase your probability for an OTIFNE (on-time, in full, no errors), implementation.

Excellent thread – and an important topic - thanks. I have been involved, in some regard, with 200+ implementations over my career. Anyone who has been on the implementation side for any length of time has seen project failure. Your thought about this experience benefiting you and helping you find your next position is excellent – we all need some failures and scars in our career.

Some things I would add to your list:

1) Get written requirements up front. This can be based on a best practices approach (template) or unique to your company – but it needs to be done. If no one in the user community can define what they want it will be impossible to deliver. It is impossible to manage to a moving and undefined target. This will help you with managing scope creep and other change in your project.

2) Focus on business goals and not systems to start. People in your company may have done something one way for a long time. However how they do it is not the business goal – the business goal (why they are doing that) can be achieved multiple ways – and often should be reviewed.

3) Document business processes. This one can be optional – but the bigger your company and the more departments involved with your implementation the more critical this becomes. The best way to leverage ERP solutions is to match them up – as much as possible – to your business processes. Sometimes your processes will change due to the system change, sometimes they should change, and sometimes this will help with the decision making during the implementation. Certainly it is visual / flow oriented method to describe business steps and objectives.

4) Consider your organization state. If the organization is in a significant state of change (for example you are putting in a new system because you are spinning out of a new company or just made a large acquisition, or you are significantly ramping as an organization, or whatever) the implementation will be harder. All implementations stretch and strain existing staff – when other factors are doing the same you need extra help and your project will cost more.

5) Do not except non-involvement. If one department isn’t available for the implementation – say manufacturing operations has no time for the tool they will end up using – do not move forward to help them. If this issue can’t be resolved by commitment from internal teams then clearly identify this issue – add a budget item to the project (temporary staffing for operations since they are too busy) – and hold them accountable publicly and on budget. Nothing will kill you more than armchair reviewers who don’t participate in your process.

6) Think about systems strategically. Customization is expensive – maybe not up front – but certainly over time. You need to invest in resources to do and maintain the customization, you need to invest in industry knowhow to stay current, and you need to retain this talent. You will be a user community of one – so when you customize it should be minor / non-material, or reporting/output oriented, or strategic to your company (it adds value beyond the cost of doing it). Most companies are not competitively unique in every aspect of their business – strategic customizations should only be used for competitive advantage.

7) Build a change management process into your approach. This can be casual (weekly meeting with mutual commits from everyone) to more structured. However if you run into something that has a business impact (data will be reported differently, etc) it is best to make that visible before you go live.

8) Remember as the project leader you are ultimately accountable – so you need to use your expertise to say no at times. Reality is you can do exactly what people ask you to do, the result is bad, and even though you did as asked you will be the one accountable. This can be extremely challenging – however it will make a huge impact on your success or failure.

Bob Scarborough
www.tensoft.com

Great discussion, everyone. I've only had the "opportunity" to be a part of 2 ERP implementations at prior employers. Both of which were great learning experiences for me. I would add a couple of minor points to this discussion.

1. Get all stakeholders in the room early to identify the requirements. This will also allow for a discussion of what items may actually be "nice to haves" vs true requirements.

2. Understand that being part of the core implementation team should be considered a full time job and the primary areas impacted need to be willing to give up the head count for the entire period of the project (plus an additional 6 months for delays and scope creep)

Anon, failure is only failure if you don't learn from what went wrong. Being offered an opportunity to take what you've learned to another company is proof that you didn't fail! How many times did it take Edison to get the light bulb right?

While not specifically ERP implementations, CFO.com just talked about this and I recently did a SmartBrief poll asking about it ...

Seven in 10 technology projects are considered failures.
Nearly one in five projects will be cancelled entirely.
88 percent of projects exceed deadlines, budget or both.

All the best with your new gig, Anon!

I would add that everyone needs to understand it is a project that will involve the entire organization. It is not an Accounting/IT project. You hit on the other, i.e. it is going to cost more and take longer than anyone expects.

Anon - Another idea is to form a project team from your best and brightest and make that implementation 100% of their job. Also set aggressive deadlines and think hard and long before embarking on customization

Failure is often the best sign that learning and development are taking place. I once had someone challenge me on the ski slopes one day about going down a different hill since I "was not falling down enough" on the one we had been doing!

One of the sticky areas, where objective, non-vested interest intervention is needed is up-front in the requirements definition phase. A lot of times the user group will specify detailed requirements that mimic the old way they do things, which then straitjackets the selection and implementation processes. Since this occurs early on, often without external assistance, it can be hard to catch and challenge, since there will be a general unawareness of what alternatives might exist that are better. Finding out later doesn't help, because by then the requirements have become embedded in the scoring and evaluation and regarded as sacrosanct.

Jeff Henley, the Chairman and former CFO of Oracle, gave a talk at FEI-Los Angeles last year. When he oversaw the global implementation of Oracle software at Oracle and all acquisitions (particularly Sun - which had a disastrous pre-acquisition implementation) he emphasized a few points for success:
(1) Plain vanilla implementation - avoid customizations. This required modifying workflow. If I recall correctly, Oracle even terminated a few teams that refused to get on board with this.
(2) Single instance of software - to minimize maintenance and allow scalability of the business.
(3) Single, shared data warehouse - to have a single source of "truth."

Also consider a strong, experienced implementation partner that is independent of the ERP vendor and engage them early in the process of requirements determination and selection. It's better to redesign non-strategic business processes to fit a vanilla implementation than to customize, as has been echoed so many times.

A very good set of responses, but one very important item seems to be missing: you have to realize that an implementation involves tradeoffs. When you implement, some stakeholders will be served well; some will not. Some will even be hurt.

A good project manager doesn't just manage the tasks; he makes decisions about the tradeoffs. If the manager doesn't do this and do it correctly, he or she will fail.

You can see how this enters into points made frequently above. "Get all stakeholders involved." Of course, but mere involvement is not enough by any means. "Get each stakeholder to understand (and accept) what he or she is getting and what he or she is giving up.

"Don't do customizations." A customization is usually required because a stakeholder doesn't want to give up on something. If that something is critical, then "don't do customizations" is terrible advice. If that something is merely a convenience, then "don't do customizations" will be correct. The real trick, though, is that somebody--not the stakeholder, but the project manager--has to figure out which category the customization falls into. (Hint: 94% of the time, shouldn't be done.)

"Get written requirements/do a process map/don't (or do) mimic the old ways." If you think of an implementation as a political process, you realize that all of these are deeply flawed, because you should be negotiating the tradeoffs only after you understand them, and when you're doing the process maps or replicating the old processes or inventing new processes, you usually don't yet understand them. Working from a pre-designed process map (usually provided by a consultant 'who's been there and seen that' but is in fact trying to reduce his costs) is a bit like enacting a law first and then having the legislature decide what they think of it.

Disclaimer: I don't work for any software company or consulting company that does implementation work. I'm one of those disinterested guys mentioned above.

Hi All, i also think it a best fit for a good project management be in place. kick off date and timelines should be well spelt out and closely monitored. UAT levels should be evaluated and well documented.

Avoiding project creep and avoiding a lot of customization are big issues. Try to figure out what you absolutely have to do to be successful and focus on that. Do not assume that your work flow is the only one that will work.

Thanks for this posting. I'm in the thick of it right now. I would add:
- Be weary of buying and implementing the new version that is not yet fully operational yet--some of the functionality you would normally expect to be present in the new version that was present in the old version will not be present due to unanticipated glitches by the software developer. Those could take months to fix and slow down your implementation.
- If your implementation depends on a few key enhancements being ready on time, assume that they will be late and plan how that might impact your implementation. Make sure the VAR or Software vendor is fully accountable and ideally there should be predefined penalties and remedies if deadlines are not met.
- If you are being assisted by consultants from the VAR or software provider, make sure they are fully competent quickly, and insist on changes in staffing ASAP if any are not. The sooner you have the right team in place, the sooner you can be on track.

There are many excellent ideas in this thread. I'd add this thought: there's obviously more than one right answer in terms of the software to implement, as it's unlikely that there's only one ERP system out there that would work well for a specific company. Once you have a short-list of possible ERP systems, learning more about the vendors themselves is strongly recommended. As part of that, consider asking prospective vendors for a long list of customer references.

Anyone who's been in business for more than a year or two can give you 3 or 4 references. I'd tend to take those first 3 or 4, toss them aside, and request another 10 (or 20) references. That often eliminates some potential vendors immediately - they cannot give you any additional references. I'd then contact several of those, and drill down in detail on implementation processes, budget vs. reality, and ongoing support dynamics, more than on the software itself - because you'll have to judge the software fit for your business, but you can certainly learn about the vendor's competence, integrity, and quality of service from the experiences of others.

I agree with all the points presented by other contributor comments. All are very good point to assure readiness and proper execution at point of ERP conversion.

I have been involved in multiple implementations and upgrades. I have been fortunate to have a successful track record based on a combination of skill and luck. One thing that I tried to assure, whenever possible, is to have a defined path back to prior tools should a disaster occur at roll out. A retrievable capture at point of cut off of prior tools and data is an inexpensive insurance policy should the worst scenarios play out at “go live”. Additionally, part of the good project plan is to define the trip point that would drive a retreat to prior tools allowing time for managing and repairing glitches in the new tools discovered at “go live”.

Of course, a temporary retreat to prior tools would be painful and costly, but would potentially avoid crashing the business should the new tools, procedures, and personnel readiness prove to be flawed. An example of a preset trip point in a manufacturing environment may be something like the inability to transact and execute customer shipments within 5 days of “go live”. If a retreat strategy is not possible or not executed on a timely basis then customer suffering could extend multiple weeks or months, and can result in long term loss of customer loyalty and revenue generation potential.

A good General in a military campaign, whenever possible, needs to have a fully developed and trip point driven exit or retreat strategic plan ready for execution should unforeseen disaster strike. If an exit or retreat plan is not in place that alone may be cause for delay. Just ask General Custer. It would be much better to execute a planned retreat and regrouping of resources then to simply press forward in a failure mode that that potentially can crash the business.

Of course egos have to be put aside and “blood and guts” approaches have to be restricted, but in the end a strategically planned delay of implementation within a short period after “go live” might be the least expensive alternative. The execution of a strategic retreat plan may in retrospect be seen as a bump in the road. Far better than driving your business off the cliff due to implementation failure resulting inappropriate roll out of new ERP tools.

I have been fortunate to have never had to execute a retreat to old ERP systems, but I had tried to have a clear path ready with trip points defined should disaster strike at “go live”. I would probably contribute my track record to fat dump luck and much as skill. But the critical goal for new ERP implementation should be to protect the customers base and the business revenue stream above all else. Sure a few folks may have to sacrifice their jobs if retreat is necessary, but having a strategic plan in place to retreat and save the business would be far better than a cliff dive.

When implementing an Accounting System the rule of thumb has always been to run parallel systems.

Wow, can this bring a company to its knees. Think of duplicated activities, overtime, fatigue.

Try this next time.

1) Try to time the implementation around quarter ends. I.e., calender year, testing can being in June

2) Start loading the new system based on ending balances/accounts, etc at the last Quarter End. (March 31)

3) Then input all transactions that occurred from Quarter end to present (April, May & June). You need your numbering system to match exactly (so check 123 is for Bob in old system and New system). As you finish each batch of entries, you notice procedural errors, programmatic errors, pitfalls, areas you want to improve upon. etc. A months worth of entries takes a fraction of a month to recreate.

4) If all goes correctly, April months end is the same (adjusted for any changes you built into the new system), as well as May and then finally June.

5) If all goes correctly, as of August 1 you off and running on your new system. Obviously problems found could reverse or retard the timeline.

This is an excellent discussion which I have forwarded to the CEO and CFO at our company which needs to migrate away from QuickBooks, quickly. It also echos my experience at both implementing and correcting implementations.

Some really good points raised here and good highlights from ANON.

Understand why you're replacing your system or implementing the new system, convince yourself and then embark on a PR campaign internally to communicate the objectives, rationale and reasoning behind the impending change. So often, the adoption of something new is not transparent or well understood. The campaign should cite very obvious and relevant examples of existing issues or problems with legacy processes and systems that you hope to address. Y2K was an obvious one, but there must be others to justify new renewals.

My view is that successful initial implementations are those where the functionality is installed in a vanilla fashion without customization. - This is very contentious because this often means you have to retain some legacy business practices and technologies - the plan should be ultimately to rework or realign these but initially this may be perceived to create more work and deem the project initially sub-par or a failure. At the same time, ensure that you really avoid change orders, this makes it incumbent on all those involved (hopefully your best and brightest) to really understand what is going to be adopted and how well it aligns with the business, where there is misalignment, make concessions or change the process!

Change Management is crucial, particularly when you have a more established and older workforce and systems. People need to be encouraged to rethink the processes that they use and a whole program around change management and re-education is key.

Finally, remember that you can have the best software product, the best integration partner, the best implementation methodology, the strongest PMO and the deepest pockets, but a good project implementation is dependent on people, pick your people carefully, if you feel midway that you made some inevitable bad choices, cut and replace them and move on, don't dilly dally or shy away from making unpopular decisions. The same is true for the integration partner, make sure you get to veto the assigned people if the fit, confidence and apparent competence are in question.

My employer did a MAJOR installation of Oracle ERP about six years ago before my arrival. The IT Director was out on a medical issue for about six months. The project was not effectively managed (not that he is an effective project manager anyway). It was, and continues to be, a major fiasco.

I managed a much smaller implementation of a CPM solution and it came in on time and under budget. A big part of the reason is that it was much smaller. Another reason is because I made it clear that there wouldn't be any mission creep nor budget adjustments for the consultants. They would get exactly what we defined in our SLA.

It's unfair that people get fired for something like this which happens so regularly but I support people getting fired for failure.