Product Innovation vs Product Complication: The “one minute strategy” syndrome

When is product innovation a hindrance?

jackalopeWhen it is innovation for innovation sake?

Let’s look at a company known for innovation and great products –Google; they have it right – or do they? It seems to me that product companies have teams that create wonderful new products, (Gmail, Google Maps) and you eagerly await the next one…what is the issue with that you say? The issue is these teams seem to stay with a product and tweak it and tweak it and feature enrich it until it ends up worse with each release. The age old maintainability and reliability over complication leads to poor usability.

These days, more often than not your hear the street complaining about the latest version-“Why did they remove select all?”; ”The search on the new version is awful, where is my old search?”; “Why are they auto filtering my email? If I wanted it in that folder I would have set a rule up…” – all complaints due to playing with the old rather than innovating the new.

Let’s look for a moment to the Insurance market – remember years ago when “time to market” was big? What did they do? Tweak the PAS systems to the point you can set up a new product in three days – to what gain? You cannot create and file a product in that time so why be able to get the PAS updated so fast? And why do they continue to invest in that feature?

Tweaking an old PAS leads to less reliability and increased maintenance; shortening the lifespan and forcing large injections of capital to replace – Why? Why not invest the short term dollars in enabling your enterprise to grow, facilitate change. The new breed of PAS systems are built on real components, with disconnected services and messaging – the Component Architecture.

More and more vendors are building tools based on such an architecture, removing the heavy integration and allowing the evolution of an enterprise component by component. No more breaking the old by adding the new, instead a simpler, proven method of extending or replacing the old without the integration and conversion nightmares of the past.

Why do I say product extension and feature tweaking is a “one minute strategy”? Because just like most Enterprise Roadmaps we see today, this development and innovation model lack thought and lacks a strategic vision. Instead of taking a moment to right the ship and steer a course into calmer water, these strategies propagate tactical solutions that never reach to the nub of the issue. We do not all have $50M to spend to keep replacing so we need an alternative, a different mode and that mode is to embrace the new architecture, get ready for it and then be able to accelerate change.

So next time you look at your product or your enterprise, try to think out of the box and stop trying to make a steering wheel better – it is round and it works…..look for ways to integrate it better….allowing future growth and expansion without the growing pains.

Why do Carriers feel the need to turn to Analysts for key decisions such as PAS replacement?

I have been pondering this more and more – I mean the sell prop seems so good at the onset. An Analyst firm is agnostic, so we are lead to believe, they spend every waking moment researching the exact topic, they do countless rfps and they promise to be right by your side all the way to….that’s the nub isn’t it, to the end of the selection. So let’s not even think about the fact they do not have to live with the decision let us really focus on the value prop.

So we look to an analyst because all they do is research topics like PAS replacement or legacy moderization, and that seems to me to be yet another problem — if you never actually go through the whole process how can you truly have a full understanding? I am not talking about asking carriers and CIOs about lessons learned; I am talking about learning them for yourself and having the key knowledge to really know how the “theory” reacts in the “real world”.Let’s take a fun example – if you decided one morning to reenact William Tell with modern weapons, who would you want to take the shot……shall we review the candidates?

Candidate 1) A man that analyzes weapons every second of every day, he knows every single moving part, the exact interactions, the kick, the muzzle velocities, heck he even talks to sharp shooters about the guns longevity, it’s reliability and confidence….seems to be the perfect candidate – he knows everything with the one exception of ever actually aiming and pulling a trigger.

Candidate 2) A US Army Ranger sharp shooter, he knows all he needs to know about the weapon, he may not know the exact rifling pattern but he does not need to he has something different; he knows exactly how the weapon reacts, the wind, the elevation and air pressure, the distance and drop of flight – he knows where the bullet will end up in the real world, not on paper.

So forget the original question – let’s have a new one – you are an Insurance CIO with an apple on your head and a lot to lose, who takes the shot at the apple? Who do you choose? Interesting thought…….

Technical Debt – Managing near term technical “borrowing” to prevent bankruptcy

In my recent client engagements, I’ve discovered that increased flexibility (in product development / deployment, mobile capabilities, back office integration, etc.) is still top of mind. But, as organizations weigh options for meeting their specific business needs, tailored, custom build efforts may be required when system replacements or refacing/modernizing front ends fail to meet long term business objectives.

