Why can’t ‘modern’ companies innovate?

What is a ‘modern’ company? Several large and established companies are starting to define themselves as such – but they seem to be searching for meaning and relevancy. Many stagnating or slow growth companies, struggling for their identity and vitality, use the term ‘modern’ as a way of saying “what we need to do is fast innovation.” ’Modern’ companies change some part of their identity every few years as they search for some path forward. How hard can innovating be over declaring yourself ‘modern’ and ‘progressive’ or even ‘cool’? Ask McDonalds, who, self-definition aside, remains shackled to their old model as evidenced by updating Ronald McDonald in 2014, creating a sort of nondescript clown doing a bad business casual Friday. The public’s reaction was not kind then and the jury is out on how  the recently named new CEO will breathe relevancy back into the corproate body unless he drops sloganering and starts innovating.
Read More

Internally Crowdfunding Innovation – 12 Steps to Create Your Internal ‘Innovation-Starter’ Marketplace

Is your innovation initiative challenge driven or challenged?

Steve Jobs said innovating was not about spending big, it was about leading people to think big. Much like the Good Judgment Project on world politics and events, the best answers and insights are often crowdsourced. Why do we typically have only a select few employees or locations contributing to new ideas? It wasn’t Henry Ford who invented the automotive assembly line – it was a mechanic, extrapolating what he saw at a slaughterhouse.

How do we democratize innovation in our organizations? Crowdsourcing and crowdfunding are fueling the fast growing Maker Movement, creating new products by empowering people atypical to the ‘usual’ new product development process. Why are we not embracing and leveraging this broadly accepted cultural trend inside our walls?

A few leading-edge companies are harnessing the Maker Movement via a concept we’ve seen work well, the internal ideas marketplace.  Modeled conceptually on Kickstarter and TopCoder,  group wisdom dictates winners and losers through gaming theory based ‘investments’. Why is this different from Open Innovation? For one thing, you own the ideas, without issues relating to Arrow’s paradox and previous art. This isn’t theoretical – Xerox became a major Apple shareholder as a result of a well-meaning graphical user interface demo to Steve Jobs.

Based on our observations and experience, here is a list of steps for implementing and running what we call the ‘Innovation-Starter’ market. While we deal with some degree of mechanics in this list, the real underlying principal is creating excitement around blue-sky thinking:

Setup

  1. Every employee has access to the ‘Innovation-Starter’ site on your intranet or SharePoint. Invite a select number of external SME’s and big thinkers. New DNA is always good for an organization.
  2. Annually, every employee gets 10,000 ‘Innovation Bucks’ to invest in the Innovation-Starter marketplace, funding ideas other than their submissions. Since the desired output is delivered innovation, and not merely participation, we use three classes:
    1. Inventors
    2. Active Investors who have made suggestions and concept refinements
    3. Passive Investors who have allocated their capital to an idea without refining the concept
  3. Two classes of innovation are requested – those answering specific customer needs or market dynamics, and pure brainstorming ‘what’ if we could’ ideas. Create innovation momentum, passion and engagement among employees by communicating challenges and the ‘leader-board’. Encourage them to visit the site and see the energy happen.

Adding Ideas looking for Investments

  1. Issue a specific challenge – is it best new idea or solving for a specific vertical market/Use Case/Domain Model?
  2. An idea must include a description, an understanding of who would be a customer, fit/purpose, and why it is a real innovation and not a logical refinement of an existing product or service.
  3. Ideas are posted anonymously to prevent politics driving a poor outcome, and are listed as ‘Pre-Investment’, i.e., not open to Innovation Bucks allocations.
  4. The full-time Innovation Team Leader reviews all recent idea postings, filtering for the clearly articulated and germane to business goals and strategy. Try to avoid the infamous Kickstarter Potato Salad campaign unless that is your business. Once approved, similar to being listed on Kickstarter (or the NYSE), the idea is ‘Open for Investment’.
    1. A word of caution – don’t over filter or be too linear. Innovation is a process and, like a sales funnel, the top of the innovation funnel has to be constantly fed to produce the best results at the bottom.

