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

a.
   
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.
 
 
An excellent vehicle to stimulate improvement in the organization is something I call an Event Review.   The objective is to extract learning’s and your own best practices that stem from good things or bad things that have happened.  Then share those learning’s with everyone for the benefit of the organization.

The ‘Event’ could be anything:  A project, an outage, a deployment, etc. but most important is the environment or culture you establish.   You need to reinforce the benefits of the learning’s.  When it is a positive event you are reviewing, people like to be recognized-but do it live and as quickly as possible—don’t wait for an event review. 

The ‘Review’ itself should be held as soon as possible after the event has occurred.   In the case of an outage, I recommend within 48 hours as details get forgotten the longer you wait.  The key here in the timeliness is that you catch the important details that are still fresh in people’s mind.  The longer you wait, the more that is lost. 

You may find you don’t have enough time in the day to perform all the reviews you’d like so you’ll need to prioritize.  Focus on what is necessary for your organization at ‘this time’.  Adjust as you mature and as time permits.  Start slow and make each one meaningful. 

Many will be weary that your event review is a witch hunt and it may take time to build up the trust.  However, to reinforce that trust you must separate the event review from any management issues that you may need to deal with, such as people not following policy.  To get to the benefits, it will take time to build up the required trust within your staff and you must respect the process and be patient.  Focus is on ‘what’ went wrong, ‘what’ went right and ‘what’ can be done to improve or repeat the success.   The ‘what’ is important and avoid the ‘who’ during the event review--especially when you are reviewing an outage or event that had a negative impact on the business or the organization!

Participants 
Assign a facilitator to lead the sessions-generally someone from your problem management staff or management team.  Invite anyone that had direct involvement in the event.   It could include IT staff as well as non-IT staff. 

The facilitator should prepare for the session by assembling as much information as possible.  This could include the timeline, decision points, start time, end time, etc.  This will help keep the discussion on topic.

There are some people that should not be invited to the event review and that is primarily the ‘brass’ of the organization.  If you really want staff to speak up then the ‘safe environment’ should be void of senior management.  Even the best of the senior staff seem to want to chime in or over react and it will send unwanted signals to the participants.  If the objective of the senior management is to provide praise, then they should do it elsewhere—not in the event review!

There is often extreme pressure from some senior staff members that may even demand to be in attendance.  If that occurs, then you have an opportunity to clarify the objective of the event review and separate out any objectives that the senior staff member may have.  You can provide them a ‘separate’ session and review the output of the event review—work to maintain the event review for just those that were directly involved.  At the same time, respect the needs of your senior management—it’s the ‘wants’ that you need to manage.  And yes, there have been many times that I have been in that situation and almost fearing my own job by not allowing my boss to attend an event review.  And I remember a number of times being requested for a name because someone’s head had to roll.  Again, we need to separate the management issues from the event review process. 

Agenda
Begin by documenting the timeline of actions/events related to the event.   What steps were taken leading up to the event?  Was the plan followed?  What validation occurred?  Literally document all activities leading up to the event as well as during the event and the steps that closed the event.   In the case of outages, often time is spent during the restoral of service to try and re-engineer something or fix something else that delays the restoral of service.  Flush those activities out during the review.

Once you have the timeline documented, you now focus on 3 key things:  1-Do we know ‘what’ was the root cause of the outage.   2- ‘What’ can be done to prevent the outage from happening again.  3-If it does happen again, ‘what’ can be done to resolve it quicker?  

After you have documented these areas, specific action items for each area must be captured with specific timeframes and owners and a process to follow up on the action items must be in place.  If you leave the event review without action items, you will not see the improvements.  The action items must be meaningful and have a documented benefit.  It is better to have fewer quality action items that can be achieved.  Giving someone an unreasonable action item that can’t be completed will mean you’ll get a lot of bad reports on status.  Follow and close out all your action items—it will be a negative reflection on your management team if action items continue without closure.

A final item to cover in the agenda is key learnings from the event.  This is best done at the end of the session.  You should open this topic with an overall summary of the event based on the prior agenda items and then step back and open up the discussion for some observations from the group.   This dialogue is often the most beneficial as it can provide great insights into the group and what they really learned from the event.  Don’t interrupt!  Let the participants speak and engage each other—just observe and then document the summary of the key learnings!

Always stick to the agenda and keep the discussion focused at the right level.  Try and keep the session crisp and to 1 to 1 ½  hours.  Separate meetings can be used to drill down on further analysis if required or designing solutions to re-engineer something.  That activity should not be done in the event review but rather, can be assigned as an action item.

I can’t say enough about the importance of building the foundation of the event review around the ‘what’ rather than the ‘who’.  When you use this review to zero in on the ‘who done it’ you will lose the openness and candor so important for continual process improvement.   Follow up with individuals is necessary, just be careful not to use the event review process as the vehicle.  Otherwise your ‘event review’ will be perceived as a visit to the principal’s office and that means people stop talking and only tell you what they think you need to know.

Another negative factor will occur when people feel they will get in trouble if they are mentioned in the event review is that they will spend more time pointing fingers and doing what they can to ensure the finger isn’t pointed at them.  Again, another unproductive activity that brings negativity into your environment and must be replaced with a true focus on the business!

The event review is truly a powerful tool that can help you mature your organization.  To do that you must prioritize the long term benefits over the short term witch hunts!