Often times, proposed modifications are defined to bolster existing systems as a short term, quick win solution, until a more permanent solution can be afforded.Carriers who elect to undertake custom build efforts in-house are faced with balancing the following resource challenges:

  1. Retaining full-time resources with sufficient expertise in both initial custom development and ongoing maintenance efforts.
  2. Enlisting external consultants who have both System Development Life Cycle (SDLC) expertise and significant industry expertise.

Either approach drives the carrier to consider the cost of ensuring quality design and development practices against tight budgets and competing business priorities.

Although a quick fix enhancement may seem to be the cheapest route, a Software Productivity Research study from 2010 found that a patch is only less expensive through the early rounds of coding. After that, it is significantly cheaper to code — and significantly more cost effective to maintain — for the longer term solution.

Most concerning is the tendency for organizations to prioritize the short term objective without fully considering the potential long term ramifications.  I can see the value of targeted modifications to existing systems for a short term, short expected lifecycle goal.  However, it seems that regardless of the intended short term lifecycle for these “Band-Aids,” the modifications are exercised years longer than planned.  The term “technical debt” has been top of mind in many discussions I’ve had recently, where we face the challenge of helping carriers fully scrutinize their options and understand the consequences of their decisions. Carriers performing more internal development need to understand that any short cuts made for an immediate patch MUST be structurally reworked in order to repay the technical debt instigated to get the fix up and running.

For example, in one instance, an organization has been weighing options to achieve a business goal given several unknown future factors.  Options included expanding an internal system – which evolved through bolt-on requests and had become a critical system – or building these capabilities within a new system.  The technical debt factor was paramount in this case, as the expected lifecycle of the selected solution weighed in heavily.  Given the uncertain future state, a short term solution may work for a year or two, but the probability of a three+ year expectancy drives a far more strategic approach.  Any short term patches made to the existing system would become exponentially more costly to support as the system remains in use.

This doesn’t mean that there can’t be quick fixes applied to meet an immediate need, but carriers should look beyond the next quarter and evaluate their debt repayment plan before making the decision to implement a quick fix.  Nearly every carrier I’ve worked with has an internal system that grew to be a critical platform and now requires full time business and IT resources purely for maintenance alone.  As the cost to maintain such a system grows, so does the cost to replace it. Carriers must consider the true long term benefits and ramifications of their development efforts and make strategically sound decisions to meet both short term needs and long term business goals.

Don’t Let Your Enterprise Overhaul Plan Implode Like the Red Sox….A Disgruntled Fan Vents

You have your architecture design all laid out; the proper resources have been secured and contracted for the duration; the development starts off a little rocky, but quickly smooths out, and you’re sailing along through the project.  Everything’s firing on all cylinders while you’re blowing through all the deliverables with ease, and you can see the potential success coming; you near the end of the project in System Integration Testing – when it all falls apart like the 2011 Red Sox.

On paper, the project plan looked flawless with plenty of time allotted for each stage, including contingency.  Your Agile development method had been tried and tested, and everyone understands his or her role.  You can do everything right to position your company for success, yet fail in the execution.

There are many factors that contribute to the success or failure of a project:

  • Focus and Concentration
  • Expertise
  • Reserves
  • Communication
  • Team Chemistry

It all starts with focus and concentration.  A system replacement project is a full-time job, and if people become distracted by other issues, such as production support responsibilities or competing projects, those distractions impact the quality and timeliness of the system replacement. Just like a pitcher who’s distracted by off-field issues or his next contract can start throwing meatballs, your project resources can be sucked into other issues and neglect their tasks at hand.

Aligning individuals with the correct task for their skill sets is key.  It’s difficult for a project to be successful if resources are overwhelmed by learning new technology. Confused employees beget faulty implementations that must later be fixed or replaced. If a player’s used to playing center field, and you stick him in left with a large wall behind him and much closer to home plate than he’s accustomed to, you’ll be stuck with defensive problems that cost games.  Similarly, it’s also important to have depth and reserves available to fill-in.  Should resources be unable to complete the work, you need competent people available to step in and allow the project to continue without causing a misstep.  If one of your best young pitchers goes down with a back injury, or your “All Star” third baseman is sidelined with a hernia, you need to have people available in AAA who can step in and hold their own to keep things moving in the right direction.

