Communicate What IT is Doing

Communicate What IT is Doing

Lack of communication can be the great punisher of IT professionals. We can include ‘not involving others’ as a variant. When looking for scapegoats, or an area to cut expense, IT is one of the easiest places to go.

When something goes wrong with IT services, a frequent question is ‘what are they doing?’

Sometimes that is the question even when nothing has gone wrong with IT services. Say that a non-IT co-worker doesn’t complete some assigned work. Blaming a technology failure is the workplace ‘the dog ate my homework’ excuse. Example: ‘I saved it but its gone.’

Technology has some inherent mystery in it. In the blame shifting game, the mystery makes IT a convenient target. The thought is ‘I guess its possible that what you did just disappeared’. And it is possible – but not likely.

The question ‘what are they doing?’ is a good and legitimate one. The challenge is how to make the question less frequent and less charged. Meeting the challenge requires communicating well both reactively and proactively. The risk in that is much less than the alternative of communicating on demand.

  1. Reactive Communication: Real-time Events
    1. Help Desk Function
    2. Help Desk Visibility
  2. Reactive Communication:  After an Event
    1. Deflection and IT Accountability
    2. Deflection Damage Control
  3. Proactive Communication
    1. Service Requests
    2. Changes
    3. Development Efforts and Agile
    4. Project Visibility

Reactive Communication: Real-time Events

Help Desk Function

What do you do when an IT service is not working right NOW.

ITIL provides guidance on handling communication well with the problem management and incident management practices.  The problem management practice covers ‘reducing the likelihood and import of incidents by identifying actual and potential causes of incidents, and managing workaround and known errors.  Incidents are defined as ‘unplanned interruption to a service or reduction in the quality of a service.  This is the help desk function, also known as the service desk.  

ITIL guidelines describe a full time service desk. The service desk is a formal point of contact for IT needs.  The service desk is responsible for shepherding active incidents to conclusion. An IT organization (or person) may not staff a full-time help desk,  An IT organization must provide what a service desk does:

  1. collect incident reports
  2. see that the incidents are addressed
  3. communicate progress
  4. confirm resolution

Recording problems, needs and requests supports incident communication.  It helps avoid an incident being lost when things get busy.  If an IT shop has more than one IT person, it can help avoid more than one person working on the same problem.  It provides visibility into what is essentially the same problem being reported by multiple people.  The incident information can be used to measure and improve responsiveness.

In organizations with multiple IT people, each IT person may collect IT service needs.  These are recorded in a help desk system. The question is, ‘what needs to be recorded?’  For the truly paranoid, recording EVERY communication seems to be about right – and impossible unless the IT group has very little interaction with the rest of the organization.

The guideline for when to record a communication into a help desk, thank you ITIL, is when a communication is about an incident.  If it is ‘an unplanned interruption to a service or a reduction in the quality of a service’, it probably qualifies to be a helpdesk entry.  If the problem was resolved in under two minutes, you can probably skip the recording it.  Questions about using Excel, turning on a printer and other low grade help usually doesn’t warrant a record.  If the resolution must be deferred beyond the initial communication, then it definitely needs to be recorded.

The source of the incident details matters.  The source are usually:

  1. Email
  2. All other (conversation, phone call, text)

If someone sends an email, you should definitely enter it into the helpdesk system.  Many helpdesk systems allow forwarding an email as a way to create a ticket.  For all other, the two minute rule applies.

Help Desk Visibility

The practice of Kanban works well for enabling affected users to see the progress of their request.  A Kanban board shows the incident reports as individual notes.  The board is divided into columns for the current incident state.  The incident note is moved to a new column as the state progresses.  Sample states ae:

  1. Received
  2. In progress.  This may be replaced with ‘Tier 1 support, Tier 2 support, etc.)
  3. On Hold
  4. Closed/Resolved.  Incidents in this state are swept over time to an archive.

The board serves the reactive communication needs when it is available for all users to view,   The board passively provides a status.  Progress notes available on the incident item can provide additional insight.  Some Kanban systems will send an email when the incident state changes.  

Some online Kanban tools are:

These are not help desk systems.  Using these tools for help desk requires some work.  Thankfully, using these tools for help desk is not a new concept and there is a body of work on how to customize them to put them to work.

For help desk systems, some options are:

Reactive Communication:  After an Event

Help desk incident notes provide a record when dealing with an after an event situation.  It enables speaking about specifics rather than a generic ‘it wasn’t working’ claim.  Addressing specific details makes communication easier.  It answers the question ‘what is IT doing’ with ‘this is what IT did’.

Deflection and IT Accountability

When someone outside IT deflects attention from what they did (or didn’t) do, the mystery inherent in technology makes it an easy if not reflexive culprit.  In the blame shifting game, common redirections are:

  1. ‘the system/network was down’
  2. ‘my computer/printer wasn’t working/ was slow’,
  3. ‘I needed help/IT to show me…’
  4. ‘IT didn’t get me….’ 

The implicit question behind all of these is ‘what were they doing that IT didn’t’:

  1. have the system/network up and running,
  2. fixed the computer/printer
  3. given help or shown how to use it
  4. provided what they were supposed to

The instance which IT professionals know too well I call the ‘unreported failure’.  The prior list of redirections are candidates for being unreported failures.  Here’s an example:

The customer service director is asked for a report on call center productivity.  On the due date, instead of a report, he tells his director/vice-president/CEO that he doesn’t have it because he couldn’t save the report to the server.  And it’s been like this for weeks.’  With that, the vice-president blows up the head of IT (at a minimum).  

