Sitting in a war room for a project already 8X over budget and a year late, they’re massaging a RAG report.  “The Boss doesn’t want our analysis, he just wants the numbers”, was the mantra. And so they presented raw numbers, which going in the wrong direction, begat even more numbers, perhaps because as Alfred Hitchcock said, “there is no terror in the bang, only in the anticipation of it.” It was time to ask hard questions, but no one wanted to.

Asking tough questions is not easy in most of the meetings I’ve attended over the years. Definition of a hard question – everyone else in the room immediately decides to check their smartphones. Between the game playing, desire not to know (for future deniability), or fear of not being a ‘team player’, most meetings are kabuki theater.

Business Analysts are adept at capturing features/functions, but they don’t challenge core hypotheses and so the resulting Business Requirements, technical project sizing and resulting planning is sort of best-case. Agile Scrum Masters are supposed to lead the capture of User Stories, but more often than not end up with a number of identified ‘expected’ situations, again, without much creativity or personal risk.

How can we do better?

Fortunately, there is a structured, politically neutral method to obtain all possible needs and outcomes. Socratic Questioning has survived for over 2500 years because it works by providing a structured deep dive into core practices and underlying assumptions, issues and scenarios.  It beats swarming newbie MBA’s into a situation, filling out data points for later analysis, as the data points themselves may be missing or deficient. Not relying on pure data analysis also requires creativity, experience and personal risk taking, none of which are well documented traits of most current MBA programs.

Disruptive projects require two levels of questioning; we covered one line of questioning, project deliverables focused, in our previous posts.  The second line is less explored and more powerful in determining potential for success – the search for, and critical testing, of all hypotheses around the possible outcomes or issues surrounding executing the initiative. Since the low hanging fruit of innovation was picked a long time ago, and even if the project team has identified all possible Use Cases/Use Stories, integrating multiple services, data feeds, and customer facing back-end systems into an end to end functioning experience is not easy. Besides message formats, data definition inconsistencies, customer experience to customer expectation alignment, and update timing (some companies are end of day and other real-time oriented) are serious complications.  Factor in external providers and services and today’s systems are more about Service Integration than Systems Integration – a whole new level of difficulty needing thorough ‘what-if’ coverage.

Who runs the questioning process? Internal or external, the facilitator is a combination of Socrates and cross-examiner, where each hypothesis is subjected to deep-dive questioning. Culture matters here – if belittling or marginalizing dissenters or questioners are the norm, or if only the senior team is assumed to be insightful, the outcome is pre-ordained.  Nothing replaces speaking truth to power and surviving the encounter.

Below are the 5 questions we ask, based on both project rescue and innovation experiences:

  1. What is the exhaustive list of all known, outlier and “that’s crazy” hypotheses?
  2. What evidence do we have proving these can happen at all? If we don’t have the information or experience to support our opinion is that because we never captured it or is it impossible to happen?
  3. But if any of these hypotheses do happen, especially the ‘impossible’ category (which have a strange habit of occurring anyway), what else would be affected or would be a related upstream or downstream effect?  How does this affect the underlying business logic? If our competitor did this to us, what would be the hit?
  4. How do we ensure the most desired hypotheses happen or fix things if the worst case occurs?
  5. How do we measure the ongoing operational status of each, as well as an early warning requiring action? How much information is required to get an accurate read?

Why avoid using deep questioning before everything blows up? It can be painful until mastered, but as Hitchcock said, “when all these are removed and you can look forward and the road is clear ahead, and now you’re going to create something…”

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC,  http://www.growroe.com , focusing on companies, initiatives and products where technology is the primary means of delivery and revenue. He is one of their senior Turnaround, Transformation, Program Rescue and Process Rescue leaders.  As a Change Agent, Trusted Advisor, Program Leader and Interim Executive, Rich has over 25 years hands-on experience reshaping companies, Operations, IT/Systems Integration and strategic initiatives.  He can be reached at richard.eichen@growroe.com, and followed on Twitter, @RDEgrowroe

The same tech contractors win over and over. And we’re shocked, shocked, when the outcomes repeat. How to avoid this trap.

There’s 1800 pages of legalese in many large system Federal IT procurement contracts. So it’s no wonder the largest and best known IT contractors win the heftiest  Federal and Fortune 10 contracts because they better understand the procurement process and have the staff overhead to run the gauntlet of writing the RFP for the purchaser, replying to the RFP they wrote, and then jumping through the Procurement hoops to secure the deal.  They’re experts at playing the game, getting additional funds as needed, adept at covering themselves and becoming part of the background.  Same in the private sector since usually it’s the same companies who know how to fit into larger organizations and not rock the boat.

OK, you’re the Business leader on the Project Steering Committee, responsible for an expensive and visible project, such as an ERP, a Mobile Payments app, or a Policy Admin replacement initiative being delivered on time, on budget and fulfilling the underlying investment business case. Now, the technical rep to the Steering Committee, who can be internal or from the contractor, has just launched their PowerPoint showing all the reasons why they will be delivering extremely late, very much over budget, and with reduced scope for Release 1.0.  What do you do now? You ask questions, such as “how did we get here”, and “what do I need to get you to move this back on track”.  The technical rep has two options:

  1. Use the KGB interrogation survival strategy – shrug their shoulders and claim they have no idea how we got here, but they’ll get back with a plan for the next meeting
  2. Launch into a well-rehearsed pitch for more time, more money, more staff, and even more scope reduction for Release 1.0.

You, in turn, have 3 possible responses:

  1. You wait for their plan to be presented at the next Steering Committee and during that inter-meeting period, you start paying increased attention to your LinkedIn relationships
  2. You stop the project; declare victory and move on to something that might actually work out.
  3. You immediately convene, to borrow a technique from Medicine, a Morbidity Mortality Board. Yes, we use that name because it has all the right gravitas.  When we hold such a Board, people understand the project is in critical condition, and we’re trying to figure out why so it does not reoccur or the project will be shut down.

In our experience, only Option #3 will create a positive result, justifying the spend to date and furthering the business goals.

This Morbidity Mortality Board, adapted to IT/Business, determines why any delays or missed milestone is occurring, and it is a formal meeting with written inputs, not a finger pointing session and has a single individual or team assigned to fix the issue. Overall, there are 5 serious investigative paths:

  1. Did a poor judgment call assume the impossible could not happen here – what else is being assumed as an outlier situation or is impossible?  Did someone miss clues or early warnings?  Do all the team members have good judgement or will they just nod their heads?
  2. Is the root-cause a systemic or methodology flaw necessitating improvement before restarting? Use the 4 P’s: People, Place, Policy and Process. The key is not to attack symptoms but to fix the root-causes. This is especially true about key contributors and leaders.  Are they burned out, talking vaguely about how “no one understands what we’re trying to do”, or “we keep trying but we can’t make the users happy”?  These may be indicative of key people being punchy, and it’s best to replace them ASAP.
  3. Poor execution led to higher errors, unstable code, understaffing or requests to redefine scope (usually this means ‘reduce’)
  4. A hand-off either did not occur on time or the hand-off was insufficient, had unexpected elements or was not tested and did not fully function as required
  5. Specify the threshold to shut down the project. What is the last straw, or straws, which can be measured or demonstrated and which would lead to ‘stop the madness’.  This doesn’t have to be an egregious example-we had a situation where an EVP of a stalled, over budget, reduced scope project hit that mark upon seeing he was being charged back for a developer’s Big Mac on a Sunday night (i.e., the contractor was not making even a $6 investment in the project).

