| PostMedia Network
"With the service desk, my core competency isn't developing a tool or
managing servers. It's making information useful to the company."
The PostMedia Network case study is based on an interview with Leslie Manness, IT
Service Manager at Postmedia Network, Inc., formerly known as CanWest Global
At Postmedia Network, Inc., better known as CanWest Global Communications,
we've had some great transformations in the last few years and we've still been able
to move forward with our ITIL implementations.
We were CanWest, a large media company and global television network. We've
always thought of ourselves in terms of three main businesses: television /
broadcasting, publishing, and digital media including Canada.com. IT is centralized
in Winnipeg in order to get better economies of scale and cost effectiveness.
About a year ago, the perfect storm hit us: the economic downturn, cutbacks across
the country, and declining ad revenue. We ended up in creditor protection, emerging
as two separate companies: broadcast and publishing, with digital media as part of
publishing. As we were going through these changes, we still had to put out
newspapers, get news into the television stations and keep broadcasting. In IT we
had a lot of money taken from our budget and we certainly weren't adding any new
staff or resources. Anything we did had to support the business directly.
One of the first things that the new management said is that we are digital first. So,
when a reporter brings in any kind of story, the first focus is on putting it out digitally,
not just putting it into the paper format and then copying the paper over into our
digital formats. With Twitter and Facebook, the new executive management really
saw that we have to change the way we do our business.
"We were struggling."
When our businesses were coming together as one company, we shared services.
We built IT very quickly and rolled out a lot of changes and new applications. We
didn't know how much infrastructure we had out there because even though we
were centralized in Winnipeg, we still had infrastructure in every site across the
country, whether it was a newspaper or a television station. Many of the newspapers
were doing the same thing at each site. Like most companies, we had silos of server and network management, with little understanding of
how everything affected the business.
We had already started on a path to process maturity,
using ITIL as a guide, and were making progress in
incident management. We were doing as good a job as
we could with change management, considering our poor
grasp of how all of our components fit into our business
services. We realized that we couldn't put business
services in place and really see end-to-end what was
affecting what. We had a legacy tool that was holding us
back, and our configuration management database
(CMDB) was a collection of out-of-date spreadsheets
across the company and country. We had developed
processes, but we could only get so far because of the
We were struggling because we didn't know how our
services were intertwined. Once, for example, we planned
an upgrade to a small server that would take it down for
about ten hours. It didn't seem like a big deal: we saw
some file shares, but it was a regular day, and we were
upgrading in the middle of the night, so we thought we
were safe. We realized too late that it was also a local
FTP site for reporters sending in stories from around the
world, and they were unable to submit news for ten hours.
It didn't look good for IT.
Searching for better tools and processes
While we were in the transition, we started looking into a
CMDB. It often took us hours just to figure out who was
impacted before we could even start a change, so we
knew that we needed a good inventory of assets aligned
to business services, and we needed to put in place
change accuracy, incident resolution, and problem root
cause identification. We created a business case solely
around the problems we'd been having and their impact
on the business so that we could get funding for a CMDB.
We started looking at how we were going to get the
CMDB in place – whether in our existing tool or in a new
tool – but at least we had the support of the company to
start moving forward.
We faced other problems besides the CMDB. Our legacy
tool just didn't give us enough information. It was too
restrictive and it had no dashboards. Nobody really knew
what was going on day to day, and that was hurting our
managers across the company. We often needed support
from the applications development team, but they were
too busy supporting business functions. We had no
budget for consulting services. And, while we were using
the tool for change and incident locally, the other offices
across the company hated the tool and wouldn't use it.
We couldn't gain buy in, and because of the way the
company was structured, we couldn't get people to use it.
We started looking at other tools, most were strictly
CMDB with auto-discovery. We looked at a number of
products but weren't satisfied: there was a lot of cost;
implementation required heavy lifting; they were going to
give us just CMDB; we still had to figure out how to
integrate it with our tool.
We also needed a cultural change away from requiring IT
language of our users. I asked the supervisor of accounts
receivable how she got along with our service desk. She
said, "It took me a couple years, but I finally figured out
the words to use with your people when something was
broken." I knew instantly this was not good. The user
should not have to learn how to speak our language in
order to get proper support from us. I started working with
my service desk, telling them to be interpreters. They
knew what they needed to hear to fix something, but they
never thought they needed to be the interpreters, and so
we've been working on this as a part of business
alignment. When we talk to the businesses, we need to
understand what is broken. They can't always tell us an
application name; they'll say, "My payroll isn't working, I
can't generate checks," and that's all they should have to
say. That was a big change in the mindset of our service
We looked into software-as-a-service (SaaS) and liked it
because we don't have the resources to support a tool
that isn't part of our core business. We saw that SaaS
wouldn't require hardware on site or take technical
resources away from revenue sources.
Try before you buy
We played with a demo instance of ServiceNow for
about three months while we were shopping and really
liked that we could try before we buy. We could implement
the tool very quickly, then go forward easily with a small
team of three: my service desk lead, who had no
application development experience; my service desk
supervisor, who worked on the project half-time; and
myself at about three-quarters time. We implemented with
only limited assistance from other groups. We liked that it
was simple, flexible and easy.
We were fortunate in finding ServiceNow because
not only did it give us IT auto-discovery, but also support
for all ITSM processes integrated for the same price as
some of the CMDB tools we had considered. I received
brand-new incident and change management and it has
been wonderful. Because it's SaaS, we're not reliant on
our application development teams or technical service
people to buy servers or to install anything. With the
service desk, my core competency isn't developing a tool
or managing servers; it's making information useful to the
We're now able to mature our ITIL processes because we
have auto-discovery with our CMDB and we have started
to build our business services. We're not very far along,
but we're seeing great results because all of our
processes – incident, problem, change – are much better
integrated. I certainly wouldn't want to try loading and
maintaining a CMDB without discovery, because of the
sheer volume of items. Of course, the trick on the other
side is ensuring data quality and relevance, but so far it's
been working really well for us.
We had had some experience with SaaS before, in our
paging notification system. But when committing your
service desk tool to SaaS, you have other considerations,
like the data centers being located in the U.S. We
consulted our security and audit teams, and since we
don't keep user IDs or passwords in our service desk
tools, we had no concerns about the data. At the end of
the day, SaaS has enabled us to move forward much
faster than we would have in any other way, and without
affecting other departments.
More eager to buy in
We originally started working with the tool in January
2010 and our plan was to go live with incident, change
and configuration management by May 1, but that would
have required all of our IT analysts to support two different systems at the same time. So, we put
configuration management in place first to let people use
ServiceNow and see the information coming in, as
we built some business services. We went live on
September 1 with incident, problem, change and
We didn't see any value in moving the old tickets over to
the new system, so we have closed out the old system
and set the old tickets to read-only. A few people asked,
"How do we get my old information? There was some
good stuff there." We tell them to pull any useful
information and create a document in the new knowledge
base in ServiceNow.
We have buy-in across the company now, and every day
I'm getting more comments and suggestions from users.
The tool is easier to use and the information is easily
accessible and usable. With the CMDB populated, users
can finally find things and they're much more eager to be
involved, which has helped us immensely in our ITIL
maturity. Users are starting to build business services
themselves, and this is a big change in mindset.
An example of a business service for us is pagination,
which represents a group of people taking information
and putting it into the page layout. That's a business
service under content management, which is the entire
process of building a newspaper. In ServiceNow, we
build out everything involved in pagination – applications,
servers, the network – so that if any piece of that
infrastructure goes down, we can see right away that
pagination is going to be affected. We know which sites
have pagination and in the pagination business service
we list the critical hours. Because we identify the business
service first, we can then identify the higher-level
business managers and notify them as necessary.
Most valuable features
Each team member now has dashboards including the
CIO. The CIO is using this data to communicate to the
executive members the volume of work that we perform.
Today everyone knows exactly what is going on. We are
starting to push this information out by business services
to our business managers and executives.
ServiceNow Discovery really was a godsend for us.
We just didn't really know what we had or where it was.
Today, we can see what has been added to the network
and we use it solve incidents quicker by looking for CI's
that have changed in our environment. We see this tool
as a foundation for our asset management program.