Allocating ‘Innovation Bucks’ to an idea

  1. Like any other source of investing, well articulated, and promising ideas attract more capital than the fuzzy. Investors endorse concepts by allocating Innovation Bucks, and ff they decide to become an Active Investor in an idea, they have to improve the concept with written refinements.
  2. To ensure continuous feedback, previous investors can reduce or claw-back their previous investment if an idea seems headed in a direction they do not like. Thus, like an actual  market, feedback is dynamic and continuous.
  3. Investment ready ideas have a shelf life of 30 days, after which the Innovation Team Leader ranks them by size of investment and the number of comments/refinements, indicating community buy-in and enthusiasm. Said ideas go before a bi-monthly  Innovation Review Committee  for a go-ahead on further exploration, and from this point on, stage-gates are appropriate.

Payback

  1. Inventor’s earn ‘dividends’ as their idea passes through the  evaluation and implementation gates:
    1. 10% for submitting an idea accepted for listing on Innovation-Starter for potential investment by the employee community
    2. 15% when selected for review by the Innovation Review Committee
    3. 25% when it goes to business case development
    4. 50% when it goes to Development for realization
  2. Active Investors receive 50% of this schedule, and Passive Investors earn 30%
  3. At the end of every year, Inventors and Investors who have achieved a minimum 50% overall ROI on their portfolio are invited to a by-invitation dinner with Senior Leadership. Originators of ideas which truly moved the needle should have a cash/options reward as well.

Don’t sweat the tech; sweat the nuances

Innovation platform vendors are numerous these days, often very similar,  so don’t sweat the platform, either SaaS or behind your firewall.  The key success criteria, in our experience, are using the largest population possible, anonymity so it doesn’t become a friends/like me fest, moderated ideas open to investment so it does not become the Dept of Trivial Thoughts, and swing for the fences, go large or go home, right from the start. Few things are sadder than an innovation initiative nursing really small ideas, none of which will move the revenue needle.

What if I don’t get sufficient standout ideas?

OK, sometimes we set up great processes only to have too few worthwhile ideas brought forward.  Why? There’s no clear answer but a few introspective questions need be asked:

  1. When should we use an open outside community such as gathered by TopCoder (and others) vs. focusing on internal idea sourcing? Should we use both?
  2. Is our culture rewarding or penalizing of ideas which seem great but do not materialize per expectations?
  3. Have we created a reward system for innovations which ‘ring the revenue bell’?  People act in their own best interest, and often that means taking a great idea (especially in the low cost cloud/app age) and doing it on their own.

Innovation is not a process requiring control and pacing to fit your organizational cadence and governance culture. A flexible thought harvesting process upfront will ensure the subsequent stage-gates are fed the very best raw materials. How do you turn ideas into an innovative reality? Here is our viewpoint: http://growroe.wordpress.com/2013/02/25/the-smell-of-the-skunk-is-a-good-thing-when-you-need-a-disruptive-product-to-power-growth-part-2/

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC,  http://www.growroe.com , focusing on transformation, innovation, and realization where technology is the primary means of delivery and revenue. He is one of their senior Turnaround, Transformation, Program Rescue, and New Product Development 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

Big Data Can Cost Big Money – 2 Key Tips to Avoid Overspending and Get Faster Results

Hoover Dam created Lake Mead 80 years ago, capable of storing over 8 Trillion gallons of water. The 5 years it took to build the dam was a safe bet as water hasn’t changed terribly much in the past eons and reservoirs have been around for over 5000 years. The term ‘Big Data’, per a NY Times Bits column, is from the late 1990’s and the underlying Hadoop database was only invented in 2005. It’s a far safer bet to invest heavily to keep water in a central place than it is to make your own Lake Mead of Data.

Still, the insurance industry seems to be going the Lake Mead route. All too often, a Big Data strategy is a multi-year push to shove every piece of data a company can get into an uber data warehouse expecting some Big Data Analytics tool will come along and reveal previously unknown relationships. Will this mass of data take on its own purpose, requiring constant alignment to your business goals, i.e. is too inwardly focused, or someone telling you in a year, “you never asked for it, so we don’t have it and quite frankly, we can’t even store it in our database?” Can you have too much data, and not enough insights? Does the past axiomatically predict the future as the predictive analytics vendors claim? Ironically, Lake Mead’s water level is falling due to unforeseen consumption and climate changes. Pouring tons of concrete does not imply continuing viability.

The NY Times had an OpEd article on 4/7, from 2 NYU professors, Gary Marcus and Ernest Davis, highlighting the potential hazards of relying too much on insights by number crunching. Not the least, and most relevant to the ‘Big Data needs the Big Warehouse’ approach, is

‘If you look 100 times for correlations between 2 variables, you risk finding, purely by chance, about 5 bogus correlations that appear statistically significant – even though there is no actual meaningful connection between the variables’

