At Raven Intel, we measure Enterprise Software implementations and projects from the customer perspective–tracking schedule, budget, and customer satisfaction, among other KPIs.  We have amassed over 350 reviews and our database is growing every day.  We promote the positive reviews–but we certainly see others which are neutral and some which are…cautionary tales.

While one poor implementation review does not represent an SI or software, it does provide a way for future customers to guard against similar problems and learn from the previous experience of their peers.  At the end of every review, we ask the customer to relay any “Lessons Learned”.

Here are 7 thematic lessons learned the hard way from customers who have gone through it.

7.  Define the team upfront & know the process for decision making.

“Make sure project team is determined beforehand and the process for approval of key decisions is defined.”

“Ensure business stakeholders are engaged and available. Decision making often slowed the entire project down.”

“It is essential that all key stakeholders at the operations level be included in requirement gathering not just high-level management. Important details can be missed requiring significant delays and change orders.”

“A concrete project timeline is needed with key check in points and a plan to keep the project on track in spite of change orders.”

We’ve seen 40% of implementation projects are behind schedule, with a full 11% requiring 2‐4 times the
expected amount of time.  Decisions that require multiple-approvals  internally (and sit on someone’s desk) are one factor in a project coming in over-schedule.  Know whose approval stamp is needed ahead of time and get decision-makers’ approvals done as far in advance as possible.

6.  Partner due-diligence & research…make sure you know what you’re getting from the SI you hire.

“Interview consultants assigned to project and get their references.”

“Do lots of research about the partner you choose.”

“Shop around and talk to customers that went through the process. Ask lots of questions.”

“Check out a partner’s technical expertise thoroughly – not just that they are experienced with the software/vendor in question, but that they have completed projects that are the same/similar as you are proposing. Finding out that your partner has proposed a solution, based on their understanding of your requirements but a misunderstanding of the software’s capabilities can be a time-consuming and expensive path to travel.”

Raven Intel can be of great assistance here… If you’re unsure about a partner’s track record–let us help give you a bird’s eye view.

5.  You get what you pay for. 

Choosing a firm because they come in cheaper may spell change orders and additional expense on the back end. We’ve seen 39% of implementation projects are over‐budget, with 10% of those being 2‐3 times the expected budget.  We find those customers who chose an implementation partner on price end up being less satisfied in the end.

“You get what you pay for; spend the money to have the consultants train your HRIS/HR staff before the implementation is complete. A brief “knowledge transfer” after all configuration work is done is not sufficient to adequately support the system.”

“Include change management in implementation process; allow extra time in projects for discoveries that will happen.”

Ensuring that the firm you choose has done a thorough discovery will help minimize change orders later on.  Make sure you read the Statement of Work before you sign.

4.  Big-bang is rarely optimal (especially with multicountry roll-outs)

“Phase-in the modules one at a time.”

“Keep it simple.”

“Try to simplify current complex positive time procedures as much as possible before starting the project.

“A big bang implementation with 10+ countries was not the best approach in retrospect. We ended up moving to an incremental implementation approach close to original Go Live date.”

“Phased-in implementation of modules is better.”

Less is more.

3.  Challenge the status quo. 

“Don’t be afraid to push back on standard this-is-the-way-it’s-always-done processes, so you can fully understand the *why* behind it and if it fully applies to your company.”

“Take the time to evaluate your current processes to determine what should be changed and improved. Do not try to take current processes and just move them into a new system. When implementing a new major system always look for ways to improve the big ticket processes.”

A system change is the opportunity to rethink old processes.

2.   Build in extra time for User Testing.

“Assure ample time is built in for UAT  (user acceptance testing) and assume there will be errors and fixes that need to be done (build time in for this).”

1.   Project team change is NEVER good.  

“If the project manager is bad–immediately demand a new one.”

“Make sure (your partner) has solid resources dedicated to the project. We had 4 to 5 different project leads!”

While changing the project team composition is NEVER optimal, identifying and fixing team issues early is better than waiting until there are big problems mid-project.  We see lagging problems with a customer’s team lead are one of the leading indicators of project dissatisfaction.

Have you gone through an implementation recently?  What “Lessons Learned” would you share?