FRM, Sapient, London
The wily sage peered over the top of his wire-rimmed glasses and eyed the project manager up and down. Wearily, he intoned, "So you want to lose millions on an ETRM implementation? You want to stumble in the footsteps of legends: managers like Richard ‘Build It Here' Christy, Robin ‘Big Bang' Quivers, JD ‘De-Supported' Harnmeyer, and Sal ‘Scope Creep' Governale? Well, it's not going to be easy. But with the right combination of project mismanagement skills, it can be done."
OK. So that conversation probably never occurred. But you could be forgiven for thinking it did. An ETRM implementation is an expensive deployment of mission-critical software. There are countless challenges to be overcome and more than a few have failed to navigate the shoal waters.
A 2008 UtiliPoint study of 35 ETRM implementation projects found that, while only one was a complete failure, a quarter of respondents indicated that their systems were not implemented properly. With the average implementation project taking nine months to a year to complete, the median licensing fee north of a half million dollars, and implementation service costs between 1.5 to 2.5 times the license fee, failure can be costly.
What follows are some of the key lessons learned from scores of implementations involving a wide range of vendors and applications, including some of the most popular and enduring in the space.
There are truisms that relate to any project. Communicate, plan, know where you are and where you want to be, document everything, etc. They also apply to ETRM implementations. But in the interests of time and space, I've dispensed with general bromides to focus on the hard-won truths that apply specifically to ETRM implementations.
Okay, here's one bromide: The cheapest lessons are learned through the experiences of others.
An ETRM implementation should be a rewarding experience, both personally and professionally. You will work with a dedicated team, meet a range of people from different disciplines, gain valuable project management experience, and develop a detailed understanding of a complex system at the heart of your company's operations. But it's no walk in the park.
The application is necessarily complex. It must support the requirements of a wide range of customers on a common code base. Complexity is the flip side of the required flexibility and scalability. So ETRM software is fundamentally different from an off-the-shelf application. It is not ‘plug ‘n play.' One size does not fit all. Significant configuration will be required to tap the full potential of the application and this configuration will require input from the customer. This has to be understood at every level of the organization and championed from the very top.
After suffering through years with an inadequate system or a gaggle of spreadsheets, there is a natural tendency to make up a laundry list of requirements based on limitations of the legacy system. The new system will be the panacea that ‘solves all problems,' so we might as well pile them on. The salesman may have even encouraged this view. Of course, the initial implementation will not solve every problem — and here's the important part — nor should it attempt to. A good rule of thumb is to try to capture 80% of requirements in the initial effort and either address the other 20% in a separate implementation phase or outside the core system.
If you have a flexible, enterprise solution maybe that number is 95% with the rest in a subsequent phase. If you have a point solution, maybe it's 60% with the balance managed outside the core system. But it's not 100% in the initial implementation. The outsized effort necessary to put rare or complex structures into the project scope can put the entire implementation at risk. Identify and deliver core functionality in the first phase. Add bells and whistles later.
An implementation methodology
The vendor should have a proven implementation methodology to bridge the gap between the ETRM system and the implemented business solution companies actually need. It must be a well-defined, tried and tested process that details client and vendor specific activities to be conducted and the order in which they should be done.
Ideally, the vendor should come armed with a list of clients willing to provide references. You may want to do a Google search for historic new client signing press releases by the vendor. Compare it to the list of references, paying particular attention to the names that don't appear on the reference list.
Vendors with a strong delivery capacity are proud of it. Expect them to note that their implementations are delivered in accordance with a recognized standard such as Prince2 in the UK or the Project Management Institute's methodology in the US. Look for evidence that lessons learned are being codified.
Every phase of the project needs firm documented requirements that have been reviewed and accepted by both the client and the vendor. Each phase must have its own budget, timeline, and goal. This defines the initial scope. Acceptance test criteria or "test cases" must be defined as part of this initial scope. Deliverables that are too broadly defined or not fully understood contain the seeds of failure.
Reports are an area of particular interest. They must be clearly defined as part of the initial scope or hypothetically the following could happen. A one-page specification could be received for a report. Based on this specification, development begins. Meanwhile an outside consultant has been hired to interview end-users and develop a specification of the same process. After a month the specification could balloon to 12 pages. When it is eventually signed off six months later, it could be 75 pages long.
The best laid plans of mice and men
Things change. There must be a formal, documented process in place to make controlled scope changes. The estimated costs and benefits of the additional scope must be spelled out and approved.
Over the course of the project, many decisions will be made relating to the configuration of the system. As choices are made, document the reasoning behind decisions. This is so, after the system is live, others can understand what the thinking was at the time and be able to independently evaluate if the conditions or assumptions have changed.
Q: How do you eat an elephant?
A: One bite at a time.
Is your plan realistic? Are you planning to boil the ocean with your team of four? Is milestone two dependent on the development of a perpetual motion machine? Build a project plan that breaks down any large deliverable into manageable chunks delivered in phases. Avoid a ‘Big Bang' plan that has everything arrive at once. Critically, map tasks to resources where skills are not fungible and include vacations, holidays and a buffer to include sick days and other unforeseen events. Note any dependencies so the critical path is clear.
By the way, high-end skills are not fungible. In the 10% to 15% of ETRM implementations that users deemed to be excellent, having the right expert and knowledgeable resources on the project were identified as key success factors.
Head Office: We want a baby. How much effort do you estimate?
PM: About 9 woman-months.
Head Office: Hmmm...We're sending over 3 women. Can we pick up the baby in 3 months?
Some tasks can't be compressed due to their very nature. QA testing is one such example. Let's say the plan is for a 20 person-day effort, one person over four weeks. The same results will not be achieved by putting four people on the job for one week.
Sponsorship and buy-in
The client must take ownership of the implementation. The way to own is to help create. The implementation team should be a mix of vendor resources and representatives from each of the front, middle, and back offices. Key stakeholders should be included from the inception. A particular risk occurs when the project has IT but no business sponsorship.
Failure to identify all interested or affected parties could prove problematic. Suppose a key person from the risk department is away when a critical decision about risk reporting is made. Even though all present might agree with the proposed solution, a workaround in this case, the key player may disagree and become a roadblock thereafter.
Executive sponsorship is the best way to signal the organization's commitment to change. This support should be clear, visible, and vocal. Ways to demonstrate this commitment include holding steering committee meetings and having senior management attend weekly status meetings.
Without executive sponsorship, the end-users could choose to resist an implementation, buffered in the knowledge that senior management never established it as a priority. If the project was on a time and materials basis this could go on for some time, generating revenue for the vendor but no deliverables for the client.
Training is a tempting target when looking to reduce scope. But effective training is critical if end-users are to accept or ‘buy in' to the application. Where possible use the client team members as trainers and schedule multiple sessions to ensure the information is taken on board. It's not reasonable to assume that knowledge of a new and complex system will be retained after a single pass.
A special caveat
It is likely that the implementation means the replacement of a system that one or more people in the organization have worked long and hard to sustain. It is critically important to identify these individuals and keep them even closer by including them in the implementation effort. Otherwise, there is the risk of active resistance or passive-aggressive behavior. Having code that you wrote be replaced by a commercial system can feel threatening. Winning these folks over is a key objective.
Pricing model risks
Certain risks are introduced by the implementation pricing model itself. If the implementation is being done on a time and materials basis, the client bears all the risk of scope creep or inefficient delivery. If the implementation is being done on a fixed price basis, the vendor bears all the risk and the client has no real incentive to assist or control scope. Each model has weaknesses. The good faith of the parties involved is the main bulwark against a breakdown.
A third way
A more flexible approach may do a better job of aligning interests. Where scope is clearly defined and responsibilities can be allocated, the fixed fee model makes sense. This relieves the client of pricing uncertainty while presenting an acceptable level of risk to the vendor. Where the scope cannot be determined with any precision, perhaps a new development initiative, for example, the time and materials model may be more appropriate. This provides maximum flexibility for the client without unacceptable risk to the vendor. For cases that fall between these extremes, a fees-at-risk model may do the best job aligning interests. Here the client is billed on a time and materials basis but a quarter of fees are "at risk." The client decides how much of the "at-risk" fees will be paid based on pre-agreed criteria laid out on a balanced scorecard. The vendor has some skin in the game.
Whew! We're implemented. Nothing can go wrong now.
Not so fast. Even if the implementation goes to plan, there are still risks that the value of the work that has been done can be seriously degraded. These risks are associated with your choice of vendor.
Most obviously, the vendor might go belly up, as Vedaris did in 2004, leaving clients stranded. This is less of a risk with industry-leading vendors.
Or the vendor might be bought out, ceding control of their future direction to the acquiring entity.
Or the vendor may simply stop supporting your application. Here's a fairy tale to illustrate one of the more creative ways that might happen:
A fairy tale with no prince
Once upon a time in a land near, near away, there lived a company. This company liked to buy other little companies to gain market share, hoping that one day they could sell to Mr. Bubble and live happily ever after. But while they were buying companies, Mr. Bubble burst. The company was very sad because they now had an assortment of products that each required support and a management team with limited operations experience. The company looked at its product line: ‘WideButShallow', ‘Intermediate,' and ‘DeepButNarrow.' Customers had bought each system to meet different requirements. The company decided to give ‘WideButShallow' a makeover and rename it ‘Ain'tItGreat?,' a one-size-fits-all solution for everyone. They then stopped development of ‘Intermediate' and ‘DeepButNarrow.' All maintenance revenue was used to develop ‘Ain'tItGreat?' But because each solution was fundamentally different, ‘Intermediate' and ‘DeepButNarrow' customers couldn't upgrade to ‘Ain'tItGreat?' They had to re-implement. They were still paying maintenance but their system was no longer supported. These customers and their orphan systems did not live happily ever after.
If the vendor does manage to stay in business and continues to support the system, you're still not out of woods yet. The point solution you were sold may not support the full range of processes required by your business. Enter the spreadsheets and still more point solutions.
This brings us to one of the great implementation bugaboos — interfaces. Rather than recount specific horror stories, let's look at the recurring themes.
Functionality from each system is lost across the interface. The interface is not supported by either vendor. The interface requires upgrading at twice the frequency of each system, due to changes at either end. The interface dramatically increases your total cost of ownership. Avoiding interfaces is one of the key selling points of a fully integrated solution.
Most ETRM implementations are delivered successfully. But achieving that outcome is neither certain nor simple. The lessons discussed here flow from smart, hard-working people. It's frustratingly easy to go off the rails. I'm reminded of a conversation between two parents of teenagers. "Have you seen the price of college?" remarked one. "Have you seen the price of ignorance?," responded the other. In this high-stakes environment, you can't afford to relearn the same old lessons.
Finally, you might have recognized some of the names at the beginning of this piece. But not because you worked with them. They are all members of the Howard Stern Show staff and the nicknames are classic ETRM implementation errors. OGFJ
About the author
Larry Hickey is a director with Sapient Global Markets. He has been rattling around the ETRM space for the past 12 years.