Case studies  | 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." – Leslie Manness, Postmedia Network, IT service manager

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 Communications.

Company Introduction

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 tool's constraints. 

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 desk. 

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 company. 

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 knowledge management. 

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.