The ancient military axiom goes "Hope for peace, prepare forwar." In other words, the act of preparing for war makes peace farmore likely.

The analogy holds with IT projects. The more you anticipate andplan for the eventualities that make projects fail, the less likelythose failures are to occur. So, a project formulation of the sameprinciple would be "Hope for success, focus on failure," whichisn't necessarily a good slogan to share with your CEO, but bearwith me.

If you follow this formulation, not only do you minimize thelikelihood of failure, but you make failure a self-consciousoption, which is a result of actions rather than inactions andsomething that you decide to do rather than something that happensto you. Also, if you are going to fail, you should choose to failfast.

Projects, especially the large and complex ones like coresystems replacement, as we all know, are risky undertakings. Coresystems projects still fail at alarming rates. There are no hardnumbers, for the obvious reason that neither the vendor nor thecarrier is interested in publicly declaring failure. However,industry analysts continue to estimate failure rates at between 50and 75 percent. So, what can you do to drastically reduce the oddsthat your project will become one of these statistics?

The answer is to plan for failure. Make a systematic inventoryof the things that could reasonably go wrong (no point in worryingabout an asteroid strike) and add in project-related skills thatyour company is not good at performing. Now start to createstrategies for dealing with each key item. When you are done youreally have only started; this list and its responses will continueto grow throughout the project.

Based on experience with many implementations—some good, somenot 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 majorcost and time increases: Create triggers in the services andsoftware agreements that give you the option to walk away withoutfurther cost from the implementation project should the vendorincrease costs by more than an agreed amount at a given point inthe project (e.g. at completion of requirements gathering), orshould the vendor fail to deliver agreed-upon items at agreeddates.

These triggers must be agreed to, written intothe contracts, and related to milestones in the project plan. Theunderlying payment scheme should be an incremental pay for deliveryarrangement, which gives you maximum leverage and minimizes yourexposure. This is the nearest your project can get to a "Get out ofJail Free Card." A $500,000 failure is still a failure, but it isso much better than a $5 million failure.

The vendor may agree to timed payments based on delivery butwhat if the quality is poor: You get the behavior you incent. Ifyou incent the vendor to deliver a code drop on a given date youare probably going to get whatever they have as of that point intime, so go one step further and write into the agreement that thecode drop has to pass certain "smoke tests" before it can be placedinto your QA library. No smoke test, no money. Passing the smoketest 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 youeither misunderstood or you got the wrong vendor (see Get out ofJail Free above). If you cannot run the project hire someone whocan.

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

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

Scope might get out of control: It usually does. No reason whyyour project should be any different, except, you have plannedahead. First, you have pounded the following principles into theDNA of the project:

• If there is no compelling reason for this feature itis 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 andmomentum.

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

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

Clarification and change are inherent in majorprojects and they must be accommodated because they cannot be fullycontrolled. I am so convinced of the common sense advantages ofagile over waterfall that I would go so far as to say that if avendor 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 aboutmore than all else in selecting a vendor. The vendor should have ahigh function/highly configurable system, a strong track record ofsuccessful implementations, and should be a disciple of agiledevelopment and implementations. The good news is increasinglythere are more vendors that fit these criteria.

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

What are we talking about here? Tools may include how you willcollect and record requirements, how you will convert and migratelegacy data, and how you will test (regression and maybe evenperformance test) a major new application. Skills and experienceshortfalls tend to come in the same areas. Who knows how to build amajor 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 ofcapable and aggressive project leaders who can move a major projectforward, or is it a group of project administrators that know howto keep score without actually knowing where the project is goingor when it will get there?

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

Scope might increase somewhat and for goodreason without throwing the project off balance, but only if thereis 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 thekind of deal outlined above they will let you know in advance andwill explain why it happened this time and will not let it happenagain. If the vendor fails to deliver more than once you will notneed to get into a vendor death spiral because of how much you havealready spent. You can bail out before the project hits the groundand the vendor knows that so they will do everything they can tokeep your project on course.

If your CEO knows the worse case is you are risking $500,000 andsix months of time, the pressure to kill the project will be muchless 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 legacyreplacement projects.

George Grieve is CEO for CastleBay Consulting. Previously a CIOand still an acting consultant, he has spent much of the past 25years with property/casualty insurers, assisting them in thesearch, selection, negotiation, and implementation ofmission-critical, core insurance processing systems. He can bereached 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 necessarilyrepresent those of Tech Decisions.