The answer is to plan for failure. Make a systematic inventory of the things that could reasonably go wrong (no point in worrying about an asteroid strike) and add in project-related skills that your company is not good at performing. Now start to create strategies for dealing with each key item. When you are done you really have only started; this list and its responses will continue to grow throughout the project.

Based on experience with many implementations—some good, some not so good—here are some items I would put on my list:

We chose the wrong vendor: (Re)read previous Shop Talk articles. If it still isn't clear, apply for a job transfer. Hint: look for "vendor shortlist" and "proof of concept."

The vendor could come back to us later in the project with major cost and time increases: Create triggers in the services and software agreements that give you the option to walk away without further cost from the implementation project should the vendor increase costs by more than an agreed amount at a given point in the project (e.g. at completion of requirements gathering), or should the vendor fail to deliver agreed-upon items at agreed dates.

These triggers must be agreed to, written into the contracts, and related to milestones in the project plan. The underlying payment scheme should be an incremental pay for delivery arrangement, which gives you maximum leverage and minimizes your exposure. This is the nearest your project can get to a "Get out of Jail Free Card." A $500,000 failure is still a failure, but it is so much better than a $5 million failure.

The vendor may agree to timed payments based on delivery but what if the quality is poor: You get the behavior you incent. If you incent the vendor to deliver a code drop on a given date you are probably going to get whatever they have as of that point in time, so go one step further and write into the agreement that the code drop has to pass certain "smoke tests" before it can be placed into your QA library. No smoke test, no money. Passing the smoke test is part of the definition of an acceptable delivery.

The vendor told me they would run the project but they are not: No software vendor in their right mind would say this, so you either misunderstood or you got the wrong vendor (see Get out of Jail Free above). If you cannot run the project hire someone who can.

Here's the single most important issue for project success: No one who has not previously run a core systems replacement can do it well; it's too complex, too broad, and has too many moving parts for on-the-job training.

It is crucial that someone, hopefully the project director, has "seen this movie before." That means they are familiar with the domain (e.g. claim system replacement), know the vendor (and preferably have worked with them before) and are well versed in project methodology. These types of projects are different from one carrier to the next, but they also are all the same. A great deal of knowledge is transferable.

Scope might get out of control: It usually does. No reason why your project should be any different, except, you have planned ahead. First, you have pounded the following principles into the DNA of the project:

• If there is no compelling reason for this feature it is out of scope

• The system need only be "good enough" to go live, not perfect or complete

• Going live early is good; it creates success and momentum.

Second, you have implemented a formal change control process, have stood up to a change control board, you have frozen the project scope, and told the whole project team repeatedly that scope creep is not an option.

The vendor might not understand what functionality we are asking for: Correct. It is also likely that your SMEs don't always understand either. This is why you have formed cross-functional teams that work in 30-day sprints inside of an agile methodology and are using prototyping tools to visualize the future system and allow the SMEs to react and change.

Clarification and change are inherent in major projects and they must be accommodated because they cannot be fully controlled. I am so convinced of the common sense advantages of agile over waterfall that I would go so far as to say that if a vendor does not use agile you should find another vendor.

We brushed past the issue of choosing the right vendor earlier, but I suggest that there are three things you should care about more than all else in selecting a vendor. The vendor should have a high function/highly configurable system, a strong track record of successful implementations, and should be a disciple of agile development and implementations. The good news is increasingly there are more vendors that fit these criteria.

We may not have the tools, skills, and infrastructure to support the project: Probably not, especially for a smaller carrier. There is a reason why you don't have what you need to replace your legacy systems: You haven't done it in 20 to 30 years.

What are we talking about here? Tools may include how you will collect and record requirements, how you will convert and migrate legacy data, and how you will test (regression and maybe even performance test) a major new application. Skills and experience shortfalls tend to come in the same areas. Who knows how to build a major QA plan, manage the vendor(s), plan and estimate the project, design/build/execute the conversion?

Last but not least, do you have a change control process, a PMO, or a project methodology? If you have a PMO, is it a group of capable and aggressive project leaders who can move a major project forward, or is it a group of project administrators that know how to keep score without actually knowing where the project is going or when it will get there?

I could go on (and on) but you get the idea. There are many things that can derail a project and cause it to fail. Usually it isn't any one particular issue but rather a combination of issues that ricochet off each other and create an increasingly dysfunctional project that you cannot get back under control.

Scope might increase somewhat and for good reason without throwing the project off balance, but only if there is some slack in the schedule or some spare resource (don't laugh) or funding to allow for some short-term talent augmentation.

The vendor might be late with a delivery, but if you have the kind of deal outlined above they will let you know in advance and will explain why it happened this time and will not let it happen again. If the vendor fails to deliver more than once you will not need to get into a vendor death spiral because of how much you have already spent. You can bail out before the project hits the ground and the vendor knows that so they will do everything they can to keep your project on course.

If your CEO knows the worse case is you are risking $500,000 and six months of time, the pressure to kill the project will be much less than if he thinks you are in for millions and years.

So, focus on those things that can cause your project to fail. It's the most likely way of ensuring the success of your key legacy replacement projects.

George Grieve is CEO for CastleBay Consulting. Previously a CIO and still an acting consultant, he has spent much of the past 25 years with property/casualty insurers, assisting them in the search, selection, negotiation, and implementation of mission-critical, core insurance processing systems. He can be reached at 210-887-6423.

The content of "Shop Talk" is the responsibility of the author. Views and opinions are those of the author and do not necessarily represent those of Tech Decisions.