The Emotion of Technology Change

I began my career in Information Technology back at Wright State University in 1974.  I didn't know anything about computers when I started, but a friend that was at WSU at the time showed me some programs and I was attracted by the logic, their math-like quality and the promise of avoiding a bunch of annoying liberal arts classes.  But little in my college experiences prepared me for how much emotions play in the technology field, either good or bad.  I've collected a few of those experiences in this article to share with you.  And if you're ever needing an ice-breaker when in the land of techies, just ask then about their most hair-raising experience.  You're sure to hear an earful and get the conversation going.  

I'll start with the worst feeling I've ever had.  I was new with a company back in 1980 and was working hard at getting something or another to work.  I was sitting at the master console of the company mainframe and realized I needed to stop any new work from starting in the system.  My brain instantly stormed two possibilities.  I could "purge the initiators" or I could "hold the queue".  Unfortunately my fingers interpreted an unfortunate combination of the two and decided to "purge the queue".  Before I thought twice my fingers had entered the requisite command and the system began to get rid of everything waiting to be run or the output of everything already complete.  When my brain figured this out a few microseconds too late, it was beyond stopping.  My stomach fell like a lead weight and my hands wanted to reach inside the console and take it back.  It was all I could to avoid vomiting on the computer room floor.  Fortunately I worked with some experienced, and nice, folks who had "been there and done that" and cut me a break.  I just wanted to hide.

On the other side of the emotional teeter-totter, one of most positively exhilarating experiences was back in the early days of the Internet.  Like most of us I  rode the modem speed curve as fast as I could.  Loved 2400 bps (bits per second), died and went to heaven when 9600 bps became reality and dreamed of the day that the promised 56,000 bps would actually work on my home PC.  The intellect could only imagine what a really high-speed connection would be like.  My time came during a trip to the IBM Raleigh North Carolina briefing center, where I stayed at the Washington Duke hotel.  I had heard they had a T-1 (1.544 megabits per second) to the Internet and couldn't wait to plug in and take off.  Yes, it was fast.  Yes, it was awesome.  But the surprising emotion was a sudden realization of the potential of the Internet.  Anything, anywhere, and in an instant.  It was as if, in my mind, the Berlin Wall had fallen that day.  I sat in my hotel room, my world changed, forever.

Some of the best emotions are deep-rooted in our past.  In 2009, one-quarter of Americans do not have a landline for telephone service and that number is increasing very day.  But I grew up with only a landline.  To date myself, when I was growing up my family had a six-digit phone number.  Crestview-3-8-3-2, which translated to 2-7-3-8-3-2 (the "C' and "r" in Crestview translating to "2-7").  And we had heavy rotary phones that rang like church bells and all the kids (five of us) would run to answer it when it rang.  And you actually had to walk over to where the phone was to use it.  Imagine that.  With that as a background we speed ahead to last year, 2009, when my wife and I, after moving from a "real landline" to a cable-provided "fake landline" the year before, decided to "cut the cord", eliminate the cordless phone and go with our cell phones and Skype.  In our heads, not a big deal.  In the emotions of our heart, a totally different deal.  A solemn call to Time-Warner.  The removal of the phones from each level of the house.  The feeling of being cut-off from the world.  Took awhile to feel whole again.  And we do miss the loud ringing on occasion.

  

Finally, I bought my first app-phone late last year, a Motorola Droid.  I've had an iPod Touch for a couple years, like the apps, but always feeling Wi-Fi needy.  I've had a love-fest with the Motorola RAZR since they first came out and have owned three.  But the Droid, again very unexpectedly, came with a stronger emotional response.  I was connected.  Always.  I could look it up.  Anywhere.  I took my stuff with me.  Anything at all.  Two email accounts, two calendars, music, videos, Twitter, Facebook, chats and messages.  Maps, alarm clock and directions, oh my!  Excited, sure, it was a dream come true.  But the unexpected emotion that swelled up was that of being overwhelmed.  Too much.  Too often.  Out of control.  Maybe some "dial tone therapy" would help. 

The Outcome-Value Statement

This article describes a concise and effective method to communicate a project, a requirement or even an organization's purpose to multiple audiences, each listening for their part of the message.  It does this by linking the work being done to the value being delivered through its expected outcome or outcomes.    

The work being done can be the list of various projects or the major components of projects.  It can a list of requirements for a new service or a new set of rules being considered.  This is the place to begin creating the Outcome-Value statement.  Simply write them down in a list with the most significant items first.  While the list could be very lengthy, it's best to summarize enough to keep its size to ten or less.  

The next step is to write down the Values you expect to gain. These fall into three categories: cost, service and risk.   It's not time yet to link the value to the work being done.  Just list the values for the entire effort.  It's okay to make these somewhat fuzzy for the purpose of this effort.  It's not intended to replace a business case analysis.  So a statement of "reduce maintenance costs" or "improve service reliability" is sufficient. 

The third step is usually the most difficult, although it comes faster as you become familiar with the process.  This involves stating or predicting one or more of the resulting Outcomes.  An Outcome is simply how are things different.  How does a business process change?  How might the people using a new service view the difference?  Perhaps a current service is being eliminated as part of this project.  The Outcomes will typically show you where your change management issues exist or where communication to affected parties will be required.  Most importantly an Outcome is not a cost, service or risk statement.  Saving a million dollars is a Value, not an Outcome.  "Reducing product recalls" is an Outcome, not a Value.  Outcomes may not be all that exciting, for example, changing a supplier that results in a million dollar savings.  It's an exciting Value, but not an exciting Outcome from your point of view.

The final step is to assign each Value to one or more Outcomes and link each work item to one or more Outcomes.  The result should clearly show what is being done, how your world will change and why it's a good thing.

Let's use implementing an email retention policy as an example.  Prior to this project people could freely keep or delete anything in their email mailbox, but new regulations and service disruptions are requiring a change.  Let's start by writing down a fictitious, but realistic, set of proposed rules. 


     - Emails older than 90 days will be automatically deleted  
     - Each user's mailbox is capped at 250 megabytes of storage
     - Email backups tapes will be erased after 30 days
     - Users can only move emails requiring longer-term storage to the content management service
     - Automatic deletions and erasures will be halted as required by legal proceedings

Step two is listing the Values expected.  

     - Reduce disk and tape storage costs (cost)  
     - Improved email system performance (service)  
     - Fewer "smoking gun" emails being kept (risk) 
     - Compliance with court orders (service) 
     - Retaining business records and knowledge (service)

Now the hardest part, the Outcomes.  Even in this made-up example it took about ten minutes to clearly state what is different.  Looking at it from the email user's viewpoint helps see the Outcomes.

     1. Email Becomes a Transitory Tool 
     2. New Processes for Retaining Emails for Legal and Business Requirements

Putting this all together and linking the new set of rules to the Outcomes, the final Outcome-Value statement is produced.  Each Value is listed as a bulleted item after its associated Outcome and after each new rule the Outcome it supports is listed in parenthesis.  

Email Retention Outcome-Value Statement

1. Email Becomes a Transitory Tool

     > Reduce disk and tape storage costs  
     > Improved email system performance 
     > Fewer "smoking gun" emails being kept

2. New Processes for Retaining Emails for Legal and Business Requirements

     > Compliance with court orders  
     > Retaining business records and knowledge

     - Emails older than 90 days will be automatically deleted (1)
     - Each user's mailbox is capped at 250 megabytes of storage (1)
     - Email backups tapes will be erased after 30 days (1)
     - Users can only move emails requiring longer-term storage to the content management service (2)
     - Automatic deletions and erasures will be halted as required by legal proceedings (2)