The Moral to the ICM Saga

Read Part 1 and Part 2 of this story first.

The blame cannot be put on one person. ABC Corp, the ICM vendor and the consultant all own some of the responsibility for the issue.

The entire situation could have been avoided if the requirements had been better designed. Requirements could have been better designed if the compensation plans had been completed with enough details. The vendor would probably have done a better job at scoping out the work initially or in certain situations may even have not submitted a proposal.

What can we take away from this story?

• Requirements cannot be fully defined unless the compensation plans are finalized. Requirements may be inaccurate or incomplete unless compensation plans show sufficient details and examples.
• An ICM solution cannot be selected unless the requirements are fully defined.
• Not all ICM solutions can handle very complex compensation plans (no matter what the vendor’s rep says). Some solutions are better suited for certain situations.
• Good requirements are the foundation for any IT project, mess up the requirements and the entire project will be shaky.
• Using an experienced consultant to help out with the requirements design, RFP writing and solution selection could be a good idea to select the ideal solution.
• Consultants and vendors alike cannot “always” guess client’s intentions.
• Mentioning or emailing a requirement is not enough, this requirement must find its way to the requirement document to ensure it is met by the implementation and properly tested.

The ICM Saga Continues…

It’s Thursday; meeting time. The vendor explains the requirements from the RFP did not accurately reflect what needed to be performed by the ICM solution. “Because the scope of the project did not include all this additional work, it will cost more and take more time to complete”, says the vendor calmly. “But your sales rep said it would not be a problem!”, exclaims the comp director of ABC Corp. “We specifically asked about this during the presentation and your rep said it you could do it!”.

The vendor finally agrees that because the relationship between their companies is valuable and because of their strong work ethics, they will honor the agreed cost and do everything they can to meet the deadlines.

However, problems keep piling up. The ICM solution is not intended to perform what would be required for the compensation plans to work how they are supposed to work. Data integration, workarounds and clever tweaking pushes the ICM solution to its limit. The client is asked to only include what is absolutely necessary in this release and push out the rest. The deadline is missed. The solution is finally implemented, but User Acceptance Testing keeps revealing new issues. The second pay-roll date is approaching but there is still no solution in sight.

Does this sound like a familiar situation?

Who should be blamed?

The vendor’s implementation team for not working harder, their sales rep for having mis-represented their solution or not asked for more detailed requirements, or the ICM solution for not being powerful enough? ABC Corp’s team or their consultant for not having defined the requirements properly?

[Read Part 3: The Moral to the ICM Saga]

The Saga of Purchasing an ICM System

ABC Corp hired a consultant with extensive Incentive Compensation Management (ICM) experience to scope the requirements to be included in the Request for Proposal (RFP) for the purchase of a new ICM solution. The consultant diligently researched the latest industry trends, ICM best practices, client needs and leveraged his experience to create an outstanding requirement document. Weeks later the RFP is born, after having spent countless hours being sent back and forth between the sales, finance, contract and legal departments.

The RFP is finally posted and it takes a few more weeks before all the proposals are in. The consultant is called again to help out evaluating the best proposal. A few solutions are short-listed, and vendors are called in to demonstrate their product. The vendor’s sales reps all claim their solution is the only end-to-end ICM solution, that it is the “best-of-breed”, and that it has the best analytics and reporting capabilities.

After thoughtful consideration, a solution is chosen. It was a hard decision, but everyone at ABC Corp are happy that this long procurement process is finally over. ABC Corp’s management is particularly happy that according to the timelines illustrated in the selected proposal, the solution will be in place to process this quarter’s commissions and bonuses. After all, this was one of the major criteria in the evaluation process.

A kick-off meeting between the vendor’s implementation team and ABC Corp’s employees is scheduled. The vendor requests to see all the existing documentation about the plans to be implemented including the requirements document, to start working on the functional design documents and solution architecture. The next meeting is scheduled for Thursday.

[Read Part 2 – The ICM Saga Continues]

Implementation: In-House development versus Hiring Consultants/Outsourcing

In-House Development Pros

• Build and maintain knowledge in-houseLower maintenance costs in the long term
• Lower implementation for future releases
• Lower perceived development costs (pay salaries vs consulting fees and associated travel expenses)

In-House Development Cons

• Potential longer development time
• High training fees and long learning curve
• Complexity of project could be underestimated
• Project scope, timelines and expectations may be exaggerated
• No extensive prior experience increases risk
• Staff may not be available to be dedicated to project
• No previous deliverables to leverage
• Outcome of implementation is impossible to predict
• Incentive Compensation is not the core business of the organization

Obviously, the greatest advantage to hiring an experienced team to perform the implementation is to increase the odds of meeting the objectives and to decrease risks associated with a complex implementation. On the other hand, the major draw backs are that the knowledge acquired while building the project could leave along with the consultants, and the implementation costs may appear to be higher.

Different circumstances could make the balance lean in one direction or in the other, and a lot of information regarding the merits of either approaches can easily be found online.

My 2 cents is that a team consisting of consultants working on-site, along side with an in-house team who will eventually ‘own’ the system could be the best of both worlds.

My next article will include some tips on choosing an implementation partner.