Once the carrier knows what it is looking for it needs to focus on a small number of likely vendors and insist those vendors perform relevant and designed tasks in order to win the carrier's business. These tasks include scripted demos and a substantial proof-of-concept to verify the “winning” vendor. The more I am involved in software selection projects, the more I believe vendor performance is the biggest single risk mitigator. If the vendor will not perform certain carrier-defined selection tasks, why should the carrier assume that the vendor can perform the ultimate task of replacing the legacy PAS?

A proof-of-concept gives the added reassurance of having the vendor perform a more extended set of tasks working with the carrier's staff and doing so preferably at the carrier's location. All of which makes it much more difficult for the vendor to keep the “wizard hidden behind the curtain”, if indeed there is one. Scripted demos and proof-of-concept go a long way to helping the carrier assess the capabilities of a vendor. However, if the vendor is intent on misleading the carrier (which is a genuinely rare event these days), it is almost impossible for the carrier to figure this out before it's too late. This is why the carrier, having done all it reasonably can to select the right vendor, should also take contractual and project management steps to mitigate the risk of a runaway project.

Mitigation Strategy No. 2: Create Contractual Exits

Carriers are usually required to execute three contracts in order to acquire and implement a third-party PAS. These are a software license agreement, a software maintenance agreement, and an implementation services agreement. Most vendors prefer that the license fee, which may be a seven-figure number, be paid up front. This locks the carrier in by making them commit to a large financial payment before the implementation begins. Being locked in then has the effect of reducing the carrier's perceived range of actions should the implementation go wrong.

This is the exact opposite of what is best for the carrier. During the selection process the carrier should clearly state that payment for both software and services will be delivery based and time phased and should insist that this provision is explicitly agreed to by each responding vendor. Then, in the negotiation process and in conjunction with the project task plan, the carriers should create contractual “exits.” These exits create measureable triggers which—should they occur on the project—the carrier has the option to re-evaluate, remediate, or opt out of the implementation and any further software license and maintenance payments without significant financial penalty. These contractual exits are usually tied to performance criteria which are reviewed at key points in the implementation project.

So what does a contractual exit actually look like? Contractual exits usually concern costs and timelines but may also include other criteria such as quality. For example, I recently heard that a carrier exercised a contractual exit because the vendor came back at the end of the requirements gathering phase with an implementation re-estimate that was higher than an agreed limit spelled out in the implementation services contract. This carrier had (with expert help, I might add) structured its software and services agreements to minimize upfront financial commitments and to provide opt-outs if the shape and size of the project grew beyond acceptable boundaries.

These boundaries, expressed as percentages of the original estimates, were agreed as exit criteria in both the services and license agreements. It is, of course, a hard judgment call as to whether or not to bail out of an ongoing project, but without these mechanisms in place it is much more difficult for a carrier to pull the plug. The contractual exits described in this instance are similar to the buy/sell triggers that investors place on stocks, which often execute automatically if a given stock falls by more than a specified percentage. This doesn't mean that getting out of the stock or the implementation project was the right call, but it is a rational way of evaluating how to spend money and invest.

Mitigation Strategy No. 3: Project Milestones

Planning for failure does not mean planning to fail. Rather it means building gates, milestones, and review points into project plans, which provide early warnings that things may be going off course and what investigative and remedial steps are to be taken should they be triggered. We mentioned above that contractual exits may be tied to cost, timeline, quality criteria, or other criteria. The carrier should create major milestones in the implementation project plan where these types of measures can be taken and acted upon as necessary.

For example, quality criteria can be invoked at any software delivery point in a project. Bear in mind that you get the behavior you incent, so if vendor payment is tied to delivery then rest assured that the vendor is going to deliver. The obvious question then is did the delivery work? And the only way to answer that question is to test the software against some pre-agreed quality measures and decide if it is acceptable or not, which in turn dictates whether the vendor gets paid.

Similarly, with cost and timeline criteria there are milestones in the project where these parameters can and should be measured. One such milestone is the project re-estimate that occurs at the end of gap analysis or requirements gathering. This is the point at which the vendor should know enough about the shape and size of the project to provide a firm price range for overall implementation. If the vendor comes back with an estimate that is outside of an agreed range based on that vendor's winning bid, the carrier should have the option to hold, review, and ultimately close down the project. As above, these kinds of review points need to be backed up by contractually agreed exits that the carrier can exercise.

With these three strategies in hand the carrier should be able to control, monitor, and react to risk of failure such that first, the risk is minimized and second, if failure is declared the financial and operational impact is minimized. The carrier alluded to above got out of a multimillion-dollar PAS acquisition/implementation for a fraction of the budgeted cost by imposing such disciplines in the contracting and implementation planning phases. This carrier is still dealing with the fallout of what is viewed as a failure, but the failure cost six figures instead of seven and took months instead of years.

Any PAS project comes with the potential to disrupt business operations, stress the organization for a significant period of time, and cost millions of dollars. While there is no way to guarantee success, the strategies outlined above will place the carrier in the best possible position to succeed, or to fail with as little impact as possible. There is one obvious point which needs to be added in closing, which is that these kind of arrangements cannot happen without the cooperation of the vendor. Clearly what is in the carrier's best interests may not be in the vendor's, but most vendors will negotiate around these kinds of terms. If a vendor refuses to entertain these types of conditions it may be telegraphing a message to the carrier that it is not the right vendor anyway.