Information Technology (IT) is one area of any business
that is marked by these characteristics:
- Excellence is largely determined by a lack of
- The skill and knowledge to understand the
complexities are not understood by most people (it's a specialty field, after
- The most consistent trait is change, and this
trait can be controlled by seldom stopped
This article covers the idea that information technology
has never truly been about the technology itself. Computer science and computer engineering are
about the computer and software. IT professionals may be viewed in many
instances as manufacturing personnel (put this here, insert this, type this,
install this). However, most IT people are
really in the business of information service delivery. That's "endpoint delivery" in geek
terms. In business terms, it simply
means that the end result is a small step from face to face communication. IT people are just delivering information
through screens instead of direct communication - but it's still a service.
In order to make this change from IT as a product to IT
as a service, new terminology may be needed.
Since accounting is a service, let’s call our new model Information
Service Delivery (ISD for short). This
term suggests a shift from the computer (or screen, as we shift more to
multiple delivery platforms) to the point at which the screen and the person
Looking at technology as ... well, technology, tends to
reduce the quality of output to the end user (translate this as person). In other words, since you aren't providing a
service, you can get away with fixing the computer and call the problem
fixed. If you look at IT as ISD you also
have to qualify if the information was delivered properly after service is
performed, not just that the computer is working. This leap from technology to people can
radically improve the level of service, the understanding of your job and the
contribution to the people working in the firm.
Let’s revisit the three statements above and look at how shifting to a
service model can improve the quality of IT.
largely determined by a lack of issues
Many technology issues can be benchmarked on this
alone. Help desk ticketing solutions are
set up to let you resolve tickets when the issue is gone. They're even called issues or tickets in most
systems - because you're dealing with computers or other devices, right? Punch in your work and you are, like an
Contrast this with information service delivery. In this instance, a problem isn't fixed until
the information is resolved, not the issue.
So, an issue with a computer driver not working might not just stop at
the driver being updated. It will stop
when the displays are verified as working by the user. I think this, in many cases, is very
different from the way the IT person uses the displays. A follow up 2 days later may uncover that the
assumption for the fix wasn't quite correct.
Is the information flowing again?
This follow up can be automated, but is that good service? Selecting a subset of tickets to call on
might be a great way to see if you are truly providing what you think you are.
Other issues are not pure IT and shouldn't involve just
IT. A failed patch is an IT issue, let's
say. But when the patch has been rolled
back, what if you find out someone is having trouble using write up properly
during the patch removal (since you have to do it in person on the one machine
that didn't take)? That's an ISD issue and might not involve you directly - but
you can be accountable to make sure the issue gets resolved.
The skill and
knowledge to understand the complexities are not understood by most people
(it's a specialty field, after all)
As an IT professional, specialized knowledge is crucial
to the completion of projects. However,
communication is crucial to the successful delivery of these projects. On teams, this may not be the person who does
the work, but a successful information service delivery should include the
business and information delivery reasons why a project was completed
successfully, not just what was done.
Most often, the heavy lifting in IT is not communicated
because of the specialty knowledge needed to understand what happened. However, this often bleeds over into areas
that don't need specialty knowledge.
Thinking with a service delivery mindset may allow these areas to shine
through, which will in turn allow for improved communication.
In addition, that communication, since it is part of the
service, will need to be catered to the recipient. You wouldn't sell a highly technical watch
that needs some assembly to someone looking for a stopwatch, so why would you
want to communicate more than you need to in order to let someone know their
problem is resolved? There is a balance
between what was done and why that change was important to the person reading
or listening to the message.
consistent trait is change, and this trait can be controlled by seldom stopped
In the IT world, oftentimes the reaction to change is loudest
in gadget arenas as well as in the camps that are stalwarts for technology that
is tried and true. In the business
world, technology often is delivered too often for comfort or not frequently
enough to keep up with the times.
Think change using an information service delivery
mindset. Will this change help the
information being delivered? If not, it
might be a good candidate for reevaluation.
Sometimes it's a patch that will fix a lingering issue. Other times you may be switching out a system
without a strong information case - which in some instances is not evaluated
properly in the business case for an upgrade.
"This will give us a competitive advantage because
we'll be ahead of our competitors" is business language but says nothing
about the quality of information being delivered. Let's say the software upgrade mentioned here
fundamentally changes the three key screens of an application. Although it gives a competitive advantage,
the information will not flow as cleanly after the upgrade. Understanding this and acting on it will help
to improve IT from installer to enabler.
Consider information service delivery as a great way to
consider how IT provides value to a firm. An example would be "a change is
happening Saturday morning to improve the review process during x". This is much easier to digest than
"release 6.208 of x package will be installed on Saturday
morning". The first sentence states
how information delivery changes; the second merely states what is being
installed. The typical IT response is
what was done, not what value the change provides. This shift in communication is crucial to
helping your firm adjust to whatever change is coming.
Communication using an information service delivery model
may initially increase ticket resolution times.
In the long run, however, that communication improvement will help
everyone in the firm. Issues will be
completely fixed, reducing reemerging tasks.
Updates and system downtime will be assessed based on what is being
improved, not what dot release is coming online. And you and your firm can start to benchmark
the success of technology on metrics beyond uptime, service SLAs and other
metrics. Things like Net Promoter
scores, satisfaction indexes and quality feedback will start to drive an
improvement in service that may have an impact across all departments in the
The longer information as a service is taken into account
during IT projects, the more end users will become allies in transitions and
updates. Translation will become easier
between technology and business, and understanding of IT projects will
improve. Look for those in your team (or
your firm) who can view IT as information service delivery and use those people
to increase the quality of information you deliver. You will be part of the engine in your firm
that develops people because your service and communication will be concerned
with how they work, not what they use. Look at ways you can start improving service
to your firm. The change will take time,
but the change is worth the cost.