Skip to content

Will my strategic software vendor become the next pets.com? 6 Real-World Tips to consider

Billion dollar valuations for apps without a revenue stream or a defined model for being in the black and self-sustaining are now common.  Sales reps are being pressured to bring in their numbers, with quotas ramped up and renewals becoming increasing critical as a source of revenue and commissions. A young CEO thinks a security breach is OK while other vendors are launching products with ‘minimum viable’ stamped all over them.  Older sales reps with established networks are being brought in to capture fast initial sales at crazy commission rates, but these reps often can’t fulfill their missions (and heavy draws) and leave. Choosing a vendor is difficult if the product or service is strategic and the relationship (and use) is long-lived or your company is a more sophisticated operating entity than this new key partner. Culture matters and a disjoin between organizations can lead to daily negotiations for what you consider obvious.

On the other side of the table, more than ever, these days being a vendor is a Darwinian experience, where today’s leader is tomorrow’s “wow, haven’t heard that name in a while”.  Even mature and successful vendors who are now larger organizations themselves are being challenged in specific areas by more agile start-ups.  We’re hearing more frequently where a large tech vendor is “being run by Finance” without the Yin/Yang of a resident leader with a vision of the future embraceable by both the market and employees.  Or worse, they’re being driven by people who think slick and glitzy features and not customer value, such as LG’s recent announcement at the Consumer Electronics Show of their washer/dryer with texting capability. Toasters with Twitter followers next?

For newer vendors, pressures have never been greater to push stuff out the door, relying on future updates to complete the product, which does not benefit the purchaser. Early stage investors are fearful of lowered valuations, not just hurting their current interests, but setting the stage for them to be hurt even more if additional funding is required, and so having something out in the market is essential for buzz (and buzz ups valuations in the short term).  For the customer organization, buying an unfinished product creates pressure to help the vendor fix it in real-time, again, making daily intra-company interactions strained when the immature vendor’s culture is more focused on growth than functionality. It’s like being in a foreign country, and while both of you speak decent English, your culture based logic trees are so different, and so each of you reach very different conclusions based on the same inputs, requiring additional negotiation.

What are the considerations in choosing a key software vendor besides straightforward pricing and functionality? Here’s our top 7 based on hard-won experience:

  1. Is their offering ‘minimum viable’ or a business mature product with a full set of functionality to address your business needs? Many Cloud based offerings are shoved out the door to gain market share fast, which is OK for non-mission-critical flashy apps, but death for complex business applications where availability, functionality and throughput are critical. We’ve spoken with a number of highly talented, high credentialed and highly paid developers averaging a decade of experience who are not yet schooled in differentiating between the Phase 1 best functionality vs. overly relying on iterations to get it fully functional a year out.
  2. Steadily growing new customer client base, including add-on products to existing customers. Have they owned the product you are buying for at least 18 months (to provide time for post-acquisition managerial and product alignment shakeouts to settle down)?
  3. How often do they introduce significant new and well-tested functionality? Have they ever taken away functionality during an incremental/iterative release or business model refinement? Is their business-model more focused on shareholder-value than customer-value?
  4. Ability to use only parts of an end to end suite, should you decide the entire suite is not uniformly best-fit. Plays well with others – ease of integrating other/outside modules via well documented (and existing) APIs and XML formats.  Do they have an ‘us vs. them’ culture?
  5. Vendor’s HR culture is nurturing for energetic talent; is the customer facing talent committed to you and willing to do ‘whatever it takes’ for your success? Are they empowered or hesitant to go out on a limb? Do customer facing employees seem happy to be around each other? Do they give straight answers with dates met? Is their average customer facing employee better than your own average employee?
  6. CEO/President’s tenure in the job and Glassdoor rating of at least 70% with an overall company rating of at least 3.0. TechCrunch recently had a blog entry from Cowboy Ventures, describing their research showing a strong current where the most successful Enterprise software (or SaaS) CEO’s are in their mid-late 30’s or older, and over 40% of these companies changed their CEO from a founder to a ‘pro’ pre-IPO. Alternatively, they may not have a Glassdoor score if they are too small or very young. Check via LinkedIn and other sources to see if they have high turnover at the executive and senior executive levels.  Nothing disheartens developers more than working for a company where they feel unappreciated, boxed in, or off on a tangent, so tech companies are only as strong as their developers’ opinions of their leaders. We also recommend reviewing their locations – is Development and R&D located in the midst of a deep talent pool?
  7. Issues can occur based on a poverty of poverty or a poverty of riches.  Some smaller vendors are not built to survive a large financial shock, such as a key customer not paying their bill, causing a cash flow issue.  This could force a company sale or some quick change in their business model or layoffs.  The poverty of riches side is equally vexing.  Since it’s all about growth these days, we’ve seen increasingly where some vendors sell new customers beyond their ability to implement their software per the client’s needs.  Their consulting units are running out of resources, projects are being delayed, and customer service for existing users suffers as resources are pulled to high margin consulting services.

Choosing the right vendor is far more than doing a product fit analysis and negotiating a price. If the product continuum spans immature to stale, the key decision factor is balancing product newness/fit with a vendor who understands how to sell, contract, add functionality, and support a company your size. Most Fit/Gap vendor eval processes do not sufficiently emphasize the relationship, relying more on simple scoring into boxes as less soft-skills/experienced based judgment is required.  The best buying decisions are weighted towards intra-company fit and the multi-year relationship.

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

5 CHALLENGING QUESTIONS TO AVOID THE “IT NEVER OCCURRED TO ME” TRAP

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.

 

%d bloggers like this: