CIOs & Competitive Advantage

The absolute central “mission critical” task for today’s CIOs is that of providing enduring Competitive Advantage for their companies. Making sure the ERP system works or the Accounts Payable system or the Payroll system or, heaven forbid, the email system works with tolerable reliability … none of these count, and they haven’t counted much for several decades. Yes, they all must work but they are all “routine” in nature and offer few opportunities for competitive differentiation.

Using technology – in all its forms – to enhance the customer experience by easier ordering, faster delivery, guaranteed availability, etc. – has been the name of the game since American Airline’s SABRE system in the 1970s through Schwab’s industry-changing, internet-based brokerage system in the 1990s right up to now with Kroger’s guaranteed super-fast check-out times in all of its stores.

The roles of CIOs who “get it” has not changed since Day One. It has, for almost sixty years, been cast in concrete as “Delivering Competitive Advantage” as discovered by Max Hopper at American Airlines (lates 1970s) or Dawn Lepore at Charles Schwab (mid 1990s) or Carl Wilson at Marriott (~2005) or Filippo Passerini at P&G (2012) or Chris Hjelm at Kroger (2013) or Patty Morrison at Cardinal Health (2014) or Rebecca Rhoads at Raytheon (2015).

(1) Announcing the winner of the 2015 Fisher-Hopper Prize, (2) Status of my long-projected book

Friends –

Two things of some importance:

  • FIRST – As the chair of the Candidate Selection Committee and as the counter of the votes from the fourteen Renaissance CIOs, I am pleased to announce the winner of the 2015 FISHER-HOPPER PRIZE FOR LIFETIME ACHIEVEMENT IN CIO LEADERSHIP.  The winner is Rebecca Rhoads, the CIO of Raytheon.  The prize will be presented as the concluding part of an all day invitation-only event to be held at UC-Berkeley on Thursday, Sept. 17, 2015.  For full details, please visit the event website at
  • SECOND – My long-projected book, “Becoming a Renaissance CIO: Leadership Skills for Successful Innovation in the Digital Age”, has been completed (242 pages, 54,247 words) and is being considered by a potential publisher.  I estimate that well over thirty “Top Tier” CIOs and globally respected IT gurus actively helped me with this – and to them I owe a huge vote of thanks.  If all goes well, hard copies might become available by late October.

I hope you all had an enjoyable 4th of July.


Thoughts at Mid-decade

The year begins. It was a cold night. The wind machines were whirling in our orange grove and water was flowing into the grove from our best well – to keep the ground temperature above freezing

Our three dogs showed little interest in their morning outing … the pillows of our bed were far warmer.

May this year be one of mutual trust between people, peoples, and nations. May those of us who labor in “IT” have a good year of creativity, of innovation, and of new systems that don’t crash and corrupt.

May all your data be true and all your decisions be wise.


Seventy-seven today!

Today is my 77th birthday. I’m at our ranch with my wife of 47 years, three dogs, two horses, and a “To Do” list that is endless. Dinner last night was my wife’s lovely homemade lasagna … with leftovers (ALWAYS better the 2nd day) tonight. Just a few minutes ago I started bringing down the Christmas decorations boxes from their 2nd floor storage area … and the tree is on our front porch waiting for me to put it in its base.

I’m in good health and living in a gorgeous place … not an “elegant” home but a gorgeous place … with a direct and clear view of the snow (yes, there really is some) covered Sierra Nevada Mountains from our bedroom.

My long discussed book is, after many fits and starts, progressing well, with the hopefully last chapter now about half done. When I complete the “first writing” my plan is to read the whole thing aloud to myself … from start to finish to catch stupidities, duplications, less than felicitous wording, and very, very long (and thus totally incomprehensible) sentences (a bad habit of mine).

I will work at my desk for the next hour or so and then start on the Christmas Tree. Before dinner, I will build a nice fire in our fireplace, pour some nice wine (maybe some nice Mumm’s Champagne in honor of my birthday) and plunk myself down with a good book – specifically “Abraham Lincoln” by Lord Charnwood, a book described in early 2014 by the WSJ as perhaps the best ever biography of Lincoln, a judgement that I, having now read about 2/3rds of the book, strongly agree with.

My best wishes to you all for a long, healthy, and happy life. Also … Merry Christmas, Happy Hanukkah, and Happy New Year!


Document Retention

Beverly Thompson, one of the most up-to-date members of SCC Sequoia’s Core Team, sent me the following on Nov 13th. I think my readers might find it helpful.

DOCUMENT RETENTION (Beverly Thompson, 11/13/14)

The subjects of document retention and its cousin document management are two of the least sexy ones in the realm of IT. In my experience, in companies from start-up size to billion dollar enterprises, the discussion of document management causes eyes to glaze over and attention spans to wander. Then the legal team of Dewey, Cheatem, and Howe shows up with a subpoena. Or the SEC. Or the IRS. Or it could be as “simple” as a pricing discrepancy on a significant customer’s order and email conversations ensue on who promised what to whom and when. The scramble to gather documents and emails, the proverbial paper trail, begins. And at what cost? How much does it cost your company in terms of man-power and loss of production to gather everything that is needed to handle the issue at hand?

In my career, I have worked in the functional areas of accounting and finance, order to cash, procure to pay, manufacturing operations and logistics, quality control, and IT. I have survived audits by MITI (Japan’s Ministry of International Trade and Industry), restraint of trade lawsuits, sales tax audits, multiple mergers, acquisitions, and spin-offs, and the list goes on. In short, I have personally spent 100’s of hours reconstructing paper trails and gathering data/documents for these unexpected situations. If proper document management and retention policies had been in place, I bet I could have saved more than 50% of those hours just hunting down the information. Multiply my hours by all the others involved in those situations and you can see the true cost of not having a system and process in place.

