Tuesday, 16 December 2014

Communicating with your Business

A challenge that most people face no matter what line of business you are in is the ability to communicate effectively. There are countless books, articles and experts who will profess ways to improve upon the delivery of messages to an audience. My simple advice is to personally connect with the audience wherever you can.

From a service management perspective a common challenge is ensuring that we communicate in a consistent way with language that ensures that the business community we are informing gets the most value for the message we are sharing.

Two of the most common message types are that of incident and change notification. The downside of this is that we are communicating that something is not working and we are trying to fix it, or that we are trying to maintain something so it doesn’t break. Quite often these may be a set in a template so that we can ensure that the format if nothing else is consistent. When in email form these messages also are often sent from the service desk or a mailbox type source. In other cases these might be alerts which are posted on a self-service portal or intranet site. In other words these are very sanitized communications.

The challenge is that while the majority of our communications are set up this way we may have other teams who have been handling communications directly for a period of time building a relationship and level of trust with their audience. An example of this would be an applications sustainment person or in its simplest form some type of business relationship manager.

Because organizationally we strive to have a consistent process to provide communications, whether you are IT or HR or what have you, we will look to have these “communications rebels” conform to the standards which have been established. The risk, in my opinion, is that we in effect break down a personal touch with the business which once broken are so hard to get back. The question you need to ask yourselves is their more value in having a communication method which is consistent or to have an understood method that still embraces that established relationship while still adhering to the policy to communicate for outages scheduled or not.

What may need to happen is to learn from the more personal connection method of communicating and where applicable work to establish similar lines of communication. Granted this might not work for company wide or large department outages, however once you are in a position to really relate with the business in terms that matter most to them (outages as a result of an issue or as a result of scheduled work) you may also find that details about the delivery of the services you are providing which were once hard to come by are more easily shared.

It all starts with talking with your business.


Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn



Thursday, 11 December 2014

Improving the Customer Experience

In December I find I am particularly more aware of the need for an excellent service experience than at any other time. Due largely to holiday shopping either at the shops, or online doing the same thing without the need to fight traffic, find parking, and be swarmed with mobs of people. Did I also mention I leave this to the last minute?

With that said, whether you are looking for the most popular toy for your kid, that especially ugly Christmas sweater for someone special, or if your leveraging services through your company, you are looking to receive exceptional customer service. While you may not view your business as a customer in the traditional sense, you are still providing a service to them which they consume.

Think about the way in which your business interacts with you today. Would you describe it as a consumer focused experience? In other words from the consumer perspective how would they categorize their experience. More and more people are given several options in the way in which they can interact with the service provider. It can be done through self-service, social media, or by email and phone. The challenge is that when outside the workplace the options are really diverse while at work we generally only using email and phone. Why is this you might ask? Well primarily the teams which are determining the delivery model are the same teams which manage it, the "this is the way we have always don it" mentality. Whether it is IT or HR you have to start thinking in terms of the customer experience.

Sounds simple enough but how do we do that?

The first thing you need to do is first take a hard look at the ways we provide service today and break it down to understand what it looks like 'by the numbers'. You might identify that 95% of requests are through email while the rest is via telephone. Because of this current state we have our service desks staffed to accommodate that work type. Important top note if we want to make changes in that dynamic down the road.

Next start asking your customers about was is working well and where opportunities for improvements exist. Gathering a list of challenges will allow you to see if there are any quick wins. For example an item identified might be that while the customer sends in an email they may not have visibility on the status of the request. Something as simple as an email sent back to the customer indicating that the work is underway might go a long way to improve the customer experience.

Another component to look at is the “who” is interfacing with the customer. Some people are just better at talking with customers. Where the opportunity exists have these people dealing directly with people via phone for example.

Soliciting feedback is a continuous loop. Just because you have gathered some feedback from people once doesn’t mean you should stop there. The goal is to continually make small adjustments, measure the results, gather feedback, make some more improvements and repeat the steps.

Be sure to share the findings within your shared services. More often we approach the service delivery in silos such as HR and IT and rarely share our findings so that each team (who shares the same customer base) can make improvements without re-inventing the wheel.

Feel free to share what improvements you have made to your service delivery that went well. Also feel free to share your pain points.

Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn

If you like these articles please take a few minutes to share on social media or comment


Monday, 8 December 2014

Keep it Simple – SLA and SLM

At a recent ITSM event I was speaking with another practitioner who said that they were looking to implement service level management. The challenge was that as he was describing this activity he was developing a crinkle in his forehead from the forlorn look on his face. I asked him if they were in a good position to move forward on this and he said “our CIO thinks so… he thinks we would be in a better position to provide service if we had some service level agreements put in place”

The first question I would ask is whether you had a service catalog in place. He indicated that they had something but nothing that was managed or formal in a way that was usable. I went on to explain that the purpose of ANY catalog, service or otherwise, was to outline what services were provided. To do this you really need to know what the business needs. The other thing is to start looking at this from the business perspective as well. What ‘services’ is the business consuming.

This takes us back to the original statement made by my colleagues CIO “if only we had some SLA’s”. keep in mind that the first word in that acronym is service. So in reality we should have a really good understanding of what the service is all about.

When looking at the definition of the service and all that applies we should be able to keep it pretty simple. In fact all the details of what the service are, including things like; what it does, when it is used, by whom, when maintenance can (or cannot be done), are easy enough to be understood by the business who consumes the service.