I love the Agile development methodology.  There’s constant communication – everyone meets every day, short sprints of development and delivery meetings, easy to follow tracking reports on tasks, publicly displayed reports on progress – everyone knows what’s going on. Constant communication yields accountability and support. If people see that they may be lagging behind, they’ll put in more time to compensate. If others are ahead of schedule, they may be able to help those whom are lagging. However, the danger is that if one group does lag behind, it can also draw others into that quicksand. They may say, “If the others are behind and no one cares, why should I kill myself to get my own work done?”  Therefore, it’s important to keep everyone motivated with accountability and let everyone know where everything stands.  This methodology also applies to enterprises as a whole.  If your pitchers are throwing so poorly that they can’t get past the fourth inning, it can create derision in the clubhouse. Your DH might start telling players, “If you can’t get the job done, we’ll have to play relievers instead.”  Or, if your new “star” left-fielder can’t get on base and use his speed to score, you need to communicate to the team why those players are still in those positions.  The oft-quoted definition of insanity is “doing the same thing over and over again and expecting different results.”

Not enough can be said about team chemistry.  Team chemistry is most important when the chips are down.  That’s what helps get you out of the doldrums and put you back on top of your game.  The team needs support from management, not only in providing the proper tools to accomplish their tasks, but also to let off steam for a respite and work together on something completely different.  Take a Friday afternoon off for the team to play volleyball on the back lawn with a BBQ lunch, or a laser tag session to get their minds thinking about something else and staying fresh.  In order to achieve success, everyone must pull together.  Get them to socialize with each other and build that rapport where they want to support each other.  Keep everyone working closely, lock them in the same room if you can, because that will help build those close relationships amongst the team.  You can’t have everyone only concerned about their performance and not working together.  You can’t have 25 guys-25 cabs.  When it gets to the end and you’ve lost 19 of the last 24 games, there’s no character there to save you.  Team members will give up on each other and graduate to a self-fulfilling prophecy of loss.  A player might say, “If pitching lets up another long ball, I’m not going to try my hardest to catch the ball.”  The defense gets lazy, balls aren’t played properly, and more runs score.  In those situations, you need to “Cowboy Up” and do whatever you can to win.  You need to cheer for each other and not expect the worst to happen.  If you expect the worst, you’ll make it happen.

Simply putting the plan together doesn’t mean it will be successful. You have to do all things well in order to make it happen and achieve success.

(Personally, this blog entry has been very cathartic.)

Cheese Log.001

Star Trek: The Next Generation Policy Administration Insight from Scottie

Cheese Log Star Date 9/14/2011…..

“She cannae take any more, Captain, that’s all she’s got. The core cannae take any more stress.”

The Cheeseship Enterprise Crew

This is the ever-present line when Captain Kirk would yet again request Scottie to do the unimaginable and provide more power from the warp core. Believe it or not, this is the guide to Policy Administration for all Comic-Con attendees and other extreme fans who like to dress in Star Trek costumes for their weekend barbecues.

However, where is this all leading? Well, why did Kirk always call upon Scottie? Because Scottie had nothing else to do in the show and was supposed to be a main character?   Or more likely, because it’s common to look to the very core of the Enterprise to solve all of our issues?

In hundreds of years, when the USS Enterprise exists, will we always look to the core of our enterprise for the only solution? It has dawned on me that over time, Policy Administration systems and the need for additional functionality or performance have caused people to rush the conclusion that the PAS must be replaced. Most often these decisions are made without the proper planning and expertise to consider the entire enterprise, nay even the universe of solutions outside your enterprise that may either avert the need for such a project or indeed “buy significant time.”

Enterprise planning and the must-do precursor to a successful PAS project is oft overlooked with two major issues arising

  • The Policy Admin replacement may not be the best idea for your enterprise at this time
  • If Policy Admin replacement is the correct path then considerable Enterprise modernization and improvements abound as “low hanging fruit” to the project, oft overlooked and left to rot

So before you call on Scottie and shout at him for more and more or before you decide to buy the new Romulan warp core, I suggest you take a step back to see if, in fact, the Enterprise has other solutions to get you where you need to go. If not, make sure you take full advantage of the upgrade.
Cheese Out.