As a firm believer in “begin as you mean to go on”, setting a document retention and management policy in the early days of a company’s existence helps meld it into the corporate culture. It is not red tape; it is sound business practice. Document management systems are relatively inexpensive these days and a few bucks invested now can save you thousands of dollars later. Implementing this type of system, policy and practice in a larger company will require change management and training but will be well worth the effort in the long term.
Document retention policies need to cover hard copy documents, email, electronic documents, and electronic data. In other words, it should include every method of written communication (and this includes the data needed to generate that communication in the form of reports, invoices, checks, etc.). These document types can be segmented by type of content, use, or a combination. Retention length may be determined by the document type. Some retention lengths are dictated by regulatory agencies like the IRS, SEC, FDA, etc. Other documents, such as email, are harder to classify because of the myriad subjects and content associated with email. Draft documents may not be kept at all. It is imperative that the policy covers all document types however and that the policy be carried out in a consistent manner.

The policy also needs to cover what to do in the event of a government investigation or when some threatened litigation is discovered. The company’s legal counsel or audit firm may instruct the company to cease the destruction of any documents that may be pertinent to the situation. There needs to be processes in place to communicate the situation to involved parties so that potentially required documents are properly saved and are “findable”.

In short, document management and good retention policies may not be the most fun topics but having them will save you time, frustration, and money in the long term.

Never Look at ROI!

I received the following a few weeks ago from Mark Tonnesen (ex CIO of McAfee and of Electronic Arts) and want to share it with you …

Why I Never Look at the Value Case or ROI
By Mark Tonnesen

When evaluating potential IT initiatives, the most common approach is to focus on the numbers and look at the return on investment (ROI) or value case. For example, say your company is considering implementing a new Enterprise Resource Planning (ERP) system. Chances are the CEO and CFO will ask, “What’s the value?” Or, “If the new system will cost $10 million, can you show me how it will produce a $10 million ROI?”

As far as I’m concerned, though, if you’re asking about the value case or ROI when evaluating IT initiatives, you’re asking the wrong question and looking at the wrong things.

What You Should Be Asking When Evaluating IT Initiatives
What gets lost in the value case or ROI approach to evaluating IT initiatives are the bigger questions that are more important than the finance-drive calculations:
• What problem(s) are we trying to solve?
• Is there an objective/end state that we’re trying to achieve when we’re done with this initiative that we don’t have today?
• Is this the best way to solve that problem or achieve that objective?
• What is the value to the business of solving that problem? How important is solving this problem or achieving this objective for the business’ ability to reach its goals?
• How will this help us make better decisions and run our business more efficiently?

Everything Cannot be Measured
Another problem with the ROI or value case approach is that you might be trying to quantify the unquantifiable. For example, say you’re considering implementing wireless internet service throughout your office for $XX per month. How do you calculate the ROI on this? You can take a best guess at how this might improve productivity and come up with a number. But that would just be a guess – and it would ignore other factors, such as the positive impact this might have on employee satisfaction and the potential negative effect on productivity of making it easier for employees to waste work hours on their personal activities online.

Liars Use Numbers and Numbers Lie
Your best guess regarding the ROI of a proposed IT initiative is just that – a guess. For example, I once worked at a large high-tech company that was big on ROI. We did a series of technical support initiatives that involved investing in tools that would become self-service tools for customers. To justify these projects we would put together graphs showing a reduction in customer support cases and calls, and an increase in customer satisfaction.

Knowing what the cost of a support issue was, we put together numbers that showed that the cost of each initiative was lower than the cost savings it would deliver – and our projects were approved. Unfortunately, the projected savings never materialized. We didn’t include other factors such as growth, customer adoption, issue severity, continuous improvement costs and operational support costs for the tools. So although the percentage of customers with support cases went down, the actual number of support cases and calls did not.

When evaluating IT initiatives, I recommend steering clear of the value case and ROI approach. Rather than pulling numbers out of the air to justify (or kill!) a program, take a hard look at the business impact that the initiative will have. Ensure you are solving the right problem and include measurement points along the way to check whether the expected goals are being achieved.

Do IT projects really fail all that often?

The Standish Group and others publish scary statistics showing very high failure rates for IT projects – with these at considerable variance with my 50+ years of IT experience. The problem seems to be the definition of “failure” and the definition of “project” with both being far too broad by the scary statistic folks. For a real project, that is one with a careful definition, an engaged sponsor, and a plan and a budget … along with “success” being defined as “the customer liked what he/she got” … my experience suggests a success rate of 60% or above. For some CIOs, I’d guesstimate a success rate of 85% or higher.

If you define as a “project” something without a plan, budget,or sponsor, you will have a Self-Fulfilling-Prophesy of frequent failure. So, my advise to those who read those scary statistics is … to avoid following in those footsteps, don’t step into them at the get-go. Instead, work your tail off at the start … supper careful definition and scope that everyone understands and agrees to, an engaged and highly visible sponsor, a realistically achievable plan and budget, a user+IT team comprised of the best darn folks you can get your hands on. Given these, you will succeed; without these you will fail … and just add to those scary statistics.

Yes, I’m cheating. I’ve defined a project with perimeters that insure success. Is that wrong or unfair? Aren’t we all supposed to succeed when we start something? Including as “projects” things that are doomed from the get-go just seems dumb …