When you introduce a new service should you do anything different than you do when you just upgrade something?  If the new service is good for the users, but they push back, how do you make progress?

Let’s take the evolution of email over the past 25+ years as an example of the maturation of a service and increasing expectations.  This may seem like a history lesson for those who never new that mobile phones use to mean that you had a 25 foot chord that you could stretch into another room or that the only video game used to be just an electronic ping pong game and social networking meant going to a dance and watching the guys stand on one side talking about tough guy stuff while the girls stood on the other side and wondered why the guys weren’t asking them to dance.  However, history lessons are good because patterns exist and they repeat.  Learning to find the patterns from the past and applying them to the present is a talent that you should develop in either yourself or your staff. 

Email started as a technology for the ‘computer people’--an application that few in the rest of the company wanted to use.  It was part of the system that you already had up and running for the ‘other stuff’ that justified the purchase of the computers.  Seemed like a cool ‘gadget’ that they could do without.  If people needed to communicate they would walk over and talk to the person or pick up the phone.   Besides that, most people didn’t have typing lessons and it took longer to type a simple message than any other form of communication.  So where was the value?  It seems easy to understand the value now, but answering that question back then and helping people get started wasn’t easy.  Here are the specific objections we were confronted with:  Email was new.  It didn’t show hard dollar savings.  It seemed to add cost.  It added steps to the way people functioned.  It was impersonal.  It was complicated.  Do these seem familiar?

So, back then, it didn’t matter if email was down once a day for a few hours.   We could take it down whenever we (IT) wanted because no one had integrated email into how they got work done.  

So how did email take off?  Demonstrated Process Efficiency!   We took the inner-office memo process and reduced the number of steps and time and people it took to deliver a memo across the company.   A ‘memo’ was something created by a manager.  They would write it by hand or record it on a tape recorder or dictate the memo to a secretary (where the secretary came and sat down in the office and wrote down what the manager said in an old cryptic language called ‘shorthand’).  The memo was then typed up.  Then copies were made and put into inner-office envelopes.  The recipient’s names were written on the outside of the inner-office envelopes.  The envelopes were then picked up from the secretary’s desk by a mail clerk who then sorted and delivered to the various recipients.  (Often, someone wouldn’t receive the ‘memo’.  Yes, that was a common occurrence and not just a joke!)

So showing how you can eliminate all the copying, stuffing, sorting and delivering while including a new benefit that you can validate who received the memo was a true demonstration of value.  We took a major memo creating department (not the biggest, but substantial) and started them on email.  Once they started talking to their peers in other departments, the demand grew rapidly for all the departments to be brought on to email. 

Then email began to take off as an internal communication tool and then it expanded to people outside of the company.   But that comparison took the “IT” person to thoroughly understand the business process and the value that existing process provided.  Then be able to see which steps of the existing process was not adding true value—those that could be replaced by technology and the benefit to the business was realized through reduced cost and improved efficiency.  BOTH were important in order to introduce a new technology!

Email did have some competition—the facsimile machine!  (It was a copier like machine that sent a copy of a document to another fax machine across a phone line).  Yes,’ faxing’ still seemed to be a preferred tool over email for many people. Especially from the vendors that were selling all the fax machines.   Sounds crazy but it was used as an alternative to email.  And it is still in use today by many pharmacies and doctors and attorneys.  Interesting!

It was primarily the secretaries (who did most of the manual work) that really understood that it was faster for them to email to many than it was to fax to many.  However, if a secretary was concerned about their job, they were slow to adapt for fear they wouldn’t have a job after the conversion.  Email utilization continued to grow and the reliability requirements increased as people relied more and more on that ‘service’ to get their work done.  The expectation became like ‘the phone’ where dial tone just seemed to always be there.   Hence today’s expectation:  Email should never be down!!