The ISO Rating Service

Where have I been?  It’s been a long time since my last blog posting and people think I’ve died or gone back to the carrier side.  Actually I’ve been submerged in the world of carrier policy system administration upgrade.  Over the last two and a half years, I’ve been working with many carriers to upgrade their systems to help them increase their market share.  This is not unusual, and in fact policy admin replacement has become quite the rage.  It may even have its own Facebook page.  But these changes have been a little different than the normal selection process, RFP, out with old – in with the new vendor system.  These changes have been modernizing the existing “legacy” system with new web front ends, and expanding the carrier’s product offerings by implementing the ISO Rating Service.

By leveraging the automated ISO Rating Service, carriers are able to quickly come to market with new products to enhance their offerings and become the one stop shop they would like to provide their customers.  Depending upon the carrier’s deviations and the systems they have in place, by building upon the already set rates and algorithms, carriers can be issuing new policies in a matter of weeks, increasing their market share and better serving their customer’s needs. 

Speed to market and the flexibility to modify rating are the two keys to success in the insurance marketplace today.  Carriers typically have a particular market they are trying to reach, such as small service businesses like plumbers, landscapers, or construction, and they want to be able to offer these markets all their insurance needs such as BOP, Commercial Auto, and Workers Comp.  If they already offer Workers Comp, they can expand their offerings into BOP and Commercial Auto by introducing the ISO Rating Service to their existing systems.  Typically, the complexities involved in the integration to the existing environment present the greatest hurdles, but once a solid design is developed and established, the rest is smooth sailing.  The service is updated by ISO and can be easily maintained by carriers without the need for large development efforts when new coverages are offered or rates are modified.

With market share increased, and maintenance efforts reduced, carriers can then go back to doing the fun work – focusing on keeping their Facebook page up to date.

He said, She Said” – An excellent Dating game perhaps but not a strategy for Policy Admin Replacement

Yes I realize it may actually not be the best dating game concept; while it does provide some hilarious moments the last thing we need is a repeat of some 70’s concept that shows us how some couples know so little about each other. However, all too often it seems that the “relationship” between Carrier and Vendor can fall quickly into this mold.

More than any other question, I am asked:

“Why have so many of these complex projects have failed, and what are the main reasons to plan against?”

Most people have the industry standard answers but let’s cut through that and get to the nub of it – relationship.

Now do not get me wrong, fabulous planning and clear well defined requirements are a must but without a doubt, in a multi-year project it is the relationship that buys us more value.

So, what does that make me right about now? I guess I could be the “Hitch” of the Insurance world; just here to try and assist in the art of keeping a relationship healthy – okay so we may not see wedding bells but we will see success stories abound with future reference clients and projects coming in on time.

Let’s talk frankly about what I mean; it is about expectations and reactions to the bumps in the road that inevitably WILL occur. There is no way to avoid them and anyone saying they have a proven turn-key solution should be shown the door. For some reason most vendors refuse to discuss the reality of the situation – my take, let’s set out with the knowledge we will hit issues and work out how we will manage them, not just via a Change Control process or clear management but through good communication channels and openness.

Communication is so critical and both Carrier and Vendor are guilty of “hiding” the truths – for example, Vendors behind on delivery seem to wait until the last second when there is no mitigation approach to raise the hand to the issue. Why would anyone think that is the right approach? It is because over the years we have all shot the messenger. The reaction to such a delay or issue should be one of resolution and joint effort, asking the question “Can we find a way to not increase costs and timeline? Is there a creative solution?” Putting the shoe on the other foot we so often see Carriers resources get pulled in several directions, with current production issues or indeed new product development that trumps the project but more often than not, the resource constraints are not adequately communicated to the vendor. This can cause the vendor to hit hold ups and delivery constraints which circle back around to the first point until there is the cataclysmic “He said, She Said” blame game.

Every issue has a resolution, and if raised early we can normally find a creative method of shifting work phases, re-prioritizing deliverable or targeting additional resource allocation in the short-term – whatever it may be there are ways to solve most of the hurdles we will face if we do not stand there throwing the wedding china around.

Just like any relationship it is all about give and take; everyone has to be willing to bend and “eat a little” – when an issue arises, do not shoot the messenger, work together and find the best way to resolve it. No one and I mean no one wins the war, if you try to “win” the battle.