My 2 favorite examples in the piece are the extremely strong correlation, from 1998 to 2007, between increased Autism diagnoses and increased sales of organic foods. Similarly, from 2006 to 2011, the murder rate and market share of Internet Explorer both went down sharply.

Why are you being pushed into the biggest Big Data implementation? Probably because, as that gangster once said, “That’s where the money is.” It’s a combination of IT responding to Board pressure for business benefits to support budgets, and vendors in a feeding frenzy before this also becomes yesterday’s hype. Tech industry reports show BI revenues growing to over $50B by 2017. Who wouldn’t like a piece of that? Consulting companies will tell you it’s hard, and takes over a year, if not years. If you implement Big Data the usual way, it is hard, there aren’t enough Data Scientists to make sense of all the information in the universe, tools with sex appeal, but without insurance content, appear every day via email announcements, and budgets are exceeded with little to show for it.

Most of today’s Big Data oriented Data Warehouses, and especially the underlying infrastructures, aren’t going to handle the Internet of Everything exceptionally well, or at all, which will become apparent when telematics driven usage based pricing becomes standard in just a few years, rather than today’s 2% market share. Most companies are just starting to think through the Big Data implications of an Internet of Everything based insurance industry, where Google states their autonomous vehicle generates about 1 GB of data for every second of driven time. Many newer cars generate approximately 100 MB of data per driven second. Take away irrelevant elements such as tire pressure, RPM, etc, and even of you cut it by 85%, the volume, when multiplied by just the 250M cars currently registered in the US, is staggering.

Before you build your own Lake Mead of Data, short-term, widely deployed, business function specific BI solutions may be more useful right now until the collective technology, automotive, wireless data and insurance industries think through implementation and operational realities. Here is an analogy – I live near a congested and dangerous State highway, concrete poured in the 1930’s, designed, and implemented without extrapolating to today’s volumes. With development on both sides of the highway, it cannot be adapted to current, let alone projected, volumes. We learned to live sluggishly and to hold our breath when we approach an entrance.

Here are 2 tips based on our experiences:

1 – Be audacious, think of Big Data as part of a Product Roadmap – start with today and think stages.

Blow right by “enhancements” or ‘’incremental” improvements. As Ray Kurzweil said, “take 30 linear steps and you end up 30 paces away, but if you think exponentially, you wind up a billion steps away.” Think the uncomfortable:

“If I gave a really smart 20 year old $10K, how would they affect my customer acquisition and retention process? What benefit justifies my Big Data spend if this college sophomore can disrupt me after dinner?”

Many Health insurers, for example, are in the early stages of revolutionizing their business through deeply integrated social apps, tying wearables to doctors to hospitals to patients to pricing.

Big Data will change insurance products from static entities into a more dynamic world where increased data and analytical capabilities will shorten product lifecycles to a year. Just as tech vendors think of their offerings over time via a phased Product Roadmap, insurers need to do likewise where Big Data is simply an ingredient, which in itself, will change over time.

2 – Don’t serve up comfort food.

That 20 year old isn’t thinking “today,” let alone “yesterday”; they’re too busy creating your demise. Big Data can be mental comfort food if not managed properly – it’s always reassuring to revisit the past. Again, think the uncomfortable by shifting from product focused to ethnography:

How will customers use my product in their daily lives? How will new data sources and types define these new products? In 10 years or sooner, will we continue to be an insurance company with a Digital presence, or will we evolve into a tech-focused company, one of whose main revenue sources is insurance? Will pouring all this Big Data concrete today contribute to, or impede, future agility?

Big Data does not axiomatically require Big Money upfront – it needs Big Innovative Thought. “Talk is cheap, show me the code,” Linus Torvalds (the developer of Linux) said. “Data is everywhere, show me the future” is what we should be demanding.

 

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

4 Non-Obvious Concerns When Buying Software From Unknown But Intriguing Vendors

Cloud and licensed software are both flush with vendors. BI, for example, is now in Enterprise-wide roll-out phase, but which BI vendor is your go-forward choice?  There are at least 24 tracked vendors in this space, and who knows how many are still under the radar.  The usual and established vendors have strong offerings, but some of the Most Unexceptional products and Cloud based services come from the new and the ‘up and comers’.  How do you buy from these non-obvious but intriguing vendors? If you’re the vendor, what is going through your prospect’s mind, and how can we reach win-win and close the sale?

