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

Monday, 24 November 2014

Why I Look at Reporting in Reverse for Service Delivery

A colleague of mine was saying that in a recent manager meeting her team came to the conclusion that they needed to implement (or rework) a particular process to drive improved service delivery. Their homework assignment for the next meeting was to outline what they thought was a good way to not only ensure that they were implementing something that would add value from a process perspective but was going to be sustainable in the long term.

My suggestions always include the use of metrics. After all, you will need to be able to measure what you are implementing and if you want to continue to be able to improve you need to show what a baseline for ‘today’ looks like.

I mentioned to her that when we do our annual HR goals planning we are expected to have SMART goals, so why don’t we have that same level of expectation when we are looking at improving service delivery. Quite often we just don’t think about it in the same context when we really should.

From a roadmap perspective think about what your end state should look like and then start to work “backwards”. I asked her what the largest pain point was. She said it was the rate at which service requests were being handled. On average they were able to resolve requests within 43 business hours. The expectation was that these would be resolved within 24 business hours.

Knowing where you want to be you can help filter out what metrics really matter as it pertains to the challenges you face. To start with she looked at “Average duration of incident by priority”, which seems like a fairly obvious p[lace to start.

Without looking through a sea of metrics she was able to spend more time looking at what was going on from a resolution perspective by priority. Right away she was able to see that the teams were handling the top priority requests really quickly. In fact they were being handled quite quickly. This is the first win. We are doing this right so make sure your teams are aware of this success! After some checking she could see where the longer duration issues exist and was able to dial into them with more scrutiny. Look to identify what is causing constraints on the workflow. It could be the number of escalations of requests, or that there was a lack of specialized resources. Whatever the slowdown might be there is a root cause to consider in your investigation.

Much like working on a problem record investigating the root cause for your request metrics will take some adjustments. The first, and likely most obvious symptom which is eating up your resources might be (yes, I am going to say it – password resets) for example. Once you have a way to address them you will need to look once again at the potential constraints and make further improvements where needed. At each stage you need to review the improvements you have made and celebrate them.

While you might not get to the goal right away, communicating with your stakeholders on the progress will allow you to share in the team’s success in improving not only the service delivery but likely in streamlining the way you are providing service

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

Thursday, 20 November 2014

Blackouts, Brownouts and Other Change Windows

It’s that time of year where we are looking forward to the change management holiday downtime, or are we? Depending on the rules around the brownout (or blackout) you may find that there are additional complications associated with them. Here are a few:

No formalized outage window
Depending on your organization you may have an unspoken understanding that people are away from the office and that changes simply aren’t done. The risk here is that without some governance over this “agreement” you may run into issues with your business units looking to take advantage of resources who seem to be more free time and asking them to just put in this “little” change. As we all know this lends itself to problems of its own, as little change have a way of doing from time to time. If there are complications there may not be the usual support resource pool to utilize for example which could impact your business more significantly that if this change was moved out to another date.

The pre window flood
In the event that your organization normally has high levels of operational changes, you may find that depending on the brownout window duration, you will have a larger volume of changes that need to be put in before the brownout begins. It is important to outline the expectations for the window as early as possible so that you are able to have more lead time to stretch the larger number of changes in over a shorter than usual timespan. If you don’t the risk you run is having a pile of changes which may collide the week before the brownout for example. This may cloud the ability to investigate issues should an incident appear with more changes which could be the culprit.

The post window flood
I have found that January can be a month with more than its fair share of changes primarily because of brownout windows. Some teams may push out implementations until the next change (or release) window and there may either be more changes in volume, or larger changes in scope. This can also complicate the ability to have successful deployments if it is not closely monitored.

Exceptions to the rule
Overall you will need to build in some flexibility to your windows since things still could break, and some projects which have high business impact are still pushing forward. Ensure that all teams are aware of the rules. Also allow for changes that no one even considered. There may be a need to do some change which does not fit nicely into one of the boxes above. Ensure that extra approval signoff is required to make sure that implementers understand the added risk of putting a change through during this outage timeframe.

The best plan is to communicate and work with your teams to ensure that you can regulate the flow of changes over the holiday season as well as ensuring that your business continues to experience the exceptional level of service it is accustomed to.

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

Thursday, 6 November 2014

Are You Managing Releases or Are They Managing You?

Depending on your organization you may or may not have a formalized release management process. You may be handling this though some other process entirely, the question that you should be asking is whether the releases are managing you.

How can you tell if things aren’t going the way that you want them to? Firstly you probably are pushing code into production at a rapid rate (someone might say that this is agile but if the end result is more issues that smiling faces on the business end you are probably doing it the wrong way.

If this is you or you are not managing releases at all the next question why not? Generally the answer you will get is that it’s either really hard to do or that its complex. That might be the case but it doesn’t have to be so difficult.

You can make it as simple as you want. Start out with a specific portfolio of what services you want to include in your release process – watch out for scope creep! Once you know what you are including you will be able to prioritize the release and generate better planning.

Get into a rhythm. Figure out what works for you and your business. It might be quarterly, monthly, weekly or more often. The key is to ensure that you can manage what is in the release throughout the lifecycle from planning to deploy in production.

The point of release is to ensure that you are integrating all components of people, process and technology across your organization to produce consistent results for each release. Being able to control the regular flow of releases improves the likelihood of business satisfaction with the end result.
In order to do this you need to make sure that you are validating progress in each of the stages including; planning, design, development, and deployment into production.


Here are a few to check at each stage (there are others): 

  • Make sure the development and operations teams are included in the planning
  • Ensure that any system requirements gave been vetted

  • Ensure that the IT team has been notified of the upcoming deployment
  • Has all the business input been reviewed

  •        Is the Service desk ready for the upcoming deployment
  •        Have we reviewed all the deliverables to validate completion

  •        Ensure all the tests are finalized
  •        Have SLA’s been reviewed where they apply

       Overall before we get ready to deploy into production we should have a document which checks off and validates the following:
  •            What does the backup schedule look like
  •         What is the business continuity plan
  •             A completed network and infrastructure diagram for all environments
  •           Any security requirements have been addressed
  •            All of the hardware and software has been installed and a list of the assets
  •        Has the deployment had appropriate levels of communication
  •        Has training been provided where necessary
  •        Are staffing levels appropriate for the deployment from support including the Service desk and various tiers

Being able to address the simple questions will better position you and your teams to handle releases before they handle you.

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

Tuesday, 4 November 2014

Service Management and the Three Bears

Why is it that we seem to complicate reporting when it comes to service management? If we are really aligning to business outcomes it should be relatively simple, yet for some reason it seems that more effort goes into the reporting process than value comes out.

At a recent meeting with some like-minded people we were discussing this very topic. One person had mentioned that in their organization they were required to provide all reports in a summarized monthly document. When I asked what that looked like they said it was about 25 pages of tabular data with some bar and pie graphs thrown in. Literally all the reports summarized (seemed like a contradiction of terms). I asked them if it took a long time to pull together and they said that the system pulls it out and they do some editing so it really only took about an hour now that they had it down to an art form. What was more revealing was their department doesn’t really do anything with the metrics which are extracted. In other words the vast amount of data that was extracted is not driving improvement. They believed that while their teams wanted to improve they had no time to go through this “summarized” report.

Another person said that their problem was almost the opposite. They recently implemented a new service management tool which came with several canned reports as they tend to do. The leadership indicated that they should use those as they were simple and easy to read, and hey, they are already built and ready to go. They went on to say that while they were way quicker to go through than the previous organizations reports that they also had little value since they didn’t tie directly to their organizations operations and improvement strategy, if there even was one.

Much like the story of the three bears, there was a case of too much reporting, too little reporting and then there is the case where the reporting needs to be just right, which is where we want to live. To do that we need to ensure that we are measuring the things that will enable us to meet our business objectives. 

In the beginning start out simple, even focusing on one critical success factor with some KPI’s is better than blindly following some canned reports and far better than boiling the ocean with several reports with little meaning.

Once you have some measurable success you will be able to build on that momentum and continue on your service improvement initiative.

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

Thursday, 30 October 2014

Not Doing Proper Post Incident Reviews Could Haunt You

From a service delivery perspective a thing which is more frightening than having a major outage is the potential that the issue could happen again if we don’t do proper post incident reviews after service is restored. 

Call it whatever you want to; severity one, priority one or major incident, when service is adversely impacted, you need to make sure that it is restored as quickly as possible. while you are doing this however, it is important to make sure that you are collecting all the information you need to ensure you can learn from this experience to assist in the future prevention of this type of incident.

Having worked on more critical incidents than I care to remember, there is a common flow on how they operate. In the initial stage there is a sense of “is this an issue?” people are escalating information that may or may not relate to the current situation. While it may seem like a major issue it might be tougher to separate the real deal from some side effects.

The second stage is the collecting data and discovery phase where we are starting to get a sense that the issue is real and is impacting a wide majority of people. We are able to confirm through various escalation points this is indeed happening and we have started (hopefully) to gather some support resources to assist.

The third stage is what I like to call “Let’s fix this NOW”. The drivers for this may be the criticality of the service in question or an agreement of some type. It might also be driven by someone (usually at the top) doing the gargoyle over the incident command center.

The final stage is where we have resolved the incident but are looking for confirmation that it is truly restored, or the I think we’re good stage. It is in this stage where we should schedule a post incident review. It is also important at this time while the issue is being verified as resolved that the incident record is as current as possible. This way when we do the review we have all the information we can to ensure we can make the most of this.

Here is the challenge, in a culture which celebrates firefighters we want to make sure we do go back and do the post incident review in the first place. It is very easy to say we will and then another crisis appears and it gets postponed indefinitely.

The next challenge is to make sure that we have enough information to see what went well and not so well during the investigation. Did we have the right resources, what areas did we check. Could improvements be made on the investigation and diagnosis end for next time should it arise?

If what we did to correct the issue was a system change (I am sure an emergency change was recorded) than is there anything we need to adjust to other systems to ensure they are stable. If this incident was the result of a change what can we learn from that.

Remember, the review should have all parties who were involved in the incident as well as keeping people who are related to the support of the service equally as informed. Just because the application delivery team was not part of the restoration process does not mean they do not need to be informed on a service they also support.

The post incident review should also be kept as a knowledge record which is accessible to all appropriate stakeholders. Any action items which were identified in the review should have a timeframe and be validated as completed. There isn’t much point on reviewing if you aren’t going to follow up on them.

To ensure we are able to provide service we must be sure that we not only have a way to restore issues should they occur but have an equally good method of ensuring issues don’t happen a second time.

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


Monday, 27 October 2014

Wait, internal customer service has to be good too?

Your business has wants and needs. How you, as a service provider, satisfy their appetites will indicate how successful you are. In the not so distant past customers had to deal with lengthy wait times on phone support lines and long physical queues for assistance. Over time technology has enabled us to improve on the delivery of service to customers so why hasn’t the translation been made from the shared services to the business. 

Question - How is your internal organization serving your business?

Think about an everyday situation. If your local shop stopped carrying the items you needed and were available elsewhere it is highly likely that you would switch shops, even if only to get the one or two items. The trick is that these other service providers understand your businesses needs even if you don’t. they look for ways to upsell and bundle to not only get your business to keep coming back to them but to entice them that they have other products and services for sale. While your business will still come to you for the staple items they may be shopping elsewhere for specialties and you may not even realize it. It is possible that they are looking right now, and in time your services may not be able to match up to your competition

Another challenge is that we (and by that I mean you and I) find it have a different expectation of the services we receive when we are at work as compared to outside the office. If we were to get a less than satisfactory turnaround on a request, even though it was promised to be completed quicker we might be more likely to shrug our shoulders. However if the same situation happened to us personally we would not tolerate it. Think about when you started with a new company you likely signed off on an onboard package of some type including the amount of compensation, possible health care coverage, weeks of holidays but did you see a page which said you should have lowered service expectations as part of the company. We need to hold ourselves to a higher standard with regards to service delivery to our business as they may not tolerate us for long

While these examples really apply to any shared service provider I choose to pick on IT as this is where I spend my time as an employee. Trust me this is not an IT issue, it is an internal service provider issue and I have experienced it first hand while attempting to get service from other shared services.

To turn this around start thinking of service delivery like your business does. For them to succeed your business needs to be in a position to be scalable and adjust to the economic climate in which it exists. If they cannot meet customer needs and expectations someone else will and your business will be in trouble.

IT service delivery needs the same ability to be agile and scalable to ensure they can provide the services the business needs to achieve its goals.

Start by working with the business to identify the services they are using right now. Which ones are Critical, secondary or tertiary. Doing this will give you a sense of scope for your ongoing improvements.  Keep the scope simple and target a few key areas for improvement. Ensure that these improvements are measurable so that you can share the success you are having with stakeholders in a quantifiable way. Communicate this information appropriately with stakeholders in a way that makes sense to them to keep the momentum going.

There are many ways you can leverage people, process and technology to improve the delivery of service to your business but remember you need to work with your business if you are going to make any improvements which will be lasting and improve their ability to achieve.

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

Thursday, 23 October 2014

Is Your IT a Wallflower?

I recently was speaking with an IT leader who was saying that she was having challenges getting together with her business counterparts.

“They must just be really busy” she sighed.
“Are all of them are busy? Must be a huge initiative underway, is it annual budget review time or something? I asked.
“Well we only have one contact in the business who we typically deal with, and they just don’t have the time.” she replied

As she mentioned only one business contact I could feel myself fading into a flashback when I would go to junior high school dances, not entirely sure how it did that, but it did. As I stood there in a daze for a second I soon realized that this situation somewhat reminded me of asking a girl to dance. Follow me here for a bit, Think back, guys and girls would be in their own groups and as the music started there would be a hurried pace to get a dance partner much like a reverse musical chairs. Inevitably the remaining people would look around realizing that time had run out.  

The stragglers would start to justify their lack of partner by saying to themselves something like; “that girl I was going to ask is already with someone else, guess I will stand here until she’s free and ask her next time. Meanwhile, on the other side of the dimly lit room a similar group of girls stand wondering why the younger version of me didn’t come over. They would rationalize it as maybe he didn’t see me and they might wait for me to get a clue. Newsflash – teenage boys don’t get the clue!

Despite the perhaps simplistic comparison there are striking similarities with the business and IT interaction to a degree. If IT is waiting for the business to make the first move and ask them to dance they could be standing at the side with your hands in your pocket until it’s too late. In some cases when the business feels that IT is out of touch they may choose to have more than a few dances with another partner and decide to get their services from an alternate provider.

Much like in this junior high school dance example, you should reach out to other people who you might not have otherwise asked. In some cases finding another business contact will prompt your current contacts to take notice and get more engaged. Having a few different perspectives, through a multitude of ‘dance partners’ on how your business consumes services will give you a better sense of the big picture. Initiating these conversations will start to position IT in a way in which will allow you to identify additional commonalities and subtle differences which may impact the way you deliver service, as well as the way you support services

The key, I explained to my colleague, was that their discussion with the business has to continue and to grow beyond one person. In the beginning it might be slow, so don’t get discouraged. The result in the long run is that you will have improved the relationship you have with your business and will be less likely to standing wondering why you have no one to dance with.

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



Thursday, 16 October 2014

Problem Management – The value in not knowing

Having worked as a problem management analyst I always understood that there was a point where you may dig for root cause and still come up with seemingly nothing. It was because of this that I always like the quote by the fictional character Mr. Spock “Once you have eliminated the impossible, whatever remains however improbable, must be the truth.” That’s an interesting thought and I will explain how it applies to problem.

One of the challenges with working with problems is that for the most part IT may have a somewhat backwards perception on the process which searches for root cause to eliminate incidents. In many cases (but not always) IT values the work in which incident does to correct issues. We have heard this all before, so I won’t beat that drum, at least not today. The trouble is that there may be very little emphasis on what goes on behind the scenes to permanently eradicate these incidents from happening in the first place.

Some problem managers would beat themselves up as they seem to get really close to figuring it out, but then seem to come up short. While others become frustrated when they chase a wild goose so to speak and end up not solving the problem either. So what’s a good problem manager to do?

I look at it like this; I may not know what the cause of the problem is, but I know what it isn't and that is important. This might make me a “glass is half full” kind of practitioner.

The important thing I try to do is not keep these findings locked away in a problem drawer somewhere. There was in some cases considerable effort spent to find this information, but since no results were realized it looks as though nothing was accomplished which is not the case. That is why so often when management looks back on problem it seems as though loads of effort is spent with little gain.

During the investigation of a problem I try to not only track the findings in the problem record but share information with teams as there may be unrealized value to them. Your organization may have regular problem meetings in which the information is shared (if you don’t you may want to consider starting). A key thing to remember when you are having these review, you may have more interest in the investigation than the audience in which you are sharing with. I once met a guy who said his problem reviews we held monthly over a two hour session. There were quite a few yawns and eventually less turn out over the course of time.

The key is to have a format and review what is important to not only the meeting participants but your business outcomes as well. There’s a pretty good chance that if your business is impacted your meeting will have more merit. Another consideration is you likely have problems which have a low priority and may not require review, so mention that they exist but only address them as a side bar if someone requires it.

The list of review items could look like this:
·         Problem description
·         Impact to business
·         Related incidents since last discussion (volume/durations)
·         Planned changes
·         Any findings even if they produced no results.

It should include a representative from a breadth of teams from infrastructure, application support, service management, and where applicable you can include business relationship managers or service delivery teams.

This brief review will allow participants to provide input even if your current problem analysis has hit a dead end. This discussion point may also shed some light on other areas or even other problems teams are facing which may relate to your other investigations.

The key is to keep it brief will allow the people attending to get on with their day and spend more time helping to improve service delivery rather than spending time reviewing what isn’t working.

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