So next time you hit that point, instead of wondering how to bury it or how to find an “out”, think what “hitch” would advise you to do……and communicate.

The Real Reason Policy Administration System Implementations Fail

Insurance company technology environments are in a state of flux and renewal, and progress has been slow and tough going. The only reason progress has not stopped completely is due to the fact that the need for change is so overwhelmingly apparent that it compels action. The reasons for change are so well understood by industry leaders that they barely warrant mention, but for completeness sake they include: the need to respond to rapidly changing insurance markets and regularly requirements, aging work force, aging and obsolescent technology, and the cost of organizational inefficiencies. The real reason Policy Administration System (PAS) implementations fail isn’t the “why,” it isn’t even the “how” or the monetary “cost,” it’s that the process of change is so difficult for these organizations that reluctance is almost equal to the need.

 

Insurance companies are typically both structurally unprepared from an IT governance perspective, and culturally unprepared from an organizational change maturity perspective. Under the current short-term driven reality that is overwhelmingly directing insurance industry efforts, staff in insurance companies are not ready to make a major changes needed because they do not truly understand, in any substantive way, the real urgency or benefit of proceeding down that path in terms of their own self-interest. These problems are certainly not unique to insurance companies. They are manifest in most organizations with well-entrenched process-driven bureaucracies. Paradoxically, to thrive in these organizations a person must become well-entrenched, which is the antithesis of change. However to survive in the long-term, insurance companies must change, which is the antithesis of entrenchment. That is both the paradox and the key challenge for PAS implementation efforts in insurance companies.

Now, this “change-is-hard” counter-balance certainly plays into the “how” and “cost” factors, but the point is that companies come up with a myriad of excellent plans for PAS implementations and spend millions of dollars over initial cost estimates and still fail. And even if they succeed, the results fall short of expectations, sometimes significantly so. Therefore the “why,” “how” and “cost” are window dressing on PAS implementation efforts.

The postmortems of such effort often focus on the “how” and “cost”; as if the insurance company in question just had a better implementation plan or had better execution or spent just a few more dollars things would have been different. And many times there is wisdom in such observations and assessments, but they often skip over the elephant in the room: a PAS implementation is a gut wrenching contest of wills between the status quo and change, which no implementation plan or amount of money can mitigate enough to matter to the people living through it.

Therefore one must acknowledge that there is personal capital involved that is high enough in a project like a PAS implementation to force individuals at all levels of the company to inadvertently, and without forethought or malice, act against the best interest of the company and/or their self interest. There are people in a typical insurance company who have been there 20 to 30 years, who have spent a lot of time and effort building the workarounds the new PAS is intended to “fix,” who have little interest learning a whole new process while maintaining the old process all things being equal, and who make the “perfect” the enemy of the “good” out of an ethical sense of due diligence. These typical change management issues can be overcome. The methods for doing so are numerous and well documented, but regardless these change management issues create one heck of a headwind on a project as large and complex as a PAS implementation and require a hefty long-term personal commitment from leaders and staff alike.

The inherent difficulty in PAS implementation projects it should be a fundamental wake-up call to the insurance company leadership and supporting staff since so many insurance companies are going to be forced to undertake such a project or go out of business. So before contemplating any movement toward PAS implementation effort, leaders and staff members in insurance companies need to significantly re-think leadership roles in the transformation. Insurance companies need its leadership and the staff to become more self-aware of these cultural challenges so that they can steel themselves to the massive amount of personal capital it will take to pull this off. Once that is done (or well on its way) the insurance company can then focus on the “how” and the “cost” (in dollars), which in the end are the easy parts of a PAS implementation.

Project Management for Policy Administration System Replacements: Art or Science

As anyone can tell you, project management is a key cornerstone to the successful completion of any project, but for extraordinary projects, like Policy Administration System Replacement projects, a more sophisticated level of project management is needed. But what does a more sophisticated level project management look like? The myriad of project management disciplines and methodologies out there can give the impression that complex projects require a project management approach that is more scientific and systematic, when in actuality, the more complex the project the less systematic project management gets. This is a counter-intuitive notion, since one would naturally think the more complex the project (i.e., Policy Administration System Replacement project) the greater the need for a systematic project management approach to make sure nothing is missed. This is not to say the project management disciplines and methodologies out there offer no value on a Policy Administration System Replacement project, because they most certainly do.  However, when managing a Policy Administration System Replacement a project manager should always keep in mind that those methodologies and tools are merely a starting point (i.e. the “canvas”) for that masterpiece that is successfully managing an endeavor of significant size and complexity in practice.