Vendors go through maturity levels – some are figuring out how to transit to a win-win business model, others are learning mainstream business culture norms.  Some are technological visionaries but inexperienced at supporting end-user buyers over the contract term.  It boils down to one extremely personal question the shopper should ask – “what would happen if I choose a non-obvious vendor and it doesn’t go well?”  Each organization is different, some embracing fast-fails, while others emulate North Korea, and so the answer depends on both you and your employer’s risk tolerance. Sellers need to put themselves in the customer’s mind, ensuring personal risks are either allayed or avoided. If not, the sales cycle will be intolerably frustrating and elongated.

Here’s what matters, based on our experience, selecting, partnering and implementing:

1 – Is the product built as a product or is it a reuse of an internal tool or application?

Products are parameter driven and need to be more than Minimal Viable’ (especially cloud based offerings) and have a shareable roadmap.  They are architected for broader use, straightforward integration with other products/feeds and adaptable/extendable with backwards compatibility or Most Unexceptional case, backwards-invisibility (you don’t even know it was updated).  Internal applications are not as flexible and usually are built to be frozen for 10 years with little or no updating.   Check if this intended purchase was designed and built as a product, or was declared a product with little more than branding and a long roadmap of critical fixes and changes added.  The vendor’s CEO knows, talk to them, one on one.

2 – Is their business model a win-win? Do they understand the current business culture? Do they know it to a fault?

We increasingly are seeing vendors built for a near-term acquisition, not built to be a company lasting even the 3-5 years of today’s normal B2B technology contract term.  They’ll do whatever short term tactic is needed to get there.  Give Facebook credit, they’re a real company figuring out new business aspects so they can be around for years. Many vendors aren’t that strong or even care. The ‘tell’ is having an impressive New Customer list, but being thin in each account, usually the original purchaser and perhaps an add-on or two. We call these ‘orphan vendors’, and we kill them off during our Vendor Rationalization engagements, so you’re stuck holding the bag for a regretful purchase decision. Dumb Money investors love long new name account lists, so a lot of companies are forced (or decide) to go this short-term route.  Therefore, when you check references, ask for ALL the users in an account, not just their primary contact.

What is their distribution strategy: call-in centers, partners, resellers? Does the underlying supporting business culture mesh well with yours? Are they selling primarily on price? Some vendors rely on referral partners, essentially someone who hands them a warm lead and then steps out of the way.  This is a powerful new lead generation system, but who will be there next to you, shoulder to shoulder making sure you’re successful? Not the referral partner who has already made their 1X cash hit, or an implementation partner who wasn’t part of the original scoping activities. Build service level KPIs into your agreements with all parties.

3 – Post Sales Support – who will hold your hand while you attain mastery?

Implementation services are much less profitable and harder to scale than software, and so many vendors shy away from implementations, using local partners. This is actually a positive for the buyer as a poorly designed product might require the vendor’s deeper understanding of the unique architecture and resulting idiosyncrasies than most resellers/partners are willing to invest in learning given the potential market opportunity.  This could be an indicator of a product issue needing further pre-sale investigation.  Make sure you have full knowledge and application IP transfer for strong long-term self- sufficiency.

4 – What happens to the vendor’s employees if your implementation doesn’t go so well? Is it only my job at stake?

Having lived in Silicon Valley, and having been involved in growing or turning around vendors, I’ve seen what I call the ‘3 time zone phenomenon’ in action. HQ staff can move on to another HQ, monetizing their experience at a failed vendor, as long as their own hands are relatively clean of the main issue which sank the vendor they’re leaving. Or, if they were early-in and the vendor can be sold, they focus on slathering ‘lipstick on the pig’ to increase valuations, and then cash in big time.  You, the product end-user purchaser, are left explaining a regretful decision.

As a buyer, adjust your payments accordingly. As a vendor senior manager, you have to convince end-user buyers through tangible assets you’re a low risk option, such as through well thought through training, implementation plans and wrap-around services provided either directly or through resellers and partners with long-term financial incentives.

Non-obvious vendors can provide new and outstanding solutions, at cost effective pricing, and should be seriously considered. Often, they have the breakthrough solutions allowing you to innovate, providing more than a ‘me-too’ catch-up capability.  Just appreciate their point of view – despite what they may say, are they transactional or relationship oriented, and how does this square up to your personal comfort zone?

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

Here’s a Timeline to Tell if Your Sales Force is Major League