How to avoid ever getting to this disaster stage?  Ask tough questions before kickoff:

  1. What will this new system look like in the final-successful state, as described by the Business?  This becomes the guiding document by which all decisions will be based.
  2. What is the minimum set of Business functions we need to deliver to achieve the most important (not the easiest) business goals, and a satisfactory Customer Experience? How do we enhance this baseline release until we have a complete system?
  3. Is the contractor the best fit or the vendor who wrote the RFP in such a way they became the best fit?
  4. Is the winning contractor’s team as deeply experienced in their responsibilities as the Business is on their side? Will they do a bait and switch?
  5. Is this vendor the ‘default’ or ‘preferred’ vendor based primarily on a heavily discounted Rate Card? If they staff at the lowest rates, can they make money?
  6. How are we ensuring quality and avoiding last minute delays due to slightly incompatible code made by different developers or contractors?
  7. Do we have a robust test environment set up; is a comprehensive set of test cases defined, representing the system’s true real-world use (see #1, above)? Hint: if they say they’re performing Continuous Integration and do not have a robust test environment built, pull the cord and stop the assembly line until they have it up and functional.
  8. How is the project organized and timed? If multiple parties are involved, who is one person responsible for signing–off on, and then enforcing, a single set of coding conventions and the end to end solution architecture?  This also applies to comments and code documentation standards and reviews. As for time, what is the exact date needed for go-live? All planning reverse solves to this date.
  9. Has the contractor staffed the project with employees having standalone levels of hands-on experience? It’s not your issue to help a contractor empty their bench of newbies.
  10. Who are the highest managers from the supplier and IT and the Business, all of whom will be involved on a daily basis, and what is their empowerment? On the contractor side, ensure the representative is a technical resource, not an Account Manager/Business Development person.
  11. What is the threshold in terms of time and money when 1 – it’s time to swap out the vendor/contractor or 2 – shut down the project? Clearly state the criteria to all participants, so they know, upfront, failure is not an option, and this is not an exercise in perpetual billing.

Large and complex systems, especially those with multiple data feeds and integration touch points, are hard to design and then develop successfully even under the best of circumstances.  Having a weekly or monthly meeting and then assuming all will fall into place between meetings is as unhealthy as pretending if you don’t ask, it must be Ok.

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC,  http://www.growroe.com , focusing on companies, initiatives and products where technology is the primary means of delivery and revenue. He is one of their senior Turnaround, Transformation, Program Rescue and Process Rescue leaders.  As a Change Agent, Trusted Advisor, Program Leader and Interim Executive, Rich has over 25 years hands-on experience reshaping companies, Operations, IT/Systems Integration and strategic initiatives.  He can be reached at richard.eichen@growroe.com, and followed on Twitter, @RDEgrowroe

3 Real-World Tips: How Not To Run Your Next System Project by ‘What Me Worry’

Mad Magazine was how we learned the truth behind the curtain.  The Cold War was on and Spy vs. Spy was as good as Boris and Natasha. Product commercial parodies taught us how to think through the hype. For those of us of a certain age “what me worry” is a funny tag line, but it’s not a systems contracting methodology.

Contracting for a system implementation and integration requires understanding how systems are built, structuring the contracts accordingly to avoid overcharges and place responsibility where it needs to be at each key project gate.  From what I’ve been able to glean from the papers and news, it seems the healthcare.com contractors were brilliant in contracting. What did they do, and as buyers how can we not repeat those practices to our detriment?

1 – Final authority was unclear:  each ship can have multiple Captains, but only 1 Master of the Vessel

Who is running the project? You or the contractor?  This problem was solved eons ago during the ancient development of maritime trade.  To this day, each ship has a crew, and can have more than 1 Captain, but only 1 Master of the Vessel.  Make sure yours is highly qualified and empowered to demand answers to key questions and not be afraid of having a contractor perform an end-run to another executive or have their jobs put on the line.  I learned this the hard way when I competed against Big Blue while they were at the height of their power. Their form of an end-run was taking a hesitant CIO to their boss and have this CIO explain, in front of Big Blue, why the CIO didn’t agree with their particular proposal or recommendation. After being provoked, the CIO would lose their cool, and then the Big Blue rep would respond “unfortunately Bob/Jane is not objective in this matter”.  This probably contributed to the saying ‘CIO means Career Is Over’. I knew several instances where this vendor had an office near their customer’s CIO, and just as big.  Think the CIO was going to question anything? That’s all changed now, but contractors, especially Gov’t contractors, are sharp elbowed to this day.

Our recommendations: Assign a ‘Master of the Project’, which is more than the lead Project Leader, since most PMO’s are staff oriented without line authority.  Having a ‘Master of the Project’ does not mean everyone else if off the testing hook.  It simply means the Master has the final say on acceptance, payments and Organization Change Management, and it is well understood any end-run around them would not be painless for the contractor.  Just as the Master of the Vessel has an Executive Officer to carry out orders at a tactical level, have each contractor assign an empowered (technical, not sales) tactical leader, reporting directly to your Master.  The Master of the Project should also have the authority to limit the number of participants to ensure focus.  Look at the org chart.  When you think you may have too many participants to control, remember this astronaut quote,  “how do you think you’d feel if you knew you were on top of two million parts each built by the lowest bidder in a government contract?”

We also recommend establishing a new testing stage, Pre-UAT. Contractually, User Acceptance Testing (UAT) typically triggers a payment event and the beginning of the warranty period.  We recommend scheduling a Pre-UAT step as a way to thoroughly test the system as if it was in final acceptance phase, but have the contractor repair any defects identified at this late point at their own expense.  Once the system is tested bullet-proof, it can then be promoted to the payment triggering final User Acceptance Testing phase. Build the Operating Model into the contract, in detail.

2 – No one specified ‘who tests what?’

Systems have 3 levels of testing: developers run Unit Testing (UT) to confirm the code works, they then perform Systems Integration Testing (SIT), to ensure everything talks to everything as required to go end to end, and finally, they present the finished product to the customer for User Acceptance Testing (UAT).  If the contractors were “not responsible” for testing, does this mean they did near-nothing?  Having end users, Beta Testers or otherwise, banging away to test the site is not Unit Testing or Systems Integration testing, it’s hardly User Acceptance Testing – I call end user testing that late in a project ‘Panic Testing Before Updating LinkedIn Profile’. If these contractors did not conduct testing, it implies they did not have a robust testing environment set up, which means they would have trouble mapping any end user found defects to the 500 million line codebase.  Repairs would be expensive, but at cost+, profitable.

Our recommendations: Require, contractually, all code be tested at the Unit and Systems Integration levels by the contractor, followed by Pre-UAT (see above), and only then at the per-phase User Acceptance level to trigger the payment event.  Include end to end and stress (volume) testing, as well as resource efficiency at extreme loads and handling outlier error scenarios.  We also recommend using an outside Static Code Analysis service/tool to ensure each module has a coherent architecture and is not, in developer vernacular, a ‘Big Ball of Mud’, which inherently is unstable and difficult to enhance and maintain.

3 – They locked in profits through the cost+ method.

This probably answers why they kept coding even though they didn’t know the full range of specifications. It also explains why they kept coding, writing 500 million lines of code, or 10X the size of an operating system, one of the most complex yet optimized pieces of code around. I don’t know this for sure, but I’ll bet they also used a blended rate for consultant hourly fees, allowing them to substitute the cheapest resources, which would also take longest, and maximize profits.  It also stands to reason they probably could charge full freight for a copy and paste of previously written code (which may also explain how they hit the 500 million lines of code threshold). It encourages sloppiness, which can affect system stability and performance.  The standard answer of “we can always throw more Cloud resources on it” is true from a Computer Science sense, but less so for the company paying for those added resources for the next 10 years.

Our recommendations: Fixed fees are always better, and a means to determine these fees is to run a ‘T&M with a cap’ scoping project up front, followed by a comprehensive project plan and cost forecast tied to the scoping efforts results.  We also recommend having the project phased, where each phase has a distinct price. In those cases where a contractor will not agree to a fixed price (and we can see where that can be the case), we recommend each phase is billed as T&M with a cap on total spending for the project and phase.

Assuming the vendor has done your type of project before, they should have a ‘starter-kit’ of reusable, already optimized, templates and routines, typically applied with some modifications per project. During negotiations, have them describe their starter-kit, license it as part of your contract, and determine how it will reduce the amount of new code being written.   In one healthcare.gov contractor’s case, they seem to be involved in several State Exchange websites, implying repurposing of a baseline starter-kit.  Be hesitant of someone who does not have  either recent hands-on experience or a starter-kit with clean IP ownership.  At the least, protect yourself contractually through the acceptance criteria process and associated payment terms.

Bottom line, systems development and integration is hard, with different technologies and contracting terms, all of which requires serious and relentless focus, by someone with ultimate authority.   You need a working, viable system; they need to turn a reasonable profit on the engagement. For both parties it’s about execution and the right contract terms will set the tone and steps to make that happen.

BTW, Happy 60th Birthday, Mad Magazine. Here’s Mad’s current editor talking to CNN about the magazine’s history. http://www.cnn.com/video/data/2.0/video/showbiz/2012/11/02/natpkg-mad-magazine-60th-anniversary.cnn.html.  Thanks for the education, Alfred.

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC,  http://www.growroe.com , focusing on companies, initiatives and products where technology is the primary means of delivery and revenue. He is one of their senior Turnaround, Transformation, Program Rescue and Process Rescue leaders.  As a Change Agent, Trusted Advisor, Program Leader and Interim Executive, Rich has over 25 years hands-on experience reshaping companies, Operations, IT/Systems Integration and strategic initiatives.  He can be reached at richard.eichen@growroe.com, and followed on Twitter, @RDEgrowroe

Lessons from www.healthcare.gov: 3 Tips not to blow up your critical systems implementation

MSNBC’s Morning Joe team was lamenting this week on how they all miss the era of desk phones, those Mama Bell stronger than a bulldozer devices, capable of being slammed down hard during an argument. It even gave you a comforting post-slam ‘ring’ from the mechanical bell just to reinforce you genuinely were that angry and had made your point. Try that today with your phone, and chances are the post-slam ring will be replaced with the not-comforting and too soft sound of shattering plastic. Not only were products simpler, they could survive occasional abuse beyond original specs.

Recent example of how not to build and launch a mission-critical system:  built  by a contractor then recently fired by the Ontario Gov’t for underperforming, and with the cost going from the original bid of $55.7M to $292M and counting, healthcare.gov is still seriously troubled and attracting a media firestorm.  The contractor who messed it up (to the point where some tech firms are wondering if it has to be scrapped and rewritten) is deflecting blame to the Business-side (here the ‘politicians’) while being forced to fix it on the fly, which is always the hardest way to fix anything. Anyone who has ever used the analogy ‘replacing the engine mid-flight’ has never been a pilot, let alone fixed a complicated, multi-stage high transaction volume system. The ‘fire the managers’ cry is becoming louder and louder.

But, what we can get from this experience is an open discussion of why critical systems developments initiatives fail so often. Here is our ‘Big 3’ and how to avoid this outcome:

1- Ineffective continuous Business involvement with the project

There’s no such thing as an IT project, short of installing new servers or systems software.  If someone other than a Systems Administrator or Technical Application Owner is going to use the system, it’s a Business project.  Typically, the Business has a vision of functional needs and expected volumes, but then throws development and deployment ‘over the fence’ without transferring necessary contextual information or a fully thought out set of detailed target functionality as seen from the ultimate end user’s point of view, which is more specific than the typical User Stories required by Agile oriented IT. Regarding healthcare.gov, one of the biggest complaints, after someone logs in, is an illogical user interaction flow.  The Business (here, the Gov’t) should have performed Human Factors research and testing at the least, pre-launch, as part of their responsibility.  It was their job to declare ‘done done’ and promote to production.

Follow this rule of thumb – encourage your IT group to refuse taking on any complex project without a well thought through Business Requirements document (which doesn’t have to be longer than War and Peace). Even in IT’s increasingly Agile world, the end-state has to be fully described to ensure everything is architected and built to fulfill the underlying Business need. To put it in modern vernacular, unless you have a Business Requirements document, you can never be truly done-done and the stress and User Acceptance testing scenarios can miss the mark by a wide margin . It is the Business’ responsibility to ensure the new system meets user experience and strategic business requirements, not IT’s.

2- The Business does not have robust systems implementation hands-on experience to manage the project

How many times per year does the average Business-side project manager hands-on implement a complex, sophisticated system?  Chances are the correct question should start with ‘how many times per decade…’ Unlike those desk phones of old, today’s systems are multi-vendor, patched together for speed to market, requiring complex data exchange between interacting systems and feeds, with each component having its own specific ‘calls’, timing, edits, definitions and new release cycles.  Using Agile development methods, IT groups often describe iterations and related sprints around 2 week time blocks, not as a series of increasingly powerful Business relevant feature deliveries of short but varying durations. Unless you can debate the finer points of iterations, it’s hard to manage a project beyond reviewing status reports.

Follow this rule of thumb – control the project from the Business side, including retaining authority to pay for accepted work product by project phase, not transferring funds to IT for them to then spend based on time X FTE’s X internal costs calculations.  Either inside or outside sourced, ensure someone is specifically tasked and empowered with having your back, bridging communications gaps between groups, and asking hard, probing questions that continue to propel the project forward but surface critical (and often not obvious) issues while they can be readily addressed.   Typically, a generalist or part-time Project Manager is not a good fit for this tech-savvy role.

3- Critical technical resources spread too thin on too many projects – and the Business caused it.

We have seen where many firms have enough journeymen developers and team leaders, but too few deeply knowledgeable legacy application SMEs.  These SME’s, in turn, are often over-allocated across multiple projects. In our experience, legacy application specific SME’s are the best people to knit multiple systems together into the correct Enterprise Solution architecture.  Any delay in their participation can lead to missing a QA testing schedule and then having to find a new opening in a future Systems Production Release window, affecting revenue projections and anchor customer commitments. A viable backup plan is to avoid using individual contractors, but instead rely on a systems integration specialist firm with a history of knitting systems together as a team. We know of one instance where a fairly straightforward new Digital product was delayed for over a year. Welcome to recession-reduced IT, and using flex-staffing for deep inter-application integration through low cost  development resources is not cost effective, no matter how tempting in the short run.

Follow this rule of thumb – pre-kickoff and thereafter, review the actual names of all personnel assigned to a project, especially the System SMEs, their experience level, concurrent project responsibilities, and ‘what-if the other project runs late’ contingency planning.  Make sure any flex-staffing is used properly.

We’ve written recently in this blog of the many companies suddenly finding themselves in the Consumer Electronics business as their normally straight forward products are being redefined through customer facing technology. Websites, mobile apps, transaction processing, and customer support systems are all increasingly sophisticated, supporting this more complex set of products.  Going forward, systems will have to support customer facing staff assisting customers in making smart product choices, where poor information can hit repeat business and brand reputation almost immediately.  Customer facing staff will have to explain more complex product features, choices, and use, all during the few minutes this buyer is at the point of purchase before fear or frustration sets in and they walk away empty handed or go back to Google.  Near-future systems may explain product options to customers, then send their decision to a nearby specialized vending machine, like those Best Buy vending machines in airports, or to an online forms application linked to a rules engine, or in the near future, to a nearby 3D printer. The world isn’t simple anymore and system failures are now in the public eye, incurring brand reputational risk.

Desktop phones are great nostalgia, but like simple systems, they are the past and the Business needs to step up and actively take charge of your own projects and thereby your future.

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC,  http://www.growroe.com , focusing on companies, initiatives and products where technology is the primary means of delivery and revenue. He is one of their senior Turnaround, Transformation, Program Rescue and Process Rescue leaders.  As a Change Agent, Trusted Advisor, Program Leader and Interim Executive, Rich has over 25 years hands-on experience reshaping companies, Operations, IT/Systems Integration and strategic initiatives.  He can be reached at richard.eichen@growroe.com, and followed on Twitter, @RDEgrowroe

Data, ROI and Flat Design – 3 Things to consider when refreshing strategic systems and processes

He nailed it from 3 rungs up in the plumbing aisle.  My town’s mayor and local hardware store owner got it right when, while standing on a ladder as we needled him on the Yankee’s sad final collapse he said, “it’s a mark of genius – next year they’ll keep the same team, declare each game an Old Timers Game, and sell out”.

In a confluence of events, the NY Times Sports section had an article this week on how the Yankee’s Manager, Joe Girardi, is an expert at gently easing out aging franchise players.  Then, about an hour later, I was reading an article in Insurance & Technology on how Chief Claims Officers are dealing with an aging group of core claims adjusters, and overall, the claims workforce is ‘transient and aging’.  You can imagine walking into a Claims Processing center and seeing everyone in pinstripes, talking to their agents about increasing autographed picture sales. More likely, you’ll see people processing as hard as they can, being pushed to handle more, faster and using workarounds taught to them by their now retired predecessors. Then they complain using their smartphone social media apps.

Many carriers are rethinking their claims process, from implementing Business Intelligence, to GIS, to rethinking their end to end processes using Lean or Lean like methodologies and not taking the next-gen workforce into consideration.  Too often, so are their consultants.  If you want to laugh at the typical, “synergistic integration”, approach to consulting by instinct, here’s a recent La Quinta commercial, too close to the truth not to be funny, http://www.youtube.com/watch?v=BIIBUksrfwo.  Each of these approaches, summarized as throwing either tech or abstractly developed efficiency at the problem, will not produce the kind of results needed in a world where your existing and prospective customers, both commercial and personal, are already thinking on a ‘what’s my consistent experience’ basis. Bottom line is your new claims staff will be Millennials, your customers a combination of Millennials and Gen X, and their views of production systems and user experiences are different and ready now, or not, their combined vision is the future.

How then, do you implement a process and system survivable for the next 10 years?  Based on our experience, here are 3 key factors:

  1. Use a data driven approach to figuring out what is wrong in each process.  Since Millennials do not want to assign (or receive) criticism, having a strong and convincing data set will allow them to focus on addressing operational issues. Use a leave behind Operational Dashboard, quickly implementable, end-user driven and action oriented, rather than being an overlay.  Ongoing, Management can reuse this dashboard, launching Alerts and Actions Requests in near-immediate responses to short-term issues.  For example, post Sandy, would it have been useful for a 2 day effort to create a Claims tracking dashboard, allowing for both rapid resource deployment and faster mid-journey process fixes? One thing we’ve learned over the years and 50+ process Improvement engagements, the expression “I wish we knew the facts before we started to spend the money”, is still said too often.
  2. Track any Operational Improvements and the associated technology refresh at a finite level, focusing not only on task completion but on the expected ROI.  Focus on the big data identified ‘big stuff’, not overly worrying about things such as relocating printers (as one company I knew just did with considerable fanfare to the staff’s non-surprise).  Use a central Operational Improvement Tracking and Communications tool for social commentary, task tracking and ROI tracking without relying on email blizzards and static project management tools or RAG reports.  This tool, as with the dashboard mentioned above, should be mobile enabled so Sponsoring Executives and team members on-the-go can see progress.
  3. Everyone now integrates their personal and business customer experience into a single viewpoint, so ensure your new technology is not the logical extension of the older screen design paradigms.  Your best Millennial employees, those who are more than workertrons, will gravitate to those companies where production systems utilize a user interface as close as possible to their other experiences.  For example, some core platform vendors have incorporated integrated streaming video conferencing (via webcams) into their Claims process, which besides being hyper-efficient, is also in-line with a generation’s familiarity with FaceTime, Skype and YouTube.  Same for integrated process flows within a core platform, rather than relying on email and manually checking queues. Vendor selection should therefore include more than the traditional test drive, alternatives should be evaluated as part of the in-house/external world integrated go-forward customer experience.

In addition to screen layout and navigation, design aesthetic also plays a large role. Millennials and Gen X are both very comfortable performing complex and accuracy-dependent functions on the limited real estate of tablets and smartphones.  Thus, the rise of Flat Design, the aesthetic where all extraneous design elements are removed, and complex information is easy to understand.  I noticed recently even the local weather report on the  6AM news now uses a Flat Design principles, so how are we to expect someone to leave their home, go to work and then see nothing but spreadsheet emulation applications screens or remakes of 1990’s screen navigation?   Those firms not employing Usability testing for design aesthetic, as well as for content and the daily functional hierarchy, rarely get application development or vendor selection right for the long term.  Implied are treating corporate usability standards as living documents, updated regularly.

New insurance systems and associated processes will exist for the next 10 years, and both consumers and employees have mature views of technology.  Staff retention will be an issue for those firms trying to preserve, or buy, already dated technology.  As Sparky Anderson, one of only 18 Managers in the Baseball Hall of Fame said, “I’ve got my faults, but living in the past isn’t one of them.  There’s no future in it”.

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC,  http://www.growroe.com , focusing on companies, initiatives and products where technology is the primary means of delivery and revenue. He is one of their senior Turnaround, Transformation, Program Rescue and Process Rescue leaders.  As a Change Agent, Trusted Advisor, Program Leader and Interim Executive, Rich has over 25 years hands-on experience reshaping companies, Operations, IT/Systems Integration and strategic initiatives.  He can be reached at richard.eichen@growroe.com, and followed on Twitter, @RDEgrowroe

Is your Call Center the Canary in the Coalmine?

You can always tell the kid who’s new to a sport and needs a lot of initial coaching and TLC.  Starting in a few weeks, a whole new group of players will enter the insurance game, and they won’t be the already well trained Benefits Depts of companies or their long-time insured employees.  They’ll be insurance newbies, their questions will be harder to answer within existing Call Center SLAs, and inbound call volumes will go up by multiples for the next few years.  Many won’t be able to go to your self-service site to get answers since they won’t even know how to verbalize the many questions they need, and deserve, answered.  But like talented amateur athletes anywhere, give them a year to master technique and demand even more detailed answers. Your Call Center is about to change and bear the brunt of health insurance becoming a contact sport, and the customer experience will suddenly be measured in 1.5 minute call durations, not years.

Thus, your low paying necessary customer support evil will become the face of your company and, most likely, the second most crucial component in retention after claims payment. Having long mastered the B2B purchasing and service game with annual contracts between companies, L&H carriers will now have to face annual reselling tens or even hundreds of thousands of new customers. As these consumers have learned with their cell phone contracts, changing annually in a highly competitive market of dueling providers is the desired situation.  Basically, in the Health insurance market, everything has changed with the click of the President’s ballpoint pen.  Every Call Center interaction will be a positive or negative x-Ray of your company’s value proposition and customer experience, not to be measured under the typical First Time Resolution and Wait Time metrics.

Many Call Centers remain a prisoner of their technology, no matter how recently updated or replaced.  For every improved IVR and chat capability, there currently exists a hard limit to the training and functionality a CSR can bring to the caller, making that interaction frustrating if it’s for anything more than clarification.  As we’ve written before, customer support has evolved to multiple channels, where customers now try self-service first, then use chat, and as a last resort call if they remain unsatisfied. Therefore, most inbound callers will be pre-frustrated, not patiently waiting to hear a canned answer being read from a knowledge base.  They will require solutions. Clearly, the best way is to reduce inbound calls in the first place.

Best Practice for Call Centers is to develop a Journey Map, aligned with data sources, CSR entitlements and a range of allowed transactions. Script out the flow within the support organization, rather than make cold hand-offs between support functions, especially during escalations. But even Better Practice is to recognize the Journey Map crosses multiple silos and has to include an end to end view of a customer cycle, from initial underwriting to billing to claims and renewal.  Claims remain the biggest source of dissatisfaction for insureds, and for the newly insured, your Call Center will have to coach them on coverages, deductibles and patient responsibilities.  Claims in particular have several complicating factors affecting customer retention:

  • The amount covered largely depends on how the Provider codes the charge
  • Patient Responsibility and deductibles paid at the time of treatment hits the insured right where it genuinely hurts while it genuinely hurts
  • The claims mobile application or portal users will almost always not understand your content accurately, being agitated or feeling financially threatened.  Then they’ll call.
  • Multi-language support will be required – some Call Centers are bracing for 100+ languages, and how will your mobile claims app deal with this population?

Therefore, L&H carriers must re-engineer their customer facing claims applications and screens, so all insureds clearly understand how they were charged and how you paid the claim, answering their questions upfront.  We had a situation with a Digital Wallet portal for a Health carrier where when we consumer tested what the digital agency told us were great screens (we had our doubts, but what did we know, we weren’t wearing fedoras and arrived on time for meetings), the feedback was almost entirely “very confusing”, and “not sure what it’s telling me or what I should do next”.  We had webcams monitoring their facial expressions and fear, confusion and anger were not uncommon looks. After some back and forth difficult conversations, the digital agency redesigned the screens to allow for the agitated user. Retesting showed the revised screens achieved higher self-service customer support closure rates, thus reducing potential Call Center volumes by several percent.

A large part of preparation is also allocating time and money to end to end quality and reliability checks for the entire backbone – network connections, data feeds, transaction processing time and stability, phone lines, etc., and most importantly, ensuring the IVR menu is sufficiently straightforward for a newly insured person to make the right choice (thereby avoiding hand-offs and call backs).  The goal is to ensure low rates for Call Blockage and Abandonment.  How much money should be allocated to end to end testing (including dialing in as if you were a caller)?  On a new implementation, our experience is in the range of 10% of the project budget.

Another factor is training and CSR scheduling. Always a tough job, being a CSR to newly insureds will be draining for the next few years, with frequent breaks and group training and venting sessions essential for preventing burnout and turnover.  CSR job descriptions will have to change from Phone Demon to Counselor and Sales Rep, with concomitant changes in earnings and career path. Hiring decisions will have to include attitude and flexibility, as well as grace under pressure. SLAs will grow from down and dirty operational First Call Resolutions and volumes metrics, to adding value proposition reinforcement and customer satisfaction targets.

Cost takeout, or at least cost stabilization, will be the go-forward mandate given the 80% Medical Expense requirement and a sure way to do this is to reverse solve inbound call sources – start with the Journey Map, fix anything which could lead to a call, and rethink your Call Centers as the portal to the end to end Organization.

How big a game will this be?  108M Americans watched Super Bowl XLVII, this year, but that involved only about 118 players – factor in 48M uninsured and the Kaiser Family Foundation, in March 2013, concluding 57% of Americans didn’t understand how they’d be impacted by the Affordable Care Act, and the potential call-in volume is immense. Then, add-in Company Private Exchanges and Retirees from major companies being moved to Exchanges, and the game day pressure on Call Centers is only going to increase for the next few years.  Are you ready?

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC,  http://www.growroe.com , focusing on companies, initiatives and products where technology is the primary means of delivery and revenue. He is one of their senior Turnaround, Transformation, Program Rescue and Process Rescue leaders.  As a Change Agent, Trusted Advisor, Program Leader and Interim Executive, Rich has over 25 years hands-on experience reshaping companies, Operations, IT/Systems Integration and strategic initiatives.  He can be reached at richard.eichen@growroe.com, and followed on Twitter, @RDEgrowroe.


Claims Transformation 2.0 is like Consumer Electronics, 5 Tips to up your speed

Lots of complex notes, not particularly bubbly, but “nice” nonetheless. In 2009, a bottle of 1825 vintage champagne was opened (talk about money to burn), one of only 2 remaining in the world, and it was ‘drinkable’, the BBC reported at the time.  Claims Transformation 2.0 projects are not like a fine wine – they don’t do well unless they’re finished not long after opening and are not meant to live 184 years.

Often, when carriers perform a Claims Transformation 2.0 exercise, they leverage BI and Analytics to streamline the claims process, approaching it inside looking out, and not outside looking in, maximizing the customer experience.  We still think we’re implementing an internal system and process for our internal stakeholders, (thinking B2B), but in reality we’re implementing a new consumer electronics product, we’re B2C, and our existing operational and transactional data is probably more justifying what was, then what will be.  Claims processing is now a consumer mobile experience, requiring the convergence of hardware/chassis, content, and a user sense this is worth using in real-life, called the consumption experience.   Consumers identify their mobile device and their apps (including your Claims app) as a single experience, subject to the same B2C criteria. A business person filing a claim has the same technology expectations as any personal lines claimant.

Like it or not, Claims is no longer just about efficiently processing documents, or transactions, or managing cases.  That’s table stakes.  It’s now about doing all that in a manner satisfying the customer’s expectation of experience and outcome, and I’ll be surprised if much of your Big Data has that dataset, which is why so many claims transformation initiatives relying on that data for insights will aim to the B2B past.

Timing is everything in consumer electronics, and speed is cherished.  Apple, even with their upcoming Sept 10th new product announcement, is now seen competing feature to feature with Android, using their own proprietary technology, where they used to own the market and product category conversation.  Apple is a current example of the Success Driven Slowness syndrome, as is Blackberry.  Apple’s Board, it was recently reported, told Tim Cook to start driving in the HOV lane, and stop cruising along in the Local, a conversation which rarely ends nicely for an incumbent CEO in 3-6 months.  When you have too much to lose by being first to redefine a market, you lose even more when someone else does it for you thereafter.

Claims Transformation 2.0 initiatives fall into this rut as well, taking far too long and costing far too much for incremental gains, protecting the carrier’s bottom line while hurting the top-line when insureds believe the claims process works against them.  More often than not, the consultants propose a new technology solution, which, low and behold, they can then implement as part of “1 stop shopping”.  Choosing the right technology is essential, obviously, but timing is the critical success criteria. Since many consultants think B2B, their perception of allowable timing is off key, ignoring the B2C priority of Claims processing.

A recent study, issued by Aite Group, and recently mentioned in an article in ‘Insurance & Technology’, shows how ‘off’ many technology vendors in our vertical tend to be.  Per that article and they’re quoting the Aite study here,  ‘74% of vendors say that next-generation technology is likely to have “a lot” of impact on their business, only 41% offer solutions in the category. This means that carriers are turning to companies outside the pure-play insurance technology industry to meet needs for things like telematics and mobility.’  Insurance is risk averse, but technology dependent, and oddly, many of the most well-known technology vendors talk the talk, but in reality, their products do not use the latest technologies needed for their customers to innovate.  You could add many technology vendors have adopted a low-risk culture, having left the ‘hi-tech’ speedway.  Are insurers then being asked to take the equivalent of the last model year of a car needing a redesign or at the least, a major refresh?

How to avoid the me-too Claims Transformation 2.0 trap?

How do we think ahead, thinking in terms of B2C? We recommend using our adaptation of Facebook’s core values:

1 Commit to the market impacts, not internally facing project goals

Commitment is about getting things done while goals are intents. Before making a Claims Transformation commitment, think through the B2C impacts of taking this approach: new timing, new market driven technology expectations, faster and never ending releases of products and services and distribution channels.  Claims Transformation is a commitment.

Think in terms of how the consumer experience will be affected, not only in terms of how much better you’re going to handle transactions internally as everyone is doing the latter.  Why spend a lot of money just to be a ‘me too’?  Map every part of a Claims Transformation strategy to how it will increase your Net Promoter and other customer satisfaction scores.  Even Commercial Lines customers now think personal when it comes to service, no longer separating the way they’re treated at work by a carrier from how satisfied they are with their personal insurers.

Not ready for a full revamping of the claims process? Then go for a partial approach by stopping the bleeding in the short run and save Transformation 2.0 for later. Engage the CEO, CFO and Chief Revenue Officer, make the vision strategic as well as cost containing.

2 Move swiftly to address what genuinely matters

Many insurers waste time and money fixing things having little market impact or which represent the last way of doing things, often identified through ‘common knowledge’ or a point in time Value Stream Map. Consumer electronics companies use ongoing qualitative and qualitative market feedback to hone their products, focusing every dollar on a detailed and measurable strategic product target.

Claims Transformation requires forward looking insights and so collecting and analyzing the right data is essential.   We recommend implementing a set of data probes into your processes, both internal and customer facing, getting a real-word, functional view of escalation thresholds, timing, claims impacting reserves, etc., and then share this information with Underwriting to shape future claims flow.  Use this operational data to decide on what truly matters to the consumption experience and focus there.  This same data telemetry is then used for continuous front-line execution, monetizing the improvements.

Another factor leading to success is IT readiness.  Digital is relatively new to IT, and many groups have small skunk works or use outside developers.  We would encourage IT be given the resources and responsibility to truly support a strategic claims transformation initiative from the B2C point of view.

3 Be bold; be First

Claims Transformation should be called Claims Transcending, implying the necessary boldness, the willingness to take a risk based on insights and market driven inputs. A recent McKinsey Global Survey, ‘Bullish on Digital’ highlights how C-level executives are focusing on strategically using Digital means to engage customers, and are just starting to think about enhancing employee and vendor engagement via Digital tools.  A clear bold move is linking customers, employees and vendors in the claims process via a digital tool and supportive business process.

4 Be open

Organizational transparency is expected these days, and somewhat contradictory to the prevailing insurance historical culture, but openness in claims processing is about using technology and related processes to leverage pre-existing body shop, mechanic, medical and other relationships and letting the customer know where they are in the final resolution process through push notifications to your mobile app. If a claimant has a doubt or is unclear on their status, you’re not sufficiently open.   Remember – to us, a claim is a loss event subject to fraud analysis and cost control, to a consumer, it’s the undeniable experience with your company. Manage the end to end experience through market research to get into their heads and create new technology and processes reflecting this voice of the consumer.

5 Build consumer experience value

The end of the claims process is not closing the claim; it’s the consumer/insured feeling they had a decent experience during a difficult period of their business or personal life, often called the Customer Claims Journey.  It’s not all the individual touchpoints and interactions such as your mobile app and call center, or approved body shop, it’s how they are woven together into a seamless flow, tracked with appropriate, actionable data (note: gathering all data and then sifting it through a set of filters rarely provides real-time actionable, executable results).  We have been recommending this approach to our clients since 2009 and have seen significant improvements in customer satisfaction, in the range of 10-18 points, which is monumental in an industry where churn and customer acquisition costs are difficult cost/growth/profitability factors.

For example, with a properly designed self-service Customer Support Journey, Call Center costs can be reduced by, on average, 18-27%, from our experience. USAA, which has an EVP for Member Experience, once again ranked high in the recent Temkin Group’s Net Promoter Score Benchmark Study 2012, translating to USAA’s customers being more likely than nearly all other personal lines insurers to have their products recommended by insureds to their friends and family, requiring less advertising than lesser ranked carriers.

What’s my next step?

You have to commit to changing how you think, increasing the pace of product introductions as well as how they are distributed and supported, end to end.

Claims Transformation is about the future, about targeting the right customers to insure, about thinking on their terms where technology and services are intertwined and rapidly improved. Use the right data to draw the right conclusions, avoid going over the Data Mining Waterfall, being swept along by the flow of data.

Develop your Claims Journey Map alongside a multi-release Technology Product Roadmap, versus the familiar decade long Technology Roadmap not fully linked at the detail level to the Claims Journey. More than ever, IT and Ops are tightly linked. The claims systems and process improvements you put in today will be upgraded annually going forward.  If you’re thinking of implementing a new claims system, with a mobile app included, and then standing virtually still to collect the rewards, remember Blackberry had the leading smartphone market share as late as 2010 and then stood still. Ensure all vendors can react as quickly as you will going forward.

Decide if your company is ready to focus on its NPS and other customer satisfaction scores and if so, establish the Claims Transformation 2.0 Cross-Functional Team.

Welcome to B2C, welcome to consumer electronics. Yes, it’s faster paced, and at times blindly exciting, but wouldn’t it be gratifying to be in a business where your product defines a segment and even a fraction of a point of market share translates to hundreds of millions of dollars in new revenue?

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC, 
, focusing on companies, initiatives and products where technology is the primary means of delivery and revenue. He is one of their senior Turnaround, Transformation, Program Rescue and Process Rescue leaders.  As a Change Agent, Trusted Advisor, Program Leader and Interim Executive, Rich has over 25 years hands-on experience reshaping companies, Operations, IT/Systems Integration and strategic initiatives.  He can be reached at 
richard.eichen@growroe.com, and followed on Twitter, @RDEgrowroe.

Evaluating Strategic tech vendors: RFP, Demo, Pilot – what about merger protection? 7 Tips to follow

End of a Quarter, 2 days to go.  The phone rings, or the End-of-the Quarter email arrives.  Ever feel vendors are trying to slam-dunk your business, offering remarkable deals expiring faster than a Snapchat message? There’s a lot of vendors out there, all fighting for their share of the business, measured Quarter to Quarter.  Vendors all live in the ‘now’.

“Of course everything would be the same even if we are acquired, which we are not” – Vendor to my client. They were acquired 60 days later.

“Who are you gonna believe, me or your own eyes?”- The Marx Brothers

Choice is admirable, but when there are too many vendors and too few Quarters for investors’ and bankers’ timeframes, it’s time for consolidation. Some will thrive, some will be acquired, and some will force their customers to exercise their Escrow clause. New vendors will take their standard toolkit (such as BI), and target their 2013 and 2104 revenue growth towards our vertical. A strong vertical, spending money on technology, a lot of it driven by new and emerging regulations – the perfect target for aggressive acquirers and activist investors looking for a high return.  The big cash-out may be perfect for founders and early stage investors, but customers often go through a potentially disruptive transition period.

INN’s online newsletter recently had a piece, regarding the state of M&A in Insurance software vendors (ISV’s), and while the author’s comments and info on a vendor being sold is correct, they best way to avoid any situation is avoiding it in the first place.  While the author cites some typical inputs on how to protect yourself if you find yourself in such a situation with a key vendor, for those of us who have been acquired, or been the buyer, the internal realities are worth knowing.  For example, shouldn’t you analyze, during your vendor selection process, if a potential vendor seems to fit into the ‘M&A candidate’ funnel? If the ‘40% of carriers are looking into or actively replacing their PAS’ statistic is true, knowing how to avoid buying into an acquisition-bait supplier is essential.

Here’s how we advise clients on identifying acquisition targets, adapted to your point of view. Incorporate these 7 tips as part of any strategic systems vendor selection process:

  1. Is your potential vendor focused on a niche, a single segment, and how mature is that niche?  Do they have the staying power to meet new technology and regulatory demands?
  2. Do they have superior technology, but cannot afford to go to market against the ‘big guns’, spending the same on marketing, sales, shows, etc?
  3. Do they have the financial muscle to develop a new regulatory-driven capability or report system in a compliant timeframe? If they’ve been too heavily modified for customers over the years, can they make all their clients compliant at the same time or will there be a waiting list?
  4. Vendors are often purchased for their talent.  Does this potential vendor have strong technical expertise, located where it can be nicely leveraged by an acquirer, as Yahoo has done recently?
  5. How will your deal affect their Enterprise Value and Valuation?  Do they suddenly become ‘affordable’ to an acquirer if they miss the Quarter? If their Valuation increases with your deal (due to money and credibility), do they suddenly look mighty tasty and yet affordable?
  6. If acquired, what happens to the Professional Services teams? Do they cash out or feel less vital and walk? What about the shared understandings you had with the now departed Regional Services Manager?
  7. It’s about risk management, like most insurance functions, and what is your IT risk profile? Are you willing to make a multi-year, multi-million dollar commitment to a vendor who could  be acquired within 18 months (so, about the time you go live)?

If your vendor is being bought, expect to be “delighted” by the acquirer’s statements of how rewarding it will be.  Take it for a grain of salt.  Figure out, did they buy your vendor for the user base, or to wipe out a competitor (and therefore your software is essentially dead)?  Many times, an acquisition is structured based on User retention – threaten them as required, but go to the CEO to do it – anyone below can be all too easily replaced during the organizational shakeout post-merger. Finally, be careful of that ‘special deal’, to be done by a specific drop-dead date to get incredibly special pricing.  I worked to unravel a situation where a company was being acquired for its user base, the sales people knew it, and cut whopping discounts for what they knew would be dead products.   The terms sounded wonderful while writing the check reflecting an 80%+ discount, but goodbye updates and support and hello aggressive cross-sell.

We all hear it will be OK since we’ll all live to our contracts, which is clearly the case.  But on a daily basis attitude and spirit of the relationship is what delivers.  You can negotiate  constantly updated code put in Escrow, returning fees if the Change of Control occurs before you go-live, ensuring update schedules are stipulated in detail, getting rid of the ‘then-current’ modifier in any description of fees for licensing and support, but if everyday life is one reoccurring renegotiation, like the scene from the Marx Brothers’ Night at the Opera (http://www.tcm.com/mediaroom/video/224507/Night-at-the-Opera-A-Movie-Clip-Party-of-the-First-Part.html), that 10+ year relationship with the vendor will be subject to entropy.  Even if you push for some form of equity upside when you do the deal, such as applying some amount of any license fees towards a buy-sell with stock options, since it’s not your primary business, is it worth the effort, versus a smooth implementation and support spanning 10 years?

There’s a lot of upsides to buying from a smaller vendor who genuinely wants your business, rather than being pleased to take your order.  Your ability to influence product direction, to know the CEO and founders, perhaps be on the Board, all have real value.  Smaller vendors rely on product excellence, rather than aggressive marketing, to win deals, so there’s a real benefit.  Just go into the relationship with your eyes open.

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC, 
, focusing on companies, initiatives and products where technology is the primary means of delivery and revenue. He is one of their senior Turnaround, Transformation, Program Rescue and Process Rescue leaders.  As a Change Agent, Trusted Advisor, Program Leader and Interim Executive, Rich has over 25 years hands-on experience reshaping companies, Operations, IT/Systems Integration and strategic initiatives.  He can be reached at 
richard.eichen@growroe.com, and followed on Twitter, @RDEgrowroe.

“No bad project news for you, 1 week!”

Eighth Avenue, and 55th street, NYC; a pretty blah neighborhood at the time. Walking around noon to get an equally blah lunch when I see a long line of people waiting, in the sun, to enter a store.  Obviously I wanted to see what’s up, so I walked over, and read the sign – ‘Soup Kitchen International’, the setting for Seinfeld’s famous Soup Nazi episode, aired just days before.  He looked the same as the actor, spoke the same, gestured just as rudely and had strict rules for ordering posted all over the place.  The soup was delicious  Legend has it Seinfeld and others went there a few weeks later whereby the Soup Nazi threw him out, claiming the show ruined his business (not true, apparently), saying sarcastically, “no soup for you 1 week!” Wouldn’t it be refreshing not to hear bad news for just 1 week?

We do a lot of project rescue work, getting a strategic project back on track before it’s officially declared a ‘runaway’ or ‘failure’, and when we ask for  one reason why they’re where they are, the answer 99.99999% of the time is “surprises and a lack of communications about our true status”. Management loses faith in the vendor, the professional services vendor (or the vendor’s own implementers) and even their own PMO.

We recently wrote about having planned failure points in change initiatives, and implementing a common language to analyze and discuss failures so repeatable lessons can be gleaned and institutionalized.  The idea is to both prevent avoidable repeat fails as well as mentally freeing everyone to think out of the box and deliver real breakthroughs.  However, with failure, even controlled failure, comes bad news delivery. So what is also needed, and what we rarely find, is a structured method to deliver unwelcome news, helping everyone move forward towards action without the usual ‘psychological hangover’ or an entire project relationship being labeled ‘Troubled- Severely At Risk’.

By this point in our careers, we’ve all delivered bad news, often mimicking what we saw our first managers do, right or wrong.  For those of us who worked (or work) in organizations with highly structured HR processes, we’ve been trained in delivering unpleasant news to underperforming employees.  So, by now, isn’t delivering a strong message old hat? Can’t we deliver project issues ‘old school’?

Just like the emerging body of work on how to fail fast and with minimal cost and maximum learning (see our previous posts covering this), there’s an emerging body of work on frameworks for delivering bad news in organizations.  You can Goggle ‘delivering bad news’ and see the journals, but basically, as you expect, delivering  bad news has 3 components and are used to train professional unwelcome news delivers – Doctors, Coroners, Clergy and Law Enforcement personnel.

  1. Preparing the content
  2. Delivering the message
  3. Transitioning

Delivering bad news about a project

PR professionals, politicians and wiser project teams use a newer approach, modeled after the 24/7 News Cycle, i.e. more adapted to how people consume information and shape opinions today.  Here’s our version:

  1. Get the bad news out early. As soon as you can see that the light at the end of the tunnel is the #4 IRT Express train, get the story out there, with full disclosure. Once the situation is ‘out there’, even if it’s only the partial story, you lose control and catch-up info sounds like an excuse or spin.  Not good for vendor legitimacy.
  2. Frame what happened. Use terms the listener will quickly understand, free of jargon, but at a detailed level. If the listener asks what time it is, this is not the time to delve into the history of wristwatches. Keep it to all relevant facts.
  3. Present the way forward. A vendor asking for opinions is not a healthy sign at this stage.  Present a realistic go-forward plan, already pre-sold (and ideally, co-developed) with the internal participants.    This keeps you in control of the narrative.
  4. Put the news behind you. Once everyone agrees to the go-forward remediations, put the distressing news behind you and stop referring to it, unless the underlying cause remains unchanged.

Acting on the bad news

How do you receive bad news and move from stunned to anger to action? We’ve seen people have trouble making the transition from anger to action, but ultimately, this situation has to be either fixed or shut down.  So what is a constructive but realistic approach?

  1. Stop your natural reaction. Don’t jump directly into solution mode by micro-managing,
  2. It’s OK to shoot the messenger if need be. By now, vendor judgment (and thus legitimacy) is a vital concern – the key is how much time were you given between when you were given the unfortunate message and when a decision must be taken?  For example, were they within $1.38 of budget when they told you of the need for additional funding?  Is this because they lack financial controls or did they paint you into a corner?  Competent vendors know early on when a project is capable of going off the rails.  The question is, when did they tell you? Here’s a link to Rick Moranis’ question about team legitimacy from Space Balls, and I’ve seen a version of this in real life several times behind closed doors: http://www.youtube.com/watch?v=MhLqPfAylF4
  3. Do they understand what happened, really? Given the facts, as presented, do you see any holes?  Any omissions?  Any gaps? If this vendor wants to maintain legitimacy, full disclosure is required. I recommend interviewing 1 or 2 levels down in the project staff from the Partner/Project Manager to get a street level view of what’s going on.
  4. Don’t blindly accept the go-forward plan. Finally, do not follow the proposed remediation plan without first seeking input from outside the combined internal-external project team.   In my experience, these non-involved counselors provide different perspectives and concerns and can help you access the vendor’s judgment, so you know if this is one time or reoccurring issue. Added fees, if any, are negotiated at this step.

Just like the 24/7 News Cycle, it’s about communications and the best way to avoid receiving bad news is to create a transparent communication culture, so issues are addressed as they occur, while still small.

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC, 
, focusing on companies, initiatives and products where technology is the primary means of delivery and revenue. He is one of their senior turnaround, transformation, Program Rescue and Process Rescue leaders.  As a Change Agent, Trusted Advisor, Program Leader and Interim Executive, Rich has over 25 years hands-on experience reshaping companies, Operations, IT/Systems Integration and strategic initiatives.  He can be reached at richard.eichen@growroe.com, and followed on Twitter, @RDEgrowroe.


Northern Virginia, 1 Metro stop outside DC.  A darkened conference room, no windows, a revolving beacon over the door signifying someone in the room didn’t have a security clearance.  Our sales rep, doing his job, says, “Let’s all get to know each other, my name is Dave”.  Complete silence, until a woman in the back said “let’s just say everyone in this room is named Dave, ok?”  Software sales ain’t easy, but then again, neither is buying.

Insurance systems are hot.  No one was writing a check for much of anything besides toner from 2008 through this year.  Many vendors are hoping the second half of this year will see a run of buying decisions, some of which will keep the vendor viable, others will add one more notch to the sales reps handle. Some vendors with a presence at the recent IASA show are saying they got over 100 leads, where only a year ago, the pickings were slim.  Life’s good, vendors need to sell and insurers want to upgrade older system, right? Here’s the disjoin – the vendor wants to sell with minimal time, effort  and cost while the insurance company wants to buy at minimal risk, at the lowest cost, and at a time in line with their corporate speed of decision making.  Now that we’re all back in the buying decision mindset, how do we bridge the gap?

How vendors sell software and services

Vendors need to scale to survive, and they accomplish this by selling as many copies or licenses/subscriptions as they can, with the least amount of modifications to the basic package, not touching the core code. Good packages are designed to be parameterized for particular situations and have some kind of API or Service Call architecture for tight integration.

Projects go bad when the sales rep/vendor is too eager to make a deal and overstates either the maturity of the product or the extent of current flexibility and functionality.  Why would they do this?  Many vendors are investor backed or barely public and are measured Quarter to Quarter. Founders know if they miss 2 Quarters, it’ll be another Board of Directors root canal session.

Therefore, combining least cost and maximum revenue into a sales cycle yields the standard

 high level discussion>high level demo>paid Proof of Concept (known as the ‘POC’ by vendors) using customer data> hammer the deal closed for the Quarter.

Nice, neat, not too many questions, low cost and let the Professional Services team bill as needed to satisfy the customer, so it’s good money all the way around for the vendor.  In my own experience, I ran Global Professional Services for a software company where there was so much sales force turnover; the prospects demanded I write the proposal and deal terms since they knew I would have to live with the reality of making the package operate as required.  From a legal standpoint, vendors love the No Fitness for Purpose clause, where they say the package operates per published specifications, and they are not responsible if it doesn’t do your job.

A further complication for vendors comes from the consulting research firms, who know the market is flooded with competitive offerings and are emphasizing having the vendors mentioned in their research reports (for a fee). References and site visits are tricky based on competitive pressures and their appreciation you’re not going to tell them of your ‘disasters’.

How customers buy software and services

Customers have a specific business need, to be addressed by new software.  They also do not need a complex piece of insurance processing software ripped apart for their modifications as overlaying new releases becomes extremely complex, time consuming and risky.   Still, the package or SaaS product has to do the job and be flexible enough for the future, but still not fully dimensioned, uses.   Using online video product overviews helps dimension the range of options to be explored; it eliminates some vendors and does not sell any one product.

The consulting research firms are encouraging the value of their services to help narrow down the number of potential vendors to be evaluated, as a way to reduce acquisition Level of Effort.  In general, this is not a crummy idea, but in reality, each sector has their own Tier 1 (default winner), Tier 2 (near default winner, a strong #2) and Tier 3 (others, with varying level of financial stability).  For example, the June/July 2013 issue of Insurance Network News has a grid showing 331 broad criteria spanning 175 vendors.  There are safe choices, future focused choices, and some ‘still hanging on for dear life’ choices.   This is not a slam dunk.

Therefore, the preferred buying cycle combines least interruptions to daily operations, lowest cost, maximum contractual protection and a strong agreement with the vendor the new software will fit a specific need, and be sufficiently flexible for future ‘unknowns’. Paying for the Proof of Concept is undesirable, as the prospect sees it as the vendor’s cost of sales and everyone understands their data is a tangible asset and releasing it, even for a pilot, is not an easy decision.

The sales cycle, from the prospective customer’s point of view, should be,

 a high level discussion>high level demo>deeper understanding of the needs, and how it fits into the remaining Enterprise architecture>free Proof of Concept using mockup data>end user acceptance>proposal>negotiation>decide on go-forward at a pace acceptable to the customer.

As a customer, it’s not in my best interest to have a virtual open checkbook for my vendor’s Professional Services group and so I want everything nailed tight into the proposal and contract, and the idea of a vendor making their Quarter is not that strong a motivator.  References are not exceeding crucial, but performing a deep background check to uncover the delta between proposed and final implementation costs, time overruns, people quality and of course, the troubled projects, is essential when the software is in the $250K to $3M range and the business impact is immense.

How to bridge the gap, i.e. both sides agree on a sales evaluation approach

Both sides have a problem to solve – close new business on one side and not make a poor decision on the other.    Where’s the common ground to bridge this gap?

We recommend you strongly consider 4 factors when selecting and buying Enterprise or business critical software, either installed or SaaS based:

Focus on a pilot (the POC mentioned above) where you do the driving.

The vendor will ask for a paid proof of concept, more as a demonstration of commitment than a cost recovery.  Most POC’s are developed by the pre-Sales staff, and that’s their job, so cost should not be a big factor.  You are committing your time, knowledge and resources to the pilot; you are also educating the vendor in your business which they will then apply towards selling to your competitors.  Hence, your contribution is more valuable than the vendor’s.  Use this to your advantage.  The pilot should be free; the data should be yours but modified to protect the business information. You should use the pilot, on your own, for a month and protect your IP transfer in the build-out process.  If the vendor insists and you agree to a paid for pilot, ask for a credit towards the purchase price.

Have their Professional Services group build the pilot. 

You need to know these people, whom you will live with for the next 6 months to a year, listen well and are committed to your success.  You’ll also get to see if you are getting their A team or a bunch of newbies. Most importantly, by having their Professional Services people build the pilot, the vendor can then confirm their proposed Level of Effort, ideally preventing underbidding, and avoiding surprises down the road.

Review their financials. If they say they are private and do not reveal their financials, take a deep breath and ask again.

There a lots of smart people in this world, hence there are over 60 Policy Administration Systems, about the same number of Claims systems, numerous financial systems, etc.  The question is which are viable for the next 10 years.  As regulations and technology changes,  will your chosen vendor have the bandwidth in terms of talented people and financials to modify today’s codebase, or develop their next gen system for 18 months out? Are their new hires overwhelmingly Marketing or Finance based, or are they nurturing their technology delivery capability as well?

Ask to speak to their Product Manager for your proposed application.

This is the interface person aligning developing market needs with the product roadmap (and the resulting budget implications).  Does this person understand the trends in your business?  If they don’t have a formal Product Manager position, definitely satisfy yourself with their explanation why not. You have to live with this investment for the next 10 years and you should know their vision for that period of time and their ability to execute.

This also applies to a vendor growing too quickly, and which does not yet have a strong implementation partner ecosystem.  How will they scale? Will they pull the best resources from your project to help land a new customer (especially if that new revenues will make their Quarter)?  I had a situation where exactly that occurred and it derailed our project for 2 months.  Is this fast growing vendor known for painful implementation, over budget by a large percent?

Buying Insurance software is not trivial – there are safe choices, but also the up and down escalators of emerging and lagging vendors.  In the end, it’s not a battle between 2 parties, but a joint effort for mutual success spanning 10 years.

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC, 
, focusing on companies, initiatives and products where technology is the primary means of delivery and revenue. He is one of their senior turnaround, transformation, Program Rescue and Process Rescue leaders.  As a Change Agent, Trusted Advisor, Program Leader and Interim Executive, Rich has over 25 years hands-on experience reshaping companies, Operations, IT/Systems Integration and strategic initiatives.  He can be reached at richard.eichen@growroe.com, and followed on Twitter, @RDEgrowroe.