When practicing the art of project management, there are a number of tactics that should be adhered to, particularly on a Policy Administration System Replacement project, which you are not going to find in the PMBOK. These tactics are not hard-and-fast rules in terms of execution, but are more fluid. What do I mean?  Well let me provide 4 examples of what I mean:

  1. Don’t Fall into the Form-Over-Substance Trap – I have seen project managers that can pull together very detailed and comprehensive project plans, create one hell of a status report, capture every risk and issue on a log, and follow whatever management methodology selected for a project to the tee and yet the project fails. In the project postmortem, there are many reasons for a project failure, but in my experience the majority comes down to management. Adherence to project management dogma over substance is a project killer and focusing too much on the paper work rather than results of what really matters does no one any good. Bottom-Line: Use project management methodology and tools as a starting point only and never mistake project administration for project management, because they are not the same thing. So not only should managers not be afraid to deviate from methodology, if they can see how it could provide additional value to the project team and/or the client, a manager should look for opportunities to do so since staying on the strait-and-narrow will bread rigidity that will ultimately doom the project when it does come time to decisively change direction. The art of this approach is in the notion that managers need to know when to let, that which truly does not matter, go when there is a need to focus on critical issues. Reschedule/skip that regularly scheduled meeting, don’t obsess about missing that status report submittal, if the project plan doesn’t get update for a few days that is ok.  Those things are not project management; project management is about knowing when those things don’t matter in light of the overall project goals.
  2. Pay Attention to Your Instinct –  Missing a due date on a project plan, having an identified risk go into red status, being alarmed by the number of bugs being logged  on a just release build of the system code; these are not the primary indicators that there is a project issue. A project manager on a Policy Administration System Replacement project should intuitively know about these issues well before those types of indicators manifest themselves in the normal project management documentation.  It is counter to the way many talk about/view project management, but in Policy Administration System Replacement projects, project managers need to place just as much reliance on the gut than the head in many situations given that they almost never have all the detailed information at hand.  If a project manager is blind-sided by any of these happenings (and yes it will happened at least once on the project), then chances are the project manager is discounting the intuition side of the equation.  If it doesn’t feel right then it is probably not right. Trust that feeling on a Policy Administration System Replacement project and start to take action. In all likelihood it could end up saving the project.
  3. Get On A One-On-One Level – Policy Administration System Replacement projects are large undertakings, involving many people from across locations, organizations, departments, and disciplines; not to mention walks of life. Often it is tough, if not a practical impossibility, to meet all team members face-to-face or talk one-on-one at least once, let alone regularly.  And the advice that, even despite these typically challenges, the project manager should try to meet all the all team members face-to-face or talk one-on-one at least once during the project is not revolutionary, but what I am trying to get at here is that there is another level that needs to be reached. To manage a Policy Administration System Replacement project the “one-on-one talk” is a key strategy for successful project management. The one-on-one conversation is where managers can get key pieces of information, but it is not something best achieved in an overly procedural manner. Picking out a few key people on the project t and scheduling a recurring one-on-one conference call will not do. With that approach it will not take long for the feedback to become obligatory and stale. Sometimes you get your best results when the person does not know when the project manager is going to call to get a status or inquire about their feelings on how the project is going. Also the “key people” you need to talk to are not always the people in the key project roles. A project manager on a Policy Administration System Replacement project will need to figure out who and when to call; that is the art of the process. The one-on-one conversation should be informal, but these types of discussion should be a common occurrence regardless of project status or stage. The one-on-one conversations a manager has on the Policy Administration System Replacement is often more important than the regularly schedule status and team meetings that are a staple of all projects (big and small).
  4. Listen More Then You Talk At Status Meetings – On a Policy Administration System Replacement project it is a practical impossibility for the project manager to read every email, be up-to-speed on what everyone is working on and the status of the applicable tasks all the time, which is why the art of listening gets a special place in the management of a Policy Administration System Replacement project.  And I don’t necessarily mean listen to the specifics of each team member report, because, while the technical/operational details of a report is of course important, how a team member gives their report is often more important. You can get technical status details in an email, but you can’t get other details that are perhaps more telling, like: body language, pauses, voice inflections, etc. These tell-tale-signs indicate whether a team member really knows what their assignment is, how it is progressing, are they disengaged from the project, etc.  This information will help the project manager determine who he/she needs to follow up with outside the team meeting and who is on track and therefore need less oversight in the short-term. If managers ignore this type of involuntary feedback, they could miss personnel/ operational task issues that could result in level project issues if not address.