[polldaddy poll=7867363]Is your sales salary expense exceeding $189M this year? If you’re the Yankees, the corresponding response is [yawn], “yes”.  They will be paying the MLB luxury tax this year, as they do every year, for exceeding the League’s Salary Cap.  To the Yankees fan in the stands, if you buy one of the forecasted 2 million hotdogs expected to be sold in 2014 at the stadium near the parking lot covering the House that Ruth Built, recovering that $25+M luxury tax bill could make those dirty water dogs a bit expensive.  Even with free sauerkraut.

Maybe you are more like the Houston Astros, whose payroll is about 10% of NY’s?  They play the same game, have the same need to compete and win, but with less cash and therefore a different kind of player. Software, B2B Cloud, and consulting companies all have the same dynamics with their player rosters, the sales teams.

I tried Googling various combinations of Tech sales rep failure, sales rep success, sales rep optimal shoe size, etc., and while you would think the information in this blog post is sort of common knowledge, Google has yet to find and index it.

Sales Talent – Who goes where?

If you’re a Tier 1 with growing sales, you get the all-star, well connected, home run hitters who then stays for years building deep relationships at key accounts and making all-star money. Once key account sales revenues start dropping due to saturation, the economy, or a technology pivot, even Tier 1 reps have to sell harder to keep their earnings steady.  Those reps not making their numbers find their territories sliced and diced, making it even harder to keep their jobs. Ever been negotiating with an embattled Tier 1 Enterprise Software rep?  You want an Observer from the International Red Cross in the room to ensure no war crime is committed. Ever been in a late-stage meeting with a Sales VP or CRO who’s under pressure? I’d rather swim in a rip-current. When they leave, some will stay in Tier 1, and others will temporarily go to Tier 2 and 3 until they can come back to Tier 1.

For Tier 2 and 3 tech companies, either those happily up and coming or those not so happily plateaued, hiring and managing a sales team is not easy.  Top talent won’t automatically come to you, except during a Great Recession when one of those former Tier 1 reps needs a quick place to land and decides you’re going to fund their ongoing job search while burning through your 6 months of non-recoverable draw.

I recently spoke about the state of sales rep hiring and management with several industry friends, including Jeff Hoffman, a seasoned Sales VP at both Tier 1 and Tier 2 vendors and another contact, a highly successful Tier 2 sales rep.  Filtered through our firm’s lens, here’s a consensus reality.

Who do you hire if you’re not yet a Tier 1?

There’s a type of rep who likes the challenge of Tiers 2 and 3, and dislikes the politics and complications often found in Tier 1’s.  Self-reliant and resilient, they are the equivalent of the Houston Astros’ starting player who will play well in the Majors, but not at the $230M superstar level (then again, the Yankees spent a boat-load of cash in 2013 and ….).

What’s the successful Tier 2 and 3 hiring profile?

Tip-offs sales rep and Sales Leadership candidates are serious about selling your products (and not just looking for a paycheck)

  • After the 1st interview, they turn the tables and interview you, demanding a demo of the product they will be selling. Only a desperate sales rep candidate determines if a product is saleable after they’re hired
  • Sales VP’s, and Sales Team leaders will ask to interview their direct reports and will ensure they have the authority to replace incumbents they feel are not ‘winners’. They won’t take the fall for their predecessor’s hiring mistakes and won’t spend a nanosecond prodding an incumbent sales rep to get out there and do sales calls

Hunter (Territory Sales Rep)

  • 7 to 10 years proven sales performance in a Tier 2 or Tier 3 vendor
  • Communicates to Marketing exactly what is needed to fill or unblock their Sales Funnel
  • Has sales skills, not necessarily vertical industry knowledge; listens, seeks each prospect’s needs and motives
  • The products they sold were often  me-too, but they still sold them day after day, and this is a plus

Harvester (Account Manager)

  • 10 to 15 years’ experience with deep and leverageable relationships in a large customer you’d like to have. Quiz them on how that customer buys, how to become a certified vendor, how procurement operates and how they personally grew the user base and revenues
  • Did they carry the revenue number or was it shared by a larger team?
    • Be careful – many Tier 1 Account Managers are amazed, when after leaving their Tier 1 vendor jobs, their former customers forget their names. It wasn’t them; it was the logo on their business card imparting credibility and access
  • Probably has some vertical industry experience (ex: Insurance, Healthcare/Hospitals, Pharma, Specific Manufacturing, Online Banking and Digital Payments) and can have a conversation at the customer’s Director and Senior Team levels.

