What’s Required?

We once heard it said that most companies replace systems before they’ve used 80 percent of those systems’ capabilities or capacities. We were skeptical at first. But the more we thought about it, and the more we looked at systems, the more true it became. Here’s why:

Most companies decide to replace systems because of recurring functional frustrations: “Our system doesn’t do this.” “If only our system could do that.” And our favorite: “We need a new system to [fill in whatever you want that new system to do here].” In response to any of those statements, the logical questions are: Did you want your system to do this, that, or the other thing (whatever that thing is) when you bought it? Did you tell anybody?

Look Ahead

When Sylvester Stallone was shooting Rambo III in Thailand, cast and crew members were dropping like flies from the heat and dehydration. Stallone said, “By the time you realized you were thirsty, it was too late.” So it is with systems: By the time you realize you need something, it’s likely too late. That’s why foresight is so important in defining and articulating system requirements. Adding a little more nitromethane to the fuel mixture propelling a top-fuel dragster is much easier to do in the staging area than it is on the straightaway at 300-plus miles an hour.

To define and articulate requirements effectively, you have to:

  • Ensure transparency. If you try to define requirements in secret, away from the prying eyes of users, you’re building the system for yourself. Don’t be that limited or limiting.
  • Specify functional needs. The less you describe specifically what you need the system to do, the more you’re likely to fall for technical smoke and mirrors.
  • Avoid popularity contests. If you ask peripheral stakeholders — rather than users — what they want, they’ll tell you. If you don’t deliver those things, they’ll talk badly of you. If you do deliver those things, you’ll blow the timeline and the budget, the system won’t perform the way users needed it to, and they’ll talk badly of you.
  • Avoid pilots or prototypes. Either the vendor’s done it before or not. As the saying goes, almost only counts in horseshoes and hand grenades. If the vendor hasn’t done it before, you probably can’t afford to be a guinea pig.
  • Agree to a list of prioritized deliverables. Those deliverables should be a clear reflection of your requirements.

Act Like the Future is Now

We know it’s not possible to anticipate everything. But the more you anticipate, the more accurately you can define and articulate your requirements. And the more accurately you define and articulate your requirements, the more you’ll get out of your system and the longer it’ll continue to meet your functional expectations.

Rambo wouldn’t be able to beat the bad guys and dragsters wouldn’t win any races if they ran at 20 percent.

Get It Right the First Time

Given the business we’re in, we like to keep an eye on the trends, attitudes, and inclinations of the companies we might consider prospects in the industry we’re in, that being insurance. Consequently, we took note of a survey of 396 CIOs and technology leaders by the consulting firm, Protiviti. Two things in particular caught our attention:

First, in response to a question about their motivations for replacing core systems:

  • 76 percent cited risk mitigation
  • 12 percent cited revenue generation
  • Just six percent cited cost savings.

Second, when asked their biggest impediments to acting on those replacement needs:

  • 41 percent cited implementation risks
  • 24 percent cited time and disruptions
  • 24 percent cited vendor product deficiencies.

We find that curious. Here’s why:

Maybe Common Sense Isn’t All That Common

In our experience, the two primary motivators for system replacements are (1) improvement and (2) improvement — the first in operations, the second in customer service. When our customers achieve those objectives, their risks go down, their revenues go up, and their savings increase. That made us wonder how the survey instrument might have been worded.

Likewise, our experience indicates that implementation risks, disruptions, and product deficiencies can be increasingly minimized with diligent, empirical scrutiny of the issues that arise; point-in-time conversions from the old system to its replacement; and ongoing customer feedback with the requisite, corresponding development efforts. That made us wonder about the companies with which the 396 CIOs and technology leaders worked to report the impediments they did.

Try This

We think the most common-sensible things to do for any project, let alone a system replacement are:

  1. Determine your objectives
  2. Identify and define your requirements
  3. Perform your due diligence in vendor selection
  4. Talk to customers of your short-listed vendors.

If you don’t do those four things, you’ll be compromising your chances of getting it right the first time.