The common method of functional requirements gathering for a "package" implementation is to employ some version of a gap analysis. This makes sense. After all, why would a carrier buy a third party vendor product and then proceed to ignore what that system does and how the system functions and go off and start requirements from scratch? So the gap analysis technique of requirements gathering is a common practice. Unfortunately it is not always a best practice. In fact the gap analysis phase is often the root cause of many problems that arise on third party software implementation projects. These problems include unrealistic time and cost estimates, incomplete functional requirements, and all the resulting project pathologies which occur when reality finally disabuses the disingenuous.

So is there something inherently inadequate about the gap analysis process that leads to these problems? The answer is "no" but on many of the projects I am aware of it is poorly done for at least two reasons:

Hard to Define Requirements

Want to continue reading?
Become a Free PropertyCasualty360 Digital Reader

Your access to unlimited PropertyCasualty360 content isn’t changing.
Once you are an ALM digital member, you’ll receive:

  • Breaking insurance news and analysis, on-site and via our newsletters and custom alerts
  • Weekly Insurance Speak podcast featuring exclusive interviews with industry leaders
  • Educational webcasts, white papers, and ebooks from industry thought leaders
  • Critical converage of the employee benefits and financial advisory markets on our other ALM sites, BenefitsPRO and ThinkAdvisor
NOT FOR REPRINT

© 2024 ALM Global, LLC, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to [email protected]. For more information visit Asset & Logo Licensing.