Consulting is a bit different, where the need to be conversant about an industry or technology is crucial and so 20+ years’ experience in a vertical or technology is often a requirement. Here, I would also review their writing skills.

At all levels, make sure they are very social media prospecting proficient, such as advanced LinkedIn skills. It’s a numbers game, and your Customer Acquisition Costs have to be controlled.

 

Managing the new Sales Rep – The Timeline

How do you know you hired a winner?  We use the following 9 month timeline with our clients and when they have a new sales team:

First 30 Days – Are they still looking for a job? Is there potential here?

  • Understands your comp plan the way you understand your calculations and earning targets, and have computed the number of closed deals required to make quota.
  • Espouses a C-Level version of your value proposition (a 1-2 minute version of your Elevator Pitch)
  • Verbalizes a high-level map between your Value Proposition and your specific offerings, stated in Day-In-The-Life terms
  • Reaches out and tells their contacts and former customers where they landed. Be cautious of reps who claim “their contacts are busy, or they’ll get back in touch” as they’re most likely buying time while still looking. This is especially true of reps formerly out of work for a year or more.
  • Demonstrates a predilection for action vs planning and advising
    • Involuntarily retooled Sales VP’s are prone to staying in their comfort zone, staying busy helping on special projects, rather than focusing on sales activities.
    • Asking a lot of questions is not the same as high activity levels
    • Avoids being a 1-person Sales and Marketing machine.  Flexible, but does not spend days putting together intricate presentations unless they are specific deal related
    • Shows resiliency; can they get knocked down or hit a speed bump and rapidly recover?

Next 60 Days – Are their skills as good as represented and are they trying to make traction happen?

  • Conducts 2 demos or deep-dive conversations conducted in cooperation with your sales support teams (might be a BA, or an Engineer who is adept on their feet and customer empathetic) to the right person based on sales cycle stage
  • Conducts a next set of 4 demos or deep-dive conversations, both follow-on and new prospect, proving they are in the marketplace and can control a sales cycle.
  • Works to attain a deeper understanding of how the customer uses your offering, actively refining their own version of the Value Proposition, now down to the Manager Level (from the C-Level we talked about above)
  • Participates in your Objection Clinic using their current prospecting and early-stage sales campaigns as input

Next 90 Days – Are they on the path to success? Are they settling in for the long haul?

  • Recites a refined customer-specific version of your Value Proposition and product map in their sleep.
  • Delivers 8-10, 30 minute Level 1 demos or equivalent conversations
  • Orchestrates 3-4 Level 2 demos with a well-defined customer need you can potentially solve, budget, timing, buying cycle and Procurement processes.
    • These can be forecasted as 30 percenters for tracking purposes.
    • Has at least 2-3 qualified opportunities where the deal terms and any deeper technical issues are being discussed, and you have personally talked to each buyer/decision maker.  Be careful of sales campaigns that drag on without your complete first hand understanding of why.
      • Reps, at this point, can forecast Phantom Deals (more wishing than having) to show activity. It’s hard to attend a sales forecasting meeting and not put something on the list at 6 months, so the pressure is on to say something, anything.
      • These 30% forecasted deals should have discovery, fit, pricing and evaluation completed within the next 30 days. Once completed, they can be forecasted at 50%.
      • Many sales reps get 6 months of recoverable draw to cover start-up cash flow needs, so near the 6-month mark, look for a sudden drop in new prospecting or deals being postponed or slowing. It usually means they’re close to leaving.

Next 90 Days – Thumbs up or thumbs down?

  • Creates at least 1 deal, closeable within your  fiscal year, and where you and their Legal are actively involved in direct customer conversations
    • This deal should be forecasted at 70%
    • This is the point where a panicky rep will start forecasting Zombie Deals, i.e. keeping deals on your forecast even though the rep knows the deal is either dead or postponed to the next fiscal year. I always ask the most senior buying executive what would happen to them if they did not buy within my fiscal year
  • If there isn’t a near-in deal, question why a rep would hang around if they seemingly cannot make a lot of money. Good reps are like cats – you rent their loyalty by feeding them

The Final 90 Days – Are they Hall of Famers?

  • Has a deeper understanding of your optimal Deal Size based on the bottom line financials and ensures all forecasted deals are within that optimal band
  • Understands and communicates to Sales Management and Marketing where their lost deals fell apart and helps devise fixes.

As Moneyball proved, you don’t need a whopping payroll to be a contending team. Hire a solid team, be realistic about production, and lead them effectively in your vision of how Most Unexceptional to play your game.

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

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