To do this you need to communicate with the business

It seems obvious enough, the trouble is that in some cases IT makes assumptions that they know and understand the services that they provide when in reality they are not as informed as they think. This assumption is typically the piece that is the issue when implementing service level management.

The key when looking at this is to look at how we provide service in a basic way and communicating with those who are using the services. Unfortunately IT overcomplicates things which are half the trouble.

In the beginning get the content from the business with their goals or outcomes in mind. Also get the information captured and validated in their terms rather than the IT (technical) viewpoint. Getting the business input might be a challenge if this hasn’t gone well before the key is to market this in a way which outlines how the success will be achieved and how their input and participation will directly contribute to that success.

Once you get these requirements down make sure that they are visible (not hidden away in a group share) and that they are in the same terms which were discussed with the business. Resist the need to make this a technical document.

When you get it built you need a way to keep this current. Where it applies make sure that you integrate other service management processes to input or take the outputs of service level management. To help with keeping the process on track make sure that you have appropriate reporting to outline areas where things may not be going well so you can correct them. Also make sure to celebrate your successes where you find them.

This methodology applies to any service catalog initiative, not only IT.


Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn



Thursday, 4 December 2014

Is Your Shadow IT Really Shady?

The mention of “shadow IT’ will strike a chord differently with different people based on previous (or current) experiences. The truth is that Shadow IT exists. The question you need to ask yourself is how it exists in your organization.

The reason which the term shadow IT gets IT teams concerned is that they see this as limiting the amount of control over something that they dominated in the past. How did we lose that control you might ask? In its simplest form it is can be broken down into a few components.

     Technology skillset

Where IT was once the “all knowing” regarding technology, business relied on them as a trusted advisor in matters as it pertained to technology. There came a point however where the business community had caught up in the tech skillset and became more savvy with the way that they conducted business as it pertains to the technology they were using and didn’t have the same levels of dependencies to IT that they once needed.

      Only at home?

All things aside, people want to have the same functionality at work as they do at home. They are comfortable in making decisions based on personal research and are using a wide variety of tools at home so they wonder “why not at work too?”

      IT is its own enemy

The final straw which ties the first two together is that while our business base changed, we may not have made parallel advancements. Because of this our once valued ability to provide service now starts to appear as a roadblock on the radar for the business. This is a problem for them especially in tight economic times where your business is looking for any competitive advantage.

So what do we do? Well, to start with we really need to understand the extent of the shadow IT within the organization and what that looks like. Once we do that we can better determine what is working and what may require some assistance. After all we want to ensure our business interests are protected and security concerns are dealt with if any exist.

It is possible that a business unit bought an off the shelf application but there may be services that their vendor has also outsourced, adding layers of shadow to the shadows. In other instances we may have a formal shadow IT. It is possible that as part of an application deployment some IT people moved with the project into the business unit as part of a sustainment team. Technically they are performing IT functions outside of IT to a degree as well.

At the end of the day we are looking to ensure that the business achieves its goals. Whether there is or isn’t shadow IT shouldn’t be the concern. We need to work with the business to ensure that where IT can we enable the business to achieve its goals.

Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn






Monday, 1 December 2014

Change Management Windows – The Star Trek Way

I was recently asked a question about the size a change window should be. “we don’t want to ask for something too long as we want the business to approve the outage window we need for this, on the other hand we want to make sure that we have enough time to complete all the work and ensure we hand the systems back over to the business in the time that we had agreed to.”




This discussion reminded me of a Star Trek episode where a Mr. Scott was face to face with his 24th century engineering counterpart Mr La Forge. The discussion was of a similar flavor revolving around a system repair and went along these lines...

     La Forge – I told the captain that it would be done in an hour

     Scotty – how long would it really take?

     La Forge – an hour!

     Scotty – you didn’t tell him how long it would really take did you?

     La Forge – of course I did

     Scotty – Ah Laddie, you’ve got a lot to learn if you want people to think you are a miracle worker

While we are not looking for the business to think of us as miracle workers we do want them to have confidence that we are able to implement the changes to systems in the agreed to time while also making sure that they are not rushed and completed successfully.

This can be hard to do in the beginning when we don’t have a baseline for reference. The key is to document the work in the change record. For example the implementation part went quicker than expected but the testing took longer than we thought. Making note of these with some commentary will allow you to schedule changes more appropriately down the road. Make sure that you also think about how long a roll back might take or if none is possible the time to restore through other activities. When the change is done we should be able to say, we had more time than we needed, or next time we might want to have an extra hour ion the change window as we cut that one pretty tight.

There may also be instances where we need to take a change that is planned and where possible separate it into smaller more manageable pieces. Like on Star Trek they are making sure that critical functionality remains available so they look to change one thing at a time. Your business services are also looking to have the same level of availability. Implementing many things in a change may have not only timing issues but if something is not working as it did in test there may be diagnosis challenges.

At the end of the day we want to ensure successful deployments through planning wherever we can and build in contingencies for the few things we have not planned for. Working with your business to identify their needs as well as ensuring their service is in a maintained state can be a balancing act but this is where top communication skills come into play to manage that relationship.


Follow me on Twitter @ryanrogilvie or connect with me on LinkedIn