And now, email as we know it could be on the downtrend of its lifecycle.  Sounds crazy but as I write this you have college kids that spend more time texting and tweeting than they do on email.  They email to the ‘group’ that doesn’t text or tweet—their professors, their parents and future employers.    Sounds like how ‘faxing’ is still around. 

Although that transformation occurred over a number of years, today that same ‘process’ of introducing technology must go through the same steps, but the timeline can be (and often is) over a matter of weeks and months.  I call this out because in the world of fast evolution, although you are pressured for speed, you must go thru the same steps—you just need to reduce the cycle time.

So let’s walk thru the steps from the email history lesson and extract the steps of introducing a new service:

1.    Identification of the new technology (Email…)
2.    Proof of concept (POC) - IT validation to understand how it works, rough order of magnitude on the potential user base, the costs involved to deploy and support

Understand the alternative ways to deliver the service and there value (facsimile machine)

b.    Filter through the vendor hype.  Understand the strength of support from the vendor.
c.    Compare to the industry, where is it already in use?  Check references. 
d.    SEE IT IN PRODUCTION somewhere else (unless you are a cutting edge environment that likes to take risks and OK being the first to use something—basically a learning center for the vendor)
e.    Are there already ways to get the work done or receive the business benefit you have identified?  You may discover that you have another application/service that may be used in a manner you didn’t think of—getting better utilization of an existing asset.
f.     Seek for the business value and be able to understand what changes to the business will occur (positive or negative)
g.    How much customization is required?  Can you use a standard configuration?  Big warning on new technology—if you have to customize too much you may be susceptible to turning a simple opportunity into a complex project with high risk that may never get off the ground.  We call that building a ‘concrete airplane’-  Very strong but may never get off the runway.

IF POC is successful continue, otherwise back to step 1

3.    Validation of business value (hard dollar… increase of revenue, reduction of cost, increase in efficiency—the memo example)

IF Validation is successful continue, otherwise back to step 1

4.    Pilot to validate the business value assumptions and deployment plans

a.    While this is happening, the awareness of what is going on must be communicated to all appropriate future users.  Begin the user buy-in process early.
b.    Build your deployment plan, cost and timing estimates.  Work to build in a phased roll out to limit business impact and reduce potential risk.  Automate as much of the deployment as possible.  Use this to deploy the pilot.
c.    Validate vendor support structure
d.    Validate your training/adaptation assumptions.  How easy is it for users to adapt?
e.    Hold tight to the scope and benefits.  Avoid making changes that will take longer to deploy—add those changes in to a phase 2 deployment.  Go after that 70-80% of the business value rather than pushing higher. 
f.     Business groups/users that will use the service must be part of the analysis of the results in this phase. 
g.    Avoid being so emotionally attached to the service at this juncture that you can’t walk away. 
h.    Push for the true validation of the benefit identified.  Be a business man that has to write checks out of your own checkbook—if the benefit isn’t there, kill it now!!  Don’t continue and reach for more soft savings that ‘may’ occur—we call that putting lipstick on a pig.  (Not that a pig isn’t a good thing—just have to know when you want a pig and when you don’t)!

IF Pilot is successful continue, otherwise back to step 1

5.    Continue with deployment

a.    Automated deployments are always preferred.   Reduce as many manual steps as possible.
b.    A phased roll out is always preferred and must be part of the planning process.  At this stage you should not be trying to retrofit a phased roll out plan. 
c.    Monitor training and make appropriate adjustments as you learn.  Sometimes less training is required, so scale down
d.    Communicate progress until deployment is completed.

6.    Validate user acceptance

7.    Validate and demonstrate business objectives met

a.    Most environments do not follow through on this step.  However, this can help you learn and improve your process.  You want to get better—don’t be afraid of the results.   It will help you the sooner you find out than waiting for someone else to tell you later.

With new technology you want to keep it as simple as possible.  Target that 70-80% of the potential benefits.  Focus on getting that out ‘phase 1’ as quickly as possible while understanding your ability to provide stability and availability.   Again, communication on expectations must coincide with the maturation of the application.