Running Successful Insurance IT Projects: When Do External Project Reviews Make Sense?

Bringing in assistance from the outside in the middle of the project, no matter how insightful, will not recoup lost time or wasted effort. However, while project ought to be carefully planned up-front, mid-course project reviews can make a critical difference.

(Photo credit: Shutterstock.)

Everyone knows that contracts are best reviewed before you sign them, not after there is an issue to be resolved. The same is true for insurance core system replacement projects. The detail of project governance and change management processes, roles definition and expected outcomes all need to be thought through and defined before a project is started. Discussion of risks and mitigation strategies with the principle parties can help to clarify roles and expectations avoiding some problems. An external project review should help to set the proper initial framework and is not mean to replace agile retrospectives. Most projects that fail to meet objectives (costs, time or benefits) go off track early in the project, so one has to ask: Is your set up for success or failure? Bringing in assistance from the outside in the middle of the project, no matter how insightful, will not recoup lost time or wasted effort. However, mid-course project reviews can be critically important. We’ll consider when reviews are not advisable, but first, here are circumstances under which reviews make sense:

  • The project is missing key milestones. If the problem is with execution, midcourse process reviews can be very beneficial. This is especially true if a waterfall methodology is being used and they are conducted just prior to initiating the next phase of a major project. Targeted reviews of processes such as software management practices can also be very helpful. CIOs should not abdicate responsibility for dealing with personnel performance issues. An outside opinion may help with the diagnosis, but the ultimate responsibility for assessing talent lies with the CIO and or other executive responsible for the project.
  • There are questions about the strategy or direction of the project. Carriers often express disappointment with their vendor or system integrator when they in fact may have committed to too aggressive a strategy or overreached their organizational capabilities. While these issues are best addressed in the early stages of the project, egos can often prevent these risks from being clearly identified and dealt with. If the implementation issues are linked to strategy or partnership issues, it is imperative that an objective evaluation is completed and that both sunk costs and egos are set-aside in the evaluation. Forecasting end states, remaining costs and operational impacts are critical to this type of an assessment. Killing a bad project is one of the most difficult things to do; yet it can be the right thing to do.

Now let’s consider the other side of the argument; outside reviews are less effective when:

  • The sponsor of the review insists on screening or directing the review team’s analysis and recommendations. Project review teams must have full access to all individuals on a project team and to all information. They need to engage impacted parties in the evaluation of their current state and discussion of both the implications and the necessary actions to obtain full benefits of this type of review.
  • Success measures for the project being reviewed are not quantified. Teams need to have the project vision defined and be held accountable to achieving targeted success measures. If these aren’t in place, you don’t need outside help to figure out what is needed.
  • Project sponsors are unwilling or unable to implement recommendations. This “gut check” is critical. However, keep in mind: if your project is going off track and you don’t fix it, someone else may be asked to do this for you.

Much like the retrospective reviews of the agile team, regular follow up reviews at the program level can keep a project from going off track and allow minor mid-course corrections. Several core system providers have a regular project health check review process built into their methodology. This can help to surface, issues but usually from a vendor’s perspective. I strongly recommend this as a best practice but would urge you to consider outside review if your IT management, risk management team or internal audit team are not confident in their ability to assess the vendor recommendations or develop action plans for internal corrections.

Leave a Comment

(required)