Clearly, choosing appropriate, well-written software from a trustworthy business partner is a good start towards a successful implementation project.

Let's Get Agile

The IT arm of the industry, led by the vendor community, has moved significantly away from waterfall methodologies to various flavors of agile. This is good for several reasons. Waterfall approaches rely on several obviously flawed assumptions including: all business requirements can be known and documented at the beginning of a project, or project phase; business drivers and related requirements will not change over the project lifespan; business users can visualize the end-state look and feel of the software; and the more variables that are locked down early in the project the better.

None of these assumptions plays out in the real world. In the real world business drivers change over time; requirements change, get discovered, get refined and get misunderstood; business users often don't know and realistically cannot know what they want until they see it. Project goal-posts move over time; especially on projects, like legacy transformations, that take years to complete.

Appropriately, vendors have moved to a more dynamic model of project execution based on the agile methodology which emphasizes and embraces change. Agile assumes that users will, for good reason, change their requirements definition during the project. Agile also allows (actually it requires) business users to interact regularly with the system as it is being built and to provide feedback, which is incorporated into subsequent build steps.

Thus, problems and progress are made explicit early and often; user buy-in is fostered and the final product is well understood and closely reflects user feedback. In the agile world there is no pregnant silence from the developers as they build for months, followed by a resounding thud and a “What the heck is this?” from the business community upon delivery,

Requirements, go “Just in Time”:

A related change is happening in the way carriers think about and gather business requirements. Carriers no longer try to define all their requirements at once, at the beginning of the project. In the agile world the overall requirements for the project are defined at a relatively general level in order to scope and plan the project. These requirements, the so called backlog, are then fed into mini-projects (sprints) which refine, finalize, build, and deliver for user verification one chunk of the functional footprint of the new system.

In this way requirements are only focused on and finalized as they are needed, and as close to their being instantiated in the software as possible. Then as we discussed above, users see and interact with the results and get to ask for changes. In this way the business community gets at least three goes at finalizing what it wants, and the requirements process changes from being an unrealistic and stressful front-loaded, siege-like process to a “just in time” exercise that promotes the Three Fs of Requirements Health ( I literally just made this up but bear with me)—Freshness, Focus and Feedback.

Requirements, like vegetables, are much better Fresh. As we said above the world changes around projects and requirements change to reflect the world. Further, the human memory has a short half-life when it comes to details. An SME may not recall months later exactly what they meant by the words in cell L157 of the Claims Requirements spreadsheet. Latency causes problems.

Focus is important because it brings together the right sub-group of SMEs and users, and only those needed to nail a finite group of requirements in a finite timeframe. Fatigue and stale thinking are minimized.

Feedback crucially allows SMEs to learn and adjust. Here are a few important questions that the SME get answers to from the verification feedback loop built into each sprint: Did I know what we needed? Did I ask for what we needed? Was I misinterpreted? In the waterfall world these are big questions; in the agile world they shrink to manageable proportions and are allowed for in the iterative process.

Not Your Father's Project

In a very important way the definition of a project and project success is changing. Traditionally we think of a project as the completion and delivery of a laundry list of specific requirements. The laundry list mentality led to a binary view projects that created huge scope issues. The “if I don't get it now, I'll never get it” view of project requirements, based on many years of IT under-delivery, led to the inappropriate inflation of project scope and all the attendant stresses and risks that follow from that.

While requirements and the delivery of core functionality remain central to the success of any implementation project the emphasis should be and is changing. Now we focus on the delivery not only of business requirements but also the establishment of core capabilities that support business drivers such as speed-to-market and straight-through processing.

In addition to satisfying a list of requirements we are now also in the business of delivering the software capabilities and potential to deliver unknown requirements in the future; an endless stream of which we know are coming, we just don't know what or when. Sustainable competitive advantage is a phrase that gets bandied about a lot. The most important word in this phrase is sustainable, which implies that a carrier must create capabilities that last over several years. If a carrier makes one innovative or disruptive move it may gain an advantage short term, but then other carriers will figure it out and follow. In order to sustain an advantage the carrier needs to be able to innovate repeatedly over time. This can only be done by first creating platforms and capabilities

One of the smart guys in our industry once likened the attempt to develop a legacy replacement project ROI to developing an ROI for putting your kid through college. What you get for your money is potential, not necessarily specific results (or these days with the kid back in your basement guest suite, any result). In one sense the end result of a legacy transformation project is not an end result, it's a beginning. It's actually what you do with the newly established software over the next several years that is most important, not the laundry list of functions that got crossed off.

This I think represents an important shift of perspective that has several benefits. One huge benefit is the reduce scope pressure that can easily warp or even sink a project. Another benefit is the longer term and frankly more realistic view of return on investment. Also, implicit in this view is the understanding that the project isn't ever done. Rather, improvements become doable and constant.

In this world view the definition of project success changes radically. Project scope is never finalized and the project is never finished. The old end becomes the new beginning. Clearly, this is not your father's implementation project.

George Grieve is CEO for CastleBay Consulting. Previously a CIO and still an acting consultant, he has spent much of the past 25 years with property & casualty insurers, assisting them in the search, selection, negotiation, and implementation of mission-critical, core insurance processing systems. He can be reached at 210-887-6423. Follow Shop Talk on Twitter at https://twitter.com/ShopTalk2.

The content of “Shop Talk” is the responsibility of the author. Views and opinions are those of the author and do not necessarily represent those of Tech Decisions.