There are of course more non-traditional tactics employed in the management of a Policy Administration System Replacement project, but the main point is to try to shift the thinking that the key successful project management of a Policy Administration System Replacement is a greater adherence to methodology and tools. Project management is an art as well as a science and the Policy Administration System Replacement project requires at least an equal measure of both to be successful.

PAS Replacement – Planning and Forethought: Worth their weight in gold

As the economy continues to sluggishly creep up the road to recovery, firms have varying notions for how to best position themselves for success when the market changes.  As noted in a recent survey by SMA (Strategy Meets Action) of 28 insurance executives, one of the top ten imperatives for insurance companies in 2010 is enabling a “fast path for new product development.”  This objective, of course, is constrained by the systems that support the current product offerings, and these systems inevitably arise as the roadblock to achieving the business objective. 

Tightly coupled with this objective of quicker time to market on product offerings is the inevitable need to increase efficiencies in current key business systems.  Whether by enabling communications between disparate systems for a more holistic view of the insured, or simply working to decrease the endless sea of manual, paper-based processes, there are several related steps that should be considered from a competitive advantage standpoint; but we’ll get to that topic another day. 

Within a single organization, multiple policy admin systems have likely been deployed – each with the best of intentions to streamline operations, allow for enhanced product offerings, consolidate numerous existing platforms…  all of these are typical scenarios in the companies we’ve worked with.  The challenges come when companies realize that a nine month time to market for a new product offering won’t position them well in the competitive landscape.  Whether that turnaround involves a highly skilled back office implementation team, or slamming the product into the current system, updating a myriad of sprinkled interfaces to just to get it out the door, the reality still exists – the systems just can’t compete. 

In response to this realization, we’ve had many discussions with companies who are looking to replace or consolidate their policy admin systems, and have experienced significant pain in the past in trying to do so.  The foremost suggestion I’d offer relates to the stage that is consistently undervalued and poorly positioned:  planning.  It’s critical to realize the importance of adequate planning before you go down any path.  We’ve seen time and again organizations who short change the planning and requirements process thinking that they have it under control.  Companies who say they haven’t had any problems to date and things are running smoothly likely have limited or no visibility into the actual state of progress, deliverables, and budget on any of these replacement projects, which all surface at the 11th hour when everything turns from “green to red.” 

When it comes to implementation and delivery, these companies find massive divergence between their expectations and the pending solution due to lack of preparation and planning.  I won’t even get into the pitfalls we continually encounter in the requirements gathering and definition process; again, a topic for another day.  But simple questions like, “Has the business case been defined and executive sponsorship obtained?”, or “What is your initial rollout strategy?” must be answered, and agreed to before you even start the package selection process. 

You have to ask the question: What were you looking for in a new system?  Look at your competitive landscape, and focus on what makes your company unique (hopefully in a positive way), and provides you a competitive advantage in your space.  As you embark upon the package selection process, there are many platforms that may have flashy, robust functionality (as the vendors will be more than happy to demo  when you get to that stage of the process), but you need to focus keenly on the specific functionalities that will enhance your organization’s differentiating factors, and look under the covers.  Whether you’re doing the vendor selection yourself or with assistance from a consulting firm, be sure to dig deeper on the key requirements you’ve noted, and ensure the demos meet *your* critical scenarios to avoid purchasing a flashy platform that fails to meet your needs.  When all is said and done and your peers ask how the current system is working (if you’re fortunate enough to get it up and running), while it may be lovely to have the newest flashy system, if it doesn’t meet the original business objective and enable your key differentiating factors, it might as well be a Fisher Price play set.