Authors: Rob Berg SCPM, CSSBB and Mark Nawrath, PMP, MBA
As expert insurance technology consultants with many years of experience under our belts, it feels like we keep seeing the same story over and over. It goes like this: Company has a need for an IT project, Company hires vendor to develop software or processes, project seems to start off strong, but ultimately gets further and further off track until the timeline is blown, the budget has skyrocketed, and Company has invested major time and money—with no useable solution yet in sight.
Though each company has its own unique circumstance and different players involved, we’ve seen the same types of issues derail project after project. Here are some of the most common reasons IT projects fail and how to keep yours going strong.
Reason 1: Lack of involvement from leadership
As the initial (and often final) decision makers, the executive team holds a significant amount of power regarding a project’s success. As we’ve all heard before, “With great power comes great responsibility.” It’s up to the executive team to not only carefully consider their choices and motivations when committing to a project, but to remain actively involved during every phase. The company’s leadership must thoroughly understand the project needs and goals and actively work to support that vision. New IT project implementation brings significant change throughout an organization. If leadership is not onboard at the outset and throughout development, those who are in charge of managing the project will struggle and the initiative may ultimately fail.
Reason 2: Change is challenging
New ways of doing business are often met with some level of resistance. The insurance industry is notoriously slow-moving and many of the people who work in this business have occupied their position for decades. Their experience brings value to an organization, but often those who have been accustomed to doing things the same way for the majority of their careers don’t realize the benefit of change. They may consciously—or unwittingly— undermine efforts to implement new systems.
Reason 3: Poor project requirements
As mentioned in a previous blog, ambiguous requirements are often both a cause and a symptom of a project that is destined to struggle. When project requirements are handled haphazardly, individuals involved in bringing the project to completion spend too much time trying to decipher what is being asked of them, they head down paths that seem right but don’t fit into the greater scope of the project, and they waste time trying to sort out the results of initial poor planning. By clearly and correctly articulating project requirements from the outset, projects stand a much greater chance of successful completion.
Read more: How the Right Requirements Can Make or Break Your Next IT Project.
We were brought into one such stressful situation. One of our clients was struggling with a failing implementation project, and about to head into an expensive arbitration. To assess the situation, we conducted a thorough review of contracts, requirements, and project management artifacts which revealed that their problem originated with the contract itself: it was far too ambiguous. One of the deliverables stated in the vendor contract was to “implement an underwriting module.” But what exactly did that include? The answer was up in the air, and neither our client nor the vendor could agree on what was to be delivered. Furthermore, requirements were scattered within emails, there was no evidence of a project plan or charter, and no regular status updates other than the ad hoc discussions that took place periodically.
Based on our written report, the client invited us to testify at the arbitration as an expert witness. After being certified by opposing counsel and the arbitrators, defending the findings in our report under cross-examination and delivering testimony that stood up under rigorous scrutiny, our client prevailed. However, their victory was a double-edged sword. They were able to recover their funds from the contract but had to pay the arbitrators, experts, and a stenographer – in addition to their own time lost in travel and testimony. They were also back to square one when it came to the project itself.
Reason 4: Sloppy project management practices
In insurance project management, keeping an eye on details is crucial. Projects should be overseen by experienced project managers or insurance technology consultants, not well-meaning junior staffers with an Excel spreadsheet and an Outlook calendar. During the course of development, many high-stakes pieces of information must be juggled, including status reports, baseline tracking, dependencies, and change requests. We’ve seen companies dive head first into costly IT projects with zero analysis of how long it’s going to take, what the final cost of implementation will be, or how it will affect other activities that occur downstream. All of these crucial pieces of information must be identified at the outset, tracked throughout development, and evaluated at project completion to gain a true understanding of whether or not the project is a success.
Read more: Common Mistakes Carriers Make When Implementing New Systems.
We were called in to rescue a project for a medium-sized regional carrier who had sunk millions into a policy administration system that was months over deadline, with no end in sight. We discovered that not only was there no onsite project manager, there were no formal documented requirements (just raw materials like rating worksheets and product filings). Organized status reporting was also nearly non-existent: the Vice President of IT would hand-draw a set of pie charts on a piece of paper each week, roughly approximating the level of project completion—with no verifiable data to back it up.
We recommended that they put substance behind their completion tracking, so we created a formal project schedule for each component. We installed an onsite project manager who took documentation seriously. What had previously been a project that was almost at the point of litigation turned around quickly as all parties were able to assess and achieve their distinct requirements. This intervention ultimately led to a successful implementation.
Reason 5: Ignoring key stakeholders
Leaving out the people who will be using these systems every day is a grave error that will almost always cause problems down the line. If the ultimate end users are not invited to participate in system selection and configuration, not only is the project likely to face resistance, it could lack certain key features that might help these individuals perform better. Involving all levels of stakeholder during all phases of project development gives each a sense of ownership over how the project proceeds. It also provides stronger justification for each person or department to support its eventual success.
How to tell where your project is struggling
We have been called in countless times to help companies who have succumbed to the traps listed above. To prevent such catastrophes, we conduct an in-depth readiness assessment – preferably in advance of the implementation effort – to determine weak areas of the project, then develop a plan to reinforce those issues. For starters, here’s what we look for:
- Personnel: Is the project adequately staffed? Are those staff members adequately trained with appropriate competencies?
- Internal processes: How does work flow through the project? What is the process for approvals? What is the process for procurements that take place outside the scope of the project’s main deliverable?
- Supporting technology: How are status reports obtained and delivered? How are people logging their time against the project? How does this compare against the baseline? Are the appropriate environments (e.g., development, staging, testing, production) set up?
- Metrics: What metrics are being monitored? How is project success being defined?
- Overall governance: What project management methods are being utilized? Are they appropriate for the project scale and scope and composition and distribution of the team?
- Physical environment: Is the project effort being performed with the right facilities? Do people have enough space, equipment, and easy access to the resources they need?
Though every project has its own unique quirks and challenges, most implementation problems stem from one or more of the above factors. Only after a thorough discovery can you develop an appropriate plan to shore up the project. The truth is that there is no stock answer. This is why there’s a high failure rate. However, thinking ahead and crafting a laser-focused plan while maintaining flexibility to combat the inevitable changes and challenges you’re sure to confront gives each project the best shot at success.