How the Right Requirements Can Make or Break Your Next IT Project
- Written By Rob Berg
Authors: Rob Berg SCPM, CSSBB and Mark Nawrath, PMP, MBA
According to the Standish Group’s Chaos Report, an alarming 19% of all IT projects fail. Meanwhile, a full 60% fail to meet expectations. Stats like this show that tech projects run the risk of failing more often than they succeed. For insurance companies, these numbers should be alarming. The amount of capital—both human and financial—invested in IT projects for insurance companies mean that missteps in implementation planning and execution translate directly into significant waste, both of time and money.
We have found that one of the most impactful ways to shield tech projects from serious setbacks is to invest in establishing a clear set of requirements well before system configuration begins. If you’re not paying attention to the fact-finding and requirement-defining phases of your project, you may be unwittingly setting yourself up for failure.
How do you define “good” requirements?
In a single word: unambiguous. This means painstakingly translating information from subject matter experts into a language that can be easily consumed by developers or those configuring IT systems. Too often, subject matter experts get mired in their own vernacular. They forget that terms and definitions that seem obvious due to daily use and a shared language among colleagues are not likely to be fully understood by the developers—who also communicate through their own shorthand. Insurance technology consulting partners must not only record requirements, but they must also take the time to outline specifically what each requirement means and communicate how it fits into the greater context of the project.
Read more: The Importance of Unambiguous Product Requirements.
From there, consistency is key. By taking ad hoc approaches to write their own requirements from scratch at the outset of each project, we’ve seen insurance companies fail to capture and organize important information along the way. The formatting of the project outline plays an important role, even down to details like consistent sentence structure and naming conventions. When each project looks like an entirely new animal, developers and project managers are forced to spend more time taking in the basics, instead of capitalizing on their expertise to document an exhaustive set of requirements and spot areas of ambiguity that require more clarification.
The cost of hazy requirements
We’ve all heard horror stories about IT projects at insurance firms that have been drastically delayed or simply abandoned because the train got so far off-track that it couldn’t be redirected. For example, we saw a company spend millions buying a new policy admin system, trusting the assurances of their software development vendor that the project would take six months to implement. After six months passed and the project was still around halfway from completion, Perr&Knight was called in to try to salvage the struggling project and stave off a lawsuit.
We discovered that the project was doomed from the start because even basic requirements weren’t clear. Obvious problems included project requirements outlined in disparate emails, multiple stakeholders weighing in at different stages and actuaries who simply passed along a rating algorithm, assuming that programmers could just use it to program for a different state or new line of business. Lack of context was stifling each party’s ability to deliver their full level of expertise.
Far-reaching consequences
Poor product definition – the core requirements that document the use of insurance product rates, rules and forms – has the potential to become a quadruple whammy that can hurt the company on multiple fronts, not just the IT or actuarial department. Here are some of the ways badly defined insurance product requirements leak out across departments and damage the company as a whole.
- Lost time – When product parameters require constant clarification from underwriting and regulatory staff, project phases extend to weeks or months instead of days, and the delay drains time that could be better spent elsewhere. This lack of efficiency leads to…
- Frustration – Projects that proceed at a snail’s pace drain morale and lead to increasing personal frustration as teams struggle to deliver.
- Skyrocketing budgets – Resuscitating shaky IT projects that are midway through development often requires throwing good money after bad. It’s the only way to justify the expenditure up until his point and salvage the project.
- Regulatory implications – For projects that do reach completion, those with poorly written product requirements often fail to address the true standards required by state departments of insurance. Configuring incomplete or incorrect forms or rates leads to a significant regulatory risk that can take a toll on the company’s reputation and seriously impede their speed-to-market objectives.
The key to establishing clear requirements
In an industry that depends so heavily on specialized expertise, one of the smartest ways to ensure that your product definitions are clear is to approach the requirement through the eyes of a layperson. It sounds counter-intuitive but boiling down needs and specifications to their most basic, plain-English functions enables project managers to deliver the vital translation between insurance company and vendor described above. Additionally, it helps insurance companies gain a deep understanding of what amount of “out of the box” functionality will truly apply to software products they purchase, versus the amount of customization that will be required to achieve the final end-product.
Though it seems like a safe bet to hire the big guys, we find that when insurance companies go directly to big technology consulting firms for development, they often end up with well-meaning tech developers who may lack adequate insurance domain knowledge. This specificity plays an important role in translating the needs of insurance companies into software that not only improves productivity and speed-to-market objectives, but supports compliance in an increasingly burdensome regulatory environment.
Hiring an insurance technology consulting company to painstakingly outline and define your entire project scope may require a slightly higher initial outlay but think of it this way: you’re in the insurance business. Taking the time to do it right the first time is your own insurance policy against expensive delays and demoralizing headaches.