The astute vice president would ask :  did you contact IT about this?  

The director will likely answer:  ‘Yes’, although more likely the answer is really ‘no’.   At most, the director may have said to the IT tech working on a printer in a neighboring office ‘I’m having some problems.  Could you help me?’   In his mind, that makes the answer a ‘yes’.

Most organization managers will consider it fair that IT be informed to be held accountable for a failure.  Many organization managers will even consider it fair that IT be informed in a useful way so that they could recognize that there is an issue.  

Had the customer service director communicated the failure to someone from IT who could have helped, the result might have been different.  Or IT would have legitimately owned the failure if they hadn’t acted effectively or at all.

Deflection is part of human nature.  Not everyone will misrepresent that they’ve communicated in a meaningful way when they haven’t.  For those that have told IT about an issue, handling the communication openly serves everyone well.

Deflection Damage Control

What to do when you’re in the damage control mode of addressing a failure attributed to IT:  ask ‘when, who and how’.  ‘When’ is ‘when did the customer service director contact IT?’.  The ‘who’ is ‘who did he contact in IT?  These two are straightforward.  The ‘how’ is ‘how did he contact IT?’  Was it an email?  Was it a call to the help desk?  Was it some words exchanged in the lunch line? 

Proactive Communication

Service Requests

What about service requests which aren’t brought about by incidents?  That’s the request for a change or something new.  ITIL provides guidelines with the Service Request management practice.  The ITIL definition is ‘supporting the agreed quality of a service by handling all pre-defined, user-initiated service request in an effective and user-friendly manner’.  The emphasis is on ‘pre-defined’ and much is devoted to a service catalog of services a user can request.  In most shops, the request is for something new. 

Both the existing and new service requests fit neatly into the help desk framework.  Just like incident requests, solid communication  about service requests minimizes possible deflection.  Unlike incident requests, service requests may remain open for some time.  If a purchase is involved, approval from outside IT may bring IT’s participation to a halt.  

Recording incidents and service requests provide an activity measure to answer the ‘what is IT doing?’ question.  The record detail makes discussions around specific incidents or requests more productive.

Changes

Changes in IT services are the wellspring of disruption.  Some changes you don’t control.  A network switch fails.  Malware takes hold on a workstation.  These events change the IT environment without advance notice.  You’re in the world of reactive communication.  

Then there are the disruptions that flow from something that IT did.  A server OS upgrade with unexpected side affects.  A router replacement.  These events are planned and probably tested in advance.  What can be said of disruptions that flow from these changes is like the Monty Python sketch about the Spanish Inquisition:  ‘nobody expects the Spanish Inquisition’.  But there they are.

Changes that IT initiates may require proactive communication.  The ITIL Change Enablement practice focuses on ensuring that risks are properly assessed, changes authorized to proceed and a change schedule is kept in order to maximize the number of successful service and products changes.  Determining the communication needs is part of the change enablement process.

A nod to the paranoid:  you could communicate EVERY change since EVERY change could cause a disruption.  Among the downside to this approach:

  1. The boy who cried ‘wolf’ effect kicks in.  Overcommunication results in not paying attention to any communication.
  2. Those who might be affected only want to know what might disrupt their work.  They do not want to put time into figuring out how they might be affected.  This is especially true when the impact possibility is remote.
  3. The time required to communicate every change becomes a drag on getting anything done.

So when do you communicate impact of a possible change?  First, the obvious instances:

  1. If the implementation plan involves end-users (they must be off the system), then you need to let them know before pushing them off the system.
  2. If part of a rollback plan involves end-users, they need to know what to do and when to do it.
  3. If the end user will need to use the service differently after the change.  Training is required in advance.

In instance one, you need to communicate:

  1. how long they’ll be off
  2. how they’ll be notified that the change is complete
  3. how their information is protected
  4. how a rollback will work (and, in so doing, that there is a rollback action)

So what about the changes where, if everything goes well, the end users will never know it happened?

  1. Is it a routine and perhaps even frequent change?  Operating system updates and application patches fall into this category.  While there is a possibility of disruption, it is unlikely.  No notification is needed.
  2. How far away from the user is the change?  An example is changing the power to a server UPS during a maintenance window.  In this instance the change is so far removed that notification is pointless.
  3. How many people will be affected by the change if it goes badly?  The smaller the number, the less need for communicating the pending change.  Doing changes in smaller batches rather than a grand implementation reduces the number.  A notice about the change may be in order.

The ITIL practice of Change Enablement still requires recording change events even if no communication is warranted.  Entering changes into the help desk history provides a single source for identifying the change as the basis for unexpected disruptions.  The IT initiated change is a service request completion with IT as the requestor.

Development Efforts and Agile

IT development addresses business or an IT infrastructure needs.  A development effort may originate in service requests requiring a sustained and concerted IT led effort.  A business case for a development initiative can be a well-researched and defined service request. What discerns a development effort from a typical service request is the resource requirement.  The principal resource needed is time.

Project Visibility

Sustained effort requires sustained communication.  The Agile practice sets a cadence with set length effort intervals which end with stakeholder review.  This applies in efforts that exceed a few days and carry on for weeks (or months). 

An analogy to building a house works well for longer efforts.  The regular reviews assure that the stakeholders ‘hear the hammer’ of progress.  Having a project Kanban board visible to the stakeholders enables progress reviews before the review date.  An updated board enables stakeholders to ‘see the nails being struck’. This reduces the formal requests and informal queries into ‘how’s it going’.  This also should reduce concerns about ‘what IT is doing’. 

Make Changes Small and Quick

 

 

What is a Destination