SysAid Blog

Blog Home
Welcome to the SysAid Blog - the place to go to find out where the IT industry is going, and what is SysAid’s role in it.

COBIT 5 Plays Well with Others

Posted by on May 13, 2015 in ITIL
COBIT 5 plays well with ITIL Are you looking for an overarching IT framework that is compatible with other IT standards and approaches?  Do you need help in building the business case to justify investments in IT service management and IT governance?   Are you looking for a way to have the governance of IT considered as part of overall governance of the enterprise?  Then let me introduce you to COBIT®! Since its introduction in 2012, COBIT 5 reflects the evolution of COBIT from an audit and control approach to an overarching governance and service management framework.  Let’s take a closer look at COBIT and the benefits that COBIT can provide for an organization.

What Is COBIT?

COBIT, formerly known as Control Objectives for Information and Related Technology, is a framework created by ISACA® (formerly known as the Information Systems Audit and Control Association) for IT management and IT governance. First released in 1996, COBIT focused initially only on auditing. The current version of COBIT, COBIT 5, integrates previous ISACA guidance, including Val IT™, Risk IT™, and COBIT 4. COBIT 5 also aligns with other IT standards and frameworks, such as ITIL®, ISO/IEC 38500, and others. As a result, COBIT 5 provides a truly comprehensive framework for helping organizations achieve their objectives for the governance and management of IT.

Why COBIT?

COBIT can be used within any size and type of organization, as it’s written in non-technical language and looks at integrating the governance of an organization from end-to-end, not just the governance of IT. Immediately one can see the positive outcomes of this approach. COBIT promotes the fact that IT is pervasive and integral in all business activities in nearly all organizations. As such, IT should be governed as part of an overall enterprise governance approach, and not separately and distinctly from the rest of the enterprise. IT can no longer be thought of as a “function” or department within an organization. IT is enterprise-wide. No longer can organizations think of projects as “business projects” or “IT projects, but rather projects, whether initiated within or external to the IT organization, must be thought of as IT-enabled business initiatives. The use and implementation of IT is not cheap, and now more than ever the investments that businesses make in its use of IT must result in furthering competitive advantage and utilizing IT as a strategic asset. COBIT provides needed guidance to ensure that IT is governed as a part of the overall governance of the enterprise.  Nevertheless, I recognize that within some organizations, governing an enterprise from end-to-end, and including IT as part of that enterprise governance may not quite be in reach just yet. If this describes your organization, COBIT can still be utilized within your organization, particularly in regards to IT service management (ITSM). If you’re already doing some kind of ITSM – regardless of the maturity of your implementation – COBIT will enhance and help identify justifiable improvements to your ITSM implementation. If you’re just getting started on your ITSM journey, COBIT provides great advice regarding the questions you should ask for identifying and justifying needed governance and management processes.  The answers to these questions then help in obtaining buy-in for getting IT governance or ITSM started in your organization.

COBIT Benefits

Looking at COBIT from the IT perspective, there are a number of benefits that may be derived from incorporating COBIT. COBIT is “framework-friendly”

As I mentioned earlier, not only does COBIT 5 integrate previous COBIT guidance, such as Val IT, Risk IT, and COBIT 4, it also provides an overarching governance for, and implementation of, other relevant frameworks and standards. So if your organization has based its ITSM implementation and IT governance on ITIL, ISO/IEC 38500, ISO/IEC 27001, ISO/IEC 9000, TOGAF®, PMBOK®, or others, COBIT can enhance what you’ve done. Through the use of the goals cascade and process capability model, COBIT can also help identify justifiable changes to what you’re doing to further improve your use of these other standards and frameworks.

COBIT helps translate business needs into IT enablers

COBIT 5 introduces the goals cascade, a mechanism that can be used to correlate business goals into IT goals and deliverables. The goals cascade starts at the stakeholder level through identifying business drivers. These business drivers then form the basis for specific enterprise goals. The enterprise goals in turn cascade to IT-related goals, which are then mapped to the specific COBIT processes that can be used to realize these IT-related goals. Within the detailed mapping, there is guidance for whether an identified process is a primary or secondary enabler of that IT goal.

COBIT provides a “ready-made” toolset

To assist with implementation, COBIT provides a robust set of tools. First of all, COBIT provides a documented question set, which can be used to clarify the needs and requirements of the stakeholders of an enterprise. For each of its 37 processes, COBIT documents a suggested RACI (Responsible, Accountable, Consulted, and Informed) matrix to help articulate the roles involved, as well as generic guidance on how to build, execute, monitor, and improve processes. COBIT also provides a process capability assessment model, based on ISO/IEC15504, to identify strengths, weaknesses, and risk. This assessment model introduces objective criteria that can be used to identify opportunities for improvement.

COBIT helps illustrate the business value of IT

Arguably, one of the more powerful features of COBIT 5 is the use of a balanced scorecard to illustrate the business value of IT. The balanced scorecard (BSC), developed by Kaplan and Norton of the Harvard Business School in 1996, is used in many organizations to help measure enterprise execution in four defined areas – Financial, Customer, Internal, and Learning and Growth. COBIT extends the use of the BSC by applying the same four areas from the perspective of IT. By doing so, the IT BSC provides insight into the value contribution of IT in business terms.

Your Mileage May Vary

These are only a few of the benefits that may be achieved through the adoption of COBIT. Like any IT framework, the use of COBIT must be approached from an “adopt and adapt” perspective. As the needs and requirements of any enterprise are unique to that enterprise, implementation of COBIT must be considered in the context of the organization, and adapted for use within that organization.

Find Out More about COBIT

If you’d like to learn more, the primary COBIT 5 reference, “A Business Framework for the Governance and Management of Enterprise IT” is freely available for download from the ISACA website (www.isaca.org).  Enjoy! And let me know if you have any questions. Acknowledgements ISACA, COBIT, Val IT, and Risk IT are trademarks of ISACA. ITIL is a registered trademark of AXELOS Limited. TOGAF is a registered trademark of The Open Group. PMBOK is a registered trademark of Project Management Institute, Inc. Image credit

Like this article? You may also like: What Is ITIL?

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

My SysAid Beta Adventure

Posted by on May 12, 2015 in SysAid
ITSM solution based on customer feedback A warm hello to all readers. I'm Danny, and some of you may already know me as the Technical Community Manager over in the SysAid Community. Over the past couple of weeks I’ve been managing the beta phase of the SysAid 15.2 Help Desk Software On-Premise release with our instrumental set of Pathfinders. Our focus, as with any Beta, was to collect as much customer feedback as possible regarding improvements and feature requests, and to make SysAid harder, better, faster, stronger! As part of 15.2, we made a wide range of improvements and tweaks, whilst implementing many sought-after features, such as third-party integrations [FR #15910], the ability to decide your own ticket prefix [FR #14042], being able to update agent settings directly from the Asset List without uninstalling and reinstalling the agent [FR #16189], and many many more – in total over 100 new enhancements (fresh features and multiple improvements).

Smooth Sailing Beta

The importance of the Beta is to ensure that everything is thoroughly tested – not only internally here at SysAid, but also by the awesome customers who volunteered to participate in our beta-testing Pathfinder Program. Despite the cautionary tales of my co-workers suggesting to bring a sleeping bag to the office, I was surprised by how calm the whole process has been. The first "pre-beta" phase, testing On-Premise 15.2.00 on MySQL, went smoothly and some customers not only installed it on MS SQL as well (despite our warnings!), but also adopted it in their production environment (I'm looking at you, Karlson!), and yet - only four issues were discovered, and of course resolved. Then came the MS SQL beta release of On-Premise 15.2.01, aimed at Pathfinders using SysAid with an MS SQL database. This triggered a significant influx of participating customers, and additional issues were identified and fixed. At the moment we have roughly 20 of our Pathfinders (both from the Community and outside of it) participating in this beta, and the feedback has been exceptional. This version is so stable you could park horses in it, so fast you have to watch out for the cops, so smooth... you get my point. Two days ago (May 19), we released version 15.2.02, which added more tweaks. Additionally, thanks to the R&D team who were ready early with a new feature (originally it was going to be included only in the next on-premise release), we also added the capability for admins to edit Network Discovery rules for WMI and SNMP scans, agent deployments, asset data updates, and agent version upgrades [#17009]. We’re happy to call this version a true... *drumroll* Release Candidate! *cue cinematic orchestral music*.

Challenge Us

But it’s not over yet! I’m excited to invite you to participate in these final stages of the beta testing and challenge our 15.2.02 Release Candidate to the test as to whether it truly deserves its title. If you haven't already, please join our Pathfinders Program and tell us more about how stable it is – or how much of a badass you are for managing to break it (*knocks on wood*). And may the force be with us. The final version of SysAid 15.2 is planned to be released early next month (June), when it’ll be made available for all customers to enjoy. Until then, you’re welcome to reach me at at my virtual home – the SysAid Community. Cheers and until next post!

Like this article? You may also like: 2014 in (Content) Review

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

What Is ITIL?

Posted by on May 5, 2015 in ITIL
If I type “What is IT” into my favourite search engine then the suggestion “What is ITIL” appears near the top of the list of suggestions, so I guess lots of people must be asking this question. What is ITIL?
Unfortunately this is one of those questions that is very easy to ask, but quite difficult to answer. I followed the links that I found when I searched for “What is ITIL”, but the explanations I found were often written in language that would be quite hard to follow if I didn’t already know what ITIL® is. Here are some examples:

The Short Answer

I guess if you’re reading this article then you’d also like to know what ITIL is, and that explanations like these have left you still searching, so here is my attempt to answer the question. I’ll start with a one sentence explanation, just so you can compare my attempt with the ones I found on my internet search.

ITIL is a way of ensuring that investments in IT create real value by providing a consistent, structured framework for planning, building, and running IT services.

A Longer Answer

If my short answer leaves you no wiser, then let me give you some context as a basis for a more long-winded explanation that I hope will be a bit easier to understand. We are becoming increasingly dependent on IT, both in our personal lives and in the organisations where we work. We invest significant amounts of time and money on purchasing and using IT equipment, so we need to make sure that our investment delivers the value that we need, rather than just soaking up all the resources we make available before letting us down when we most need it. Obviously, we all want IT to deliver the value we need. ITIL is simply a way to help ensure that we do all the things we need to do to make sure that happens.

Services and Service Management

Organisations don’t get any value just from their hardware, or their network, or the applications they use; it takes all of these things and many more to create value. ITIL considers IT as a provider of services that creates value. There are lots of different definitions of what a service is, and I’m not going to quote the ITIL definition here as that would require a lot of explanation. The simplest way to think about it is that a service is something that somebody else does for you, to help you achieve something that you want. Examples of IT services are:
  • Gmail, Hotmail, or the email service you receive from your Internet service provider
  • Provision of a PC and all the required software, hardware, and support you need so that you can use it for your work
  • A customer relationship management (CRM) system used by a large organization to manage all their interactions with their customers
An organization that wishes to provide these IT services efficiently and effectively has to do lots of things, including:
  • Understanding what their customers need, and ensuring that they invest in the right services to meet that need.
  • Making sure that each service they design can deliver not only the functionality customers want, but also sufficient availability, the right capacity, and all the necessary security features.
  • Planning how to implement new and changed services so that they are properly tested, and they actually deliver what is expected.
  • Operating the services and dealing with things that go wrong.
  • Continually monitoring everything they do and planning improvements.
These sort of activities are called service management, and since we are dealing with IT services, they are IT service management, commonly abbreviated to ITSM.

So What Is ITIL?

Now that I’ve given you a bit of context I can try again to explain what ITIL is. ITIL is the world’s best known framework for ITSM. It includes:
  • Publications describing ITSM best practice that you can adapt to suit your own environment
  • Training and exams to help people develop understanding and skills
  • An endorsement scheme for ITSM tools to help ensure they can deliver the functionality required
  • A global community of consultants, practitioners, and trainers who share ideas and promote best practice
To find out more about ITIL you can:  

Like this article? You may also like: ITSM Basics: A Simple Introduction to Incident Management

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Change Evaluation: The Seven R’s Revisited

Posted by on April 29, 2015 in ITIL
Seven R’s trigger ITIL’s change evaluation process The 2011 version of ITIL introduced the lesser known change evaluation process. It’s a great addition, and I haven’t seen a lot written about it. The first thing to know is not every change requires a formal change evaluation. It’s intended to be used primarily for major changes, where the complexity and scope of the change warrants careful and formalized evaluation. Change evaluation comes with its own Seven R's - a handy same-letter list that’s easy to remember, and can help make sure we’ve explored the most common sources of issues with proposed changes.
Here’s the seven R’s:
  • Who raised the request for change (RFC)?
  • What’s the reason for the RFC?
  • What return is the change expected to deliver?
  • What risks does the change pose?
  • What resources are necessary?
  • Who is responsible for the key tasks?
  • What's the relationship between this and other requested changes?
The list is not intended to be a set of required fields on the RFC form; modern IT systems are far too complex. It’s intended to be used in the evaluation process to trigger deeper thinking about a proposed change and uncover potentially hidden sources of risk and unintended consequences.

A Great Start

The R’s are a great start, but we really need to do a little more serious detective work. Remember, change evaluation is reserved for major changes, where there’s often a great deal of complexity and high visibility. Let’s put on our detective hats, and take a closer look.

Raised

Who raised the RFC is a good place to start. It goes well beyond who's filling out the form or taking administrative responsibility for the RFC. Change evaluation needs to know the role and business function of the requestor. If it's IT, what functional unit? Why was it raised by this particular person or group? If customer, does the requestor represent all user groups of the service? Has the requestor worked with relationship management and/or the service owner? Was it raised by a person who was directly impacted by a recent incident? Understanding more about the role and context of the requestor helps change evaluation understand the bigger picture. Again, these are supposed to get you thinking deeper about the proposed change.

Reason for the Change

An analogous question would be "What are you hoping to accomplish with this change?" This one can be tricky because you need to get to the question behind the question. Sometimes RFCs come on the heels of a significant incident. Some changes are proactive changes to avoid a potential incident or problem (such as keeping technology current). Other changes are raised to address very specific business needs. Some reasons are urgent and pressing and others are related to longer term releases or system upgrades. The question of what you hope to accomplish helps identify what specific outcomes are anticipated, so change evaluation can help determine if the RFC is likely to deliver them. This question should be answered in plain, unambiguous language that makes very clear the purpose of the proposed change. In my experience, this question can unearth significant issues. In the evaluation process, it may be discovered that there are differences in understanding the reason behind a change. If the request isn't clear, it's harder for the change to be successful in meeting the desired outcome(s).

Return

This one tends to get forgotten because it's hard to answer. ”Return” here is talking about business value. It too should be answered in plain language. An example would be: "RFC will deliver new order processing functionality that will reduce order processing time by 20%". The "return" should be specific and measurable, and from the perspective of the business. If it's an infrastructure RFC, what risk or impact is it seeking to mitigate, and what's the value of the avoided risk?

Risks

Identifying risks associated with change requests is critical for an effective change program. The risks here are not limited to technical and infrastructure risks – things like adding firewall rules may block application-required traffic. When identifying risks, keep a business-impact focus in mind:
  • What could happen that would have adverse impact on the business?
  • Could the change impact other services running on the same infrastructure? Could there be unanticipated impact to business processes? Will the change increase the support load? Are there multiple changes happening at the same time, and are they compatible?
  • Do the results from the test environment accurately predict what will happen in production?
  • Will the changed service be able to meet its service level targets?
There are a number of formal risk management methodologies, such as ISO 31000 and Risk IT. If your company uses a formal methodology, that would be a good place to start. Otherwise, a simple and common approach is to create a risk matrix, where risks are identified and each rated on the probability of its occurrence, and impact, if it does. Risk Matrix for ITSM With this simple matrix, it’s pretty easy to see that you should focus most of your attention on the critical and high risks, some on the minimum, and little on the low risks. One thing to keep in mind is that all changes have some level of risk. It’s not helpful to either under or over state risks. Both can have disastrous impact.

Resources

This is where you identify all resources required for a successful change implementation. This includes everyone needed to build, test, implement, communicate, support, or roll back the change.
  • Will the required resources be available during the development and implementation phases?
  • Are other changes scheduled that require the same resources?
  • Are the needed infrastructure and technical resources available (e.g. server and network capacity)?
  • Is there sufficient infrastructure capacity to support the changed service? (How will you know?)
  • Do all the players have what they need to be successful? (Will they be available immediately after the change is implemented?)

Responsible

Similar to resources, the “responsible” question seeks to ensure there are clearly established and understood roles and responsibilities. A RACI chart may be helpful (see What’s a RACI chart and how do I use it?). This is a critical step that helps eliminate assumptions and avoid misunderstandings.

Relationship

This is where we seek to understand how the change in question may impact or be impacted by other recent or planned changes. How do the service components fit together?
  • Are there hidden dependencies to the components being changed? (What efforts have been made to identify?)
  • Are there unknown users of a service that’s being changed or decommissioned? (How do we know?)
  • Are there version dependencies between components, and have they been tested?
  • Does the test environment accurately represent the production environment?
  • Are critical parts of the infrastructure needed to implement the change that may be unavailable because of other changes?
Beyond the scope of this article, good configuration management and change modeling can be really helpful in understanding complex relationships.

Finding the Right Balance

Out in the real world, we all know some changes are more risky than others. It’s up to you to determine how deeply you need to go in evaluating a proposed change. If a change is large or complex or significant risk may be present, change evaluation is warranted. Changes that involve critical business functions or significant business process changes are excellent candidates for formal evaluation. It’s been my experience that just when you think a change is benign, you get hit with something you didn’t think about, but maybe should have. So, let me suggest a few additions of my own – reality, respect, results, and repeat:

Reality

This is where we take a quick reality-check. Yes, 12 Ninjas might drop from the ceiling and cause a large impact. But, in reality, how likely is it to happen? Have changes similar to the one under review been successfully implemented? Reality can be an important data point to help strike the right balance. Data is a great reality check. Historic change information can be really helpful to help determine where additional evaluation is warranted and where it would be unnecessary. In reality, some change types, and components are just less problematic. Likewise, some that should be harmless no-brainers can cause big problems. Use reality as a guide.

Respect

The Change Advisory Board (CAB) is comprised of your best subject matter experts - those who have deep knowledge and are respected for their expertise and track record. Respect their experience and knowledge. When it comes down to it, change evaluation depends on people who are good at what they do.

Results

  • Do the test plans adequately ensure the change will operate as intended?
  • Has business functionality been tested? (Have the ‘intended result’ been validated?)
  • Do the test results meet identified criteria for success?
  • Were business users involved with testing? (Were any significant issues raised?)
  • Has the business reviewed the test results?

Repeat

  • Has the change being evaluated been done before? (Was it successful?)
  • Is it a change that’s been attempted and failed? (Have the reasons for the failure been identified and addressed?)
  • Have previous changes to the service components been successful?
  • If it involves vendor-supplied updates, what’s the track record of prior updates?

Making It Happen

Remember to use the R’s as a reminder to explore all aspects of a change. Effective change evaluation is core to successful service delivery and business value. Use the seven R’s of change evaluation to make sure you’re covering all the bases. Also, take a look at the extra ones I’ve suggested. How about you? What additions would you make? Do you have any that you’ve found helpful?

Like this article? You may also like: Defining Metrics for Change Management

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Software Asset Management: How to State the Case for Obtaining a SAM Solution

Posted by on April 22, 2015 in Asset Management
Software Asset Management (SAM) is also part of IT So you’re the “go to” guy or gal within IT, and IT service management (ITSM) has been your life for the last five years.  You can soak up ITIL and ISO 20000, and your team is well versed in the nuances of ITSM and how that has been moulded within IT to deliver great service to the rest of the business.  And then someone says to you “What about Software Asset Management (SAM)”?
Your IT budget has been apportioned to various projects and training requirements for the next 12 months, and your ITSM solution doesn’t come with a reconciliation engine to enable comparisons of inventory data to proof of entitlement (contracts, licenses etc.), which in turn could produce a license compliance report. Plus the CIO has said there is no money in the budget “for another tool, on a topic I have little comprehension of.” (Sorry – I’m sure some CIOs understand SAM!) So what’s a hard-pressed IT manager to do to try and enforce some degree of SAM discipline within a company without a bona fide SAM solution to measure his/her efforts?  Below are a few ideas that could make the job of managing an IT estate a little bit easier, as well as acting as a way to state the case for obtaining a SAM solution in next year’s IT budget.

Control Spending on Software

The organizations where SAM is weakest will most likely have the most liberal financial control also.  If software purchases are not funnelled through an IT portal for a company to maximise the benefits to be derived from economies of scale, then there is also a good chance that any evidence of purchase/proof of entitlement is not finding its way back to a SAM function to justify the install.  Commercial culture has to be bent, not broken – so perhaps a step forward is to say to those liberal budgets holders:  “Buy whatever IT you like, but buy it through authorized channels.”

Control Deployment of Software

Not unlike the previous restraint mentioned, deployment of software should not be a knee-jerk reaction to a red-faced project manager looking to massage his ego by demanding deployments “yesterday”.  Granted, certain installations can be justified off the back of existing contracts, but make sure financial evidence can be levied against individual installs for true compliance.  However, due-diligence should take place between the requestor, procurement, and deployment to ensure that what was requested was what was bought, and that what was bought was what was installed.

Educate Your Workforce

Communications best practice highlights that the right message goes to the right people at the right time in the right format.  Clearly, the SAM/IT asset management (ITAM) message that goes to a developer is completely different to the SAM/ITAM message that would go to an end user or a contractor.  Ensure that the policies and ambitions for managing SAM are consistent across the board.

“Be Mean” with Your Supported Software Catalogue

If you rationalize the number of software titles that are used to run your company, then the amount of SAM overhead in chasing down entitlement and contract management is also reduced.  Interestingly, this can have a knock-on effect to the service desk, as fewer titles also leads to a reduction of support tickets on the dizzying array of titles that could be installed on a given IT estate.  Interestingly, a mean supported software catalogue can also be used to further limit purchases, as only approved software will receive authorisation to proceed with a request for purchase.

Start Learning About Licensing Types

One license = one install is so 90s! Terms and conditions offered through support and maintenance and/or volume contract agreements can extend the capability/footprint of software considerably (and in a legitimate fashion too).  Also, try and stay vendor-neutral in respect of learning licensing types, as you will start to find that terminology plays a large part in how one vendor to the next defines a device, or a user, or an installation.  This extends to the roles devices play too – one vendor might view a back-up server as requiring a full production license, regardless of whether the software is being used or not.  This gets evens trickier in the database space as the hot/cold standby nature of the reserve install can be factored into a license calculation.

Get to Understand How IMAC Can Influence SAM

It may be that you believe once a SAM solution is installed, you will be able to produce real-time dynamic license compliance reports at the touch of a button.  The question to ask yourself here is: Do you really want to? Is it reasonable to be taking license compliance reports to senior management on a daily/weekly basis asking them to make management decisions on either uninstalling or purchasing software to rectify a compliance position?  The churn and frequency of change within your IT estate should offer a fairer indication as to how frequently such reports should be placed in front of senior management for a call to action.

Understand the Role of Software when Conducting Value-Chain Analysis

If it is your intention to take SAM into the boardroom, then understand the role and value the software has in revenue production.  Calculation of this is a subjective matter, merely comparing the cost of the software against the revenue the software supports could be viewed as naïve. Whatever calculation you do settle upon, make sure you can justify that calculation in support of any figures that might be placed before the board.

Identify Allies to the SAM Cause

Once you start to dig deeper to understand where data is coming from to derive a license compliance position, you will come to realize that a significant portion of it comes from outside of IT.  A SAM manager has to ensure the goodwill of key stakeholders in getting that data in a timely and accurate fashion, and also in a format that will ultimately be acceptable to the SAM solution.  Establishing those links prior to the arrival of a SAM solution will put you in a great position.

Try to Spot Points of Crossover with Other IT Disciplines

Don’t reinvent the wheel when it comes to creating SAM processes; several of the processes required of ITSM, as outlined in ITIL, can be modified to address SAM concerns. I hope the above gives you a flavour of issues/steps to address prior to acquiring a SAM solution.  Regardless of the size of your organization, SAM should extend as far into your organization as the IT does, and does not “go away” merely because a SAM solution has been purchased.  If anything, SAM serves to prove the old maxim of “Garbage In – Garbage Out”.  If you can adopt an ounce of quality assurance/plan-do-check-act (PDCA) in your approach/preparation to SAM, then when the SAM solution arrives you will be better placed to gain quality results that serve, and can be trusted by, the business. Image Credit

Like this article? You may also like: 9 Ways ITAM Can Empower IT

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Meeting Business Needs: Doing the Right Things and Doing Things Right

Posted by on April 14, 2015 in ITIL
ITSM-business alignment Good business-IT alignment (please note that I use this well-known and oft-used phrase reluctantly as IT is part of the business) relies on two things: doing the right thing and doing things right. Without both of these, what IT does will never live up to what business colleagues and stakeholders need and expect; where:
  • Doing the right things” means executing IT initiatives that support business strategy.
  • Doing things right” means executing these initiatives in a way that delivers the proposed value within the required timescale and cost constraints.

How Does IT Normally Fare?

In my opinion, IT can sometimes do the wrong things badly. But it’s less common for IT to do the right things well, at least in the eyes of business colleagues. The two key factors here are business-IT alignment and operational excellence. When there is a disconnect between the business and IT there can be a reduction in the business value generated, even if IT is run very efficiently. And if IT has issues with its operational efficiency, it may struggle to deliver value to the business, even if it does know what the business needs. This can be represented in a simple matrix that shows IT maturity in the context of business alignment and IT operations. IT maturity matrix

So What Can IT Organizations Do?

Organizations want and need to move up and to the right (into quadrant C), with this desire driven by different instincts on either side of the divide. The IT department wants to focus on new infrastructure and improved operational efficiency, because that’s what they care about. They want to move across the matrix from left to right. The business wants IT to “stop messing around with the shiny technology” and to give them what they really want (or at least what they think they want). They want IT to move up the matrix. They want more business value from IT. Unfortunately, many IT organizations (being more focused on the “how” rather than the “what”) will take a path from A through D to C. However, the preferred path would be to do the rights things slowly and then ramp up efficiency over time (going from A to B to C) as this will have a more immediate impact on the business value delivered, not to mention reducing the money spent on things that are potentially irrelevant to generating business value.

Which quadrant is your organization in?

Quadrant A

IT organizations in quadrant A suffer from a combination of poor processes and poor strategic alignment with the business. From here, IT has a lot of ground to cover. Simultaneously improving business value and internal operational efficiency is tough, so IT will need a solid improvement roadmap outlining the key priorities. The catch-22 is that the business may have little faith in IT, making it difficult to get the budget and manpower needed to get out of the “firefighting mode” and take steps to increased maturity.

Quadrant B

Organizations in quadrant B have good alignment between IT and the business, but suffer from poor execution. They understand what the business needs, but immature capabilities and processes are preventing them from delivering value quickly, efficiently, and with minimal risk to current business operations. This means the output can be frequently late, over budget, and below the level of quality the business needs. For organizations in quadrant B, implementation of best practices (such as ITIL®, the IT service management best practice framework, formerly known as the Information Technology Infrastructure Library) will help to give them the efficiency boost they need to execute delivery more quickly.

Quadrant C

Quadrant C is where IT organizations need to be, combining a good understanding of what the business needs with a solid supporting IT strategy and good execution capabilities. However, this is not an end point; there will always be room for improvement. IT organizations in this quadrant will have a clear track record of delivering business value fast, so the perception of IT will be considerably more favourable. This will make it easier to work with business stakeholders and get additional budget for improvement.

Quadrant D

With established processes and capabilities, IT departments in quadrant D are moving fast — but in the wrong direction. It’s a common situation for IT departments that put too much focus on implementing a best practice framework like ITIL. Efficiency goes up and the internal IT metrics look good but IT has effectively disengaged from the business at a strategic level. To get back on track, the IT department needs to re-engage with business stakeholders, implement business value metrics to measure performance, and institute IT customer satisfaction surveys to keep a gauge on the business’s perception of IT.

Mature IT organizations that measure business value and operational performance will be able to use their metrics to quickly place themselves in the matrix. However, the majority of organizations that actually have suitable measurements are more likely to already sit near the top-right. Organizations with lower IT maturity should be able to establish their position by consulting the business directly. Do business stakeholders feel that they have the right services and technology to do their jobs efficiently and effectively? Are IT projects delivered quickly enough? Do IT expenditures balance well against business value delivered? Do changes to the IT infrastructure frequently have an adverse impact on business operations? Is IT responsive when something goes wrong? The matrix is a tool for IT to plot its maturity level from an alignment perspective, frame conversations with internal and external stakeholders, and hopefully crystallize a commitment to moving in the right direction. With it, IT can identify whether it needs to improve internal operational efficiency, develop a better understanding of business strategy, or both. The path to business-IT alignment begins with a shift in the mentality of IT — from devices, infrastructure, and processes to customers, services, and value.

Like this article? You may also like: 4 Things You Need to Know About IT Maturity Assessments

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Improving Categorizing Incidents

Posted by on April 7, 2015 in Service Desk
Categorizing incidents in your service desk Recently a customer asked me how many different categories they should have for managing incidents. They seemed to think that, like a magician, I could pull an “ideal” number of incident categories out of a hat, and that they could somehow compare themselves to this to see if they had the right number. I gave them the typical consultant’s answer of “it depends”, because there really isn’t any right answer to this question. If you only have 3 or 4 categories then you are almost certainly doing something wrong, but if you have more than 1,000 categories then you probably have it wrong in the other direction. Between these extremes it really does depend on the scope of your service desk and what you’re using the categories for.

What Are Incident Categories Used For?

There are lots of different things you might use incident categories for. Typically organizations use incident categories to help them:
  • Determine what information the service desk should ask for when logging an incident; for example if the user cannot log in to their laptop then you may want to find out what username they are using and what domain they are logging in to.
  • Identify the correct SLA for the incident, which will tell the service desk how quickly the incident needs to be resolved.
  • Identify scripts or tools that should be used for initial diagnosis of the incident.
  • Decide which group or team will carry out initial diagnosis of the incident; for example there may be a dedicated team providing support for a critical line-of-business application.
  • Identify when multiple incoming incidents are all related to a single problem, so they can be managed together to avoid duplication of effort.
  • Decide when an incident should be escalated and which group or team it should be escalated to if the service desk cannot resolve it within the required time frame.
  • Analyse trends to identify problems and improvement opportunities.
  • Create reports that record the reliability and availability of individual IT services.
This is not a definitive list; you may have other reasons for categorising incidents. The important thing is to think about why you are categorising incidents, so that you can make sure the categories you define are appropriate for how you intend to use them.

How Many Category Fields Should You Have In Your Service Desk Tool?

It is very common to use categories and sub-categories to allow a larger number of overall categories to be easily managed. Many organizations use a three level hierarchy of categories. This has the advantage of limiting the number of choices presented to the service desk agent at any one time, while still allowing a larger number of overall categories. For example if the first level has 10 categories, and on average each of these has 8 sub-categories and these in turn have an average of 8 sub-categories then you have a total of 640 categories, but the dialog boxes from which categories are chosen only have 8 to 10 entries. Categorization in SysAid If you use this kind of approach then you need to be very careful that the hierarchy makes sense to the people entering the information. I have seen a situation where a service desk agent knew exactly what option they wanted to select in the final dialog box, but had to keep guessing to find the right higher level choices to get them to it. As well as setting initial categories, you also need suitable closure categories for your incidents. Closure categories cannot be set when a call is logged, as they depend on the outcome of the incident. Closure codes are vital, however, in helping with your incident analysis, and they often have options based on the outcome of diagnosis, such as “user training issue”, “faulty hardware”, and “known error”.

Defining Categories

The best way to set about defining incident categories is to get all the people who need to be involved into a workshop. Start by agreeing on the purpose of your categories; you can use my list above as a starting point for your discussions. Based on what you intend to use the categories for, you can decide on how many different categories you need. At this stage you will answer questions like “How many different levels of categories do we need?” and “Is the impacted IT service the top level category or should it simply be a separately recorded item of information?” In my experience, it’s better to have too few categories than too many. Very large numbers of categories cause problems for service desk agents who have to look through many different entries to find the correct one, and later on have little value in analysis, as each category has very few incidents.  This makes it harder to identify trends that you need to think about, or issues you need to address. So start with as few categories as you can, and add more as you find the need for more information.

Summary

In summary, you need to think about incident categories in terms of what you use them for, rather than just allowing people to define more and more categories that may be of very limited value to you or your customers. If you haven’t reviewed your incident categories recently then why not spend a bit of time looking to see if they are still fit for purpose. Improvements you make in this area can make life much easier for your service desk agents, and ultimately for your customers. Image credit

Like this article? You may also like: Defining Metrics for the Service Desk

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Workshop as a Blog: How to Mature a Service Management Process

Posted by on March 31, 2015 in ITIL
.itSMF Conference workshop I recently attended itSMF Norway 15 Conference. What an incredible experience with some of the most dedicated people in IT service management! I had the privilege of being one of the Service Bazaar workshop leaders. My session was How to Mature a Basic Change Management Process. The format was groups of up to 8 attendees in each of three 90-minute workshops. Each group had industry leaders (including ITIL book authors) and beginner practitioners side-by-side. The sessions were lively to say the least, and everyone learned something. Me? I got a triple dose, and learned the most. This blog isn’t a traditional How-To, but rather a summary of some gems that came out of my three workshop sessions. Note that while the sessions focused on maturing Change Management, what we learned applies to any process.

Start With Why

Leadership expert, Simon Sinek, gave a TED talk entitled Start With Why. He explains how the human brain is wired to need a why before accepting what or how. One of the challenges we face in IT service management (ITSM) is our tendency to focus more on the process, and less (often much less) on the desired outcomes and business value they create. In other words, we jump directly to what and how, and bypass why entirely. If we (and the business we serve) aren't in agreement and completely clear on the business outcomes that the proposed process maturity will achieve, we've already lost the battle. So, before we set out to mature an ITSM process, let's pause and ask a tough question:  why do you want to mature the process? And, as you may have guessed, all three groups I worked with came up with some good and some not so good reasons why. Let's get some of the not-so-good ones out of the way first:
  • The ITIL book says so
  • The ITSM consultant/expert said so
  • Process assessment rated the process low maturity
  • We need to be more like...
Better reasons why:
  • Reduce post-implementation incidents and business impact
  • More rapid implementation of beneficial changes
  • More responsive to business needs
  • Regulatory compliance
Don't worry if you struggle with the question itself, or find yourself drawn to some of the first answers. I’ve been there myself. Big part of why I'm so passionate about this is because starting with the wrong why will cause nothing but heartache and be an uphill battle. Remember that the goal of ITSM is to enhance business performance and remove barriers. It's all about business value and the results the business is able to achieve as a direct result of improvements in IT services. You need to start with an easy to understand, business-value WHY. Keep in mind that it's possible the current maturity level of a process is sufficient, and maturing it further will not increase business value.

What Are the Obstacles?

After we finished with the whys, each group then came up with a list of obstacles they face in maturing their Change Management capability. The list was lengthy and sadly all too familiar:
  • Too focused on technology
  • Too focused on processes
  • Insufficient senior leadership support/involvement
  • Insufficient resources (staff/funding)
  • Not a business enabler
  • Too bureaucratic
    • Too many forms
    • Process bottleneck
  • Lack of shared vision
  • Inconsistent understanding (terms, scope, goal)
Quite a list of obstacles, wouldn't you say? Where do we even start?

Circles of Influence

It's very tempting to focus on things that really should be in place. Things that are out of our control.  For instance, senior management really ought to be committed (bonus points if you get the double meaning!) When faced with such a daunting list, I find it helpful to label each along these lines: Can I control it directly? Can I influence it? Stephen Covey described this in his timeless Circle of Influence.

Stephen Covey's Circle of Influence

In short, there are things in your direct control, things you can influence, and beyond that—things over which you have no control, i.e. "gravity issues". If you want to make real progress, focus most of your energy on things you can control, and some on things you can influence. But those outside of that, don’t waste your energy.

Good Old ABC's

Next we took a look at the good old ABCs (Attitudes, Behaviors, and Culture.) If you're not familiar with ABC of ICT™, take a moment to check out the phenomenal work of Paul Wilkinson and team. The short of it is: Attitude - What we think and feel. Behaviors - How we act based on our attitudes. Culture - The collection of accepted behaviors within a group. In one session at itSMF Norway, we labeled each obstacle as A, B, C, or other. Guess what? More than 80% of them were ABC issues. In other words, non-technical, non-process, non-ITSM issues that relate to people. Of the three, you're more likely to change behaviors than attitudes or culture. It's been said that you change the culture one behavior at a time. You’ll never overcome ABC issues with process and technical solutions. For instance, if your Change policy states that all changes must come to a Change Advisory Board (CAB), leadership must consistently address those who do not. It’s not a process issue, it’s a people issue! If the behaviors are not dealt with, the culture, in fact, accepts unmanaged changes. But change the behavior, and eventually it becomes a cultural expectation.

Start Small and Mature in Phases

One challenge with any service management process implementation is trying to adopt a fully-mature process. Many times these efforts fail because it's too big of a leap for the organization. Fully-mature processes are also dependant on other processes that may not be in place yet. In the workgroup, I talked about a multi-phased approach to introduce a very basic process, with clear checkpoints to incrementally mature. The approach is basic Continual Service Improvement, and it works. Stuart Rance wrote The Help You Need to Adopt Continual Service Improvement, which includes a handy downloadable whitepaper.

Getting It Done

The Service Bazaar was an overwhelming success. The sessions were filled with engaged, passionate service management professionals. The collective knowledge was incredible, and the energy was off the charts. We boiled process maturity down to some key elements:
  • Start with why
  • Focus your energy on what's in your control
  • Change the culture one behavior at a time
  • Start small, and plan for incremental improvements
Join the conversation. What have you found helpful in maturing IT service management processes? Photo credit: Simone Jo Moore

Like this article? You may also like: 4 Things You Need to Know About IT Maturity Assessments

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.
Continue reading

Human Communications Protocol

Posted by on March 26, 2015 in Service Desk

.ITSM communications is a two-way process

How many times does the word ‘communications’ get mentioned as an issue in your organization (and we’re not referring to networks and routers)?

The basic human function of communicating information accurately and appropriately between people seems to pop up regularly as the reason for failure, the stumbling block, the broken link in the supply chain, and generally as the barrier to success.

Often the term ‘communications’ is used to cover a multitude of issues, from lack of information, to too much information, plus of course inappropriate information. Usually, however, this comes down to the extent to which individuals are aware of their own communications actions (or lack of them) and how this is received or experienced by others. Often it’s about misunderstandings, or in some cases personality clashes – i.e. when people don’t get on with each other.


The net result however is usually some form of problem: waste of money, delay, additional cost, failure of delivery, loss of service, missed business opportunity, etc. So communications failure isn’t just about people not being nice to each other – it’s a real business problem.

Consider the following scenario:

Your organization may be implementing a new technology service and needs some external (paid) consultancy to help with technical implementation. However the consultant is booked to arrive on a day when the person who needs to give said consultant access and support to your infrastructure isn’t available, or even aware of this happening, so the cost of the consultant is wasted.

Why did this happen? Maybe no one contacted and booked time with the relevant people. Or maybe an email was sent but didn’t make it clear what was expected, or even was sent with the assumption that all involved were okay with the details and didn’t check up. Nobody purposely meant to fail, but poor communications meant that the result was failure.

Of course when you get large projects and these gaps are not managed, this can have a huge impact on budget and delivery targets – and this regularly does happen when dependencies and logistics are not closely and dynamically managed. In addition, you are probably already aware of the potential for misunderstanding when escalating incidents and events between teams, if written and verbal notes between teams are not clear and very specific.

Technology can go so far in reducing these issues but ultimately this comes down to how well people communicate with each other as human beings. How can we make this better, particularly as people working in technology where communications is a huge part of what we do apparently…hmmm.

Send and Receive

Communications must be a two-way process. Successful communications only happens when messages are not only sent, but also known to be received and understood.

Too often in IT we think that simply sending out a message (e.g. an email) is sufficient as a form of communication, when in fact this is only (the first) part of the process.

It might be useful for IT folk to consider one of the most basic of all IT standards as a parallel – i.e. communications protocol.

As soon as computers began communicating with each other, and across geographical divides, it was established that simple protocols were needed to establish that contact was good – reliable, continuing, consistent, and also two-way. Communications protocol states that all electronic communication is predicated on the following steps:

  1. Making contact– verifying and acknowledging the link. This happens as a 2-way process, with send and acknowledgement messages being exchanged.
  2. Maintaining contact– ensuring that the contact remains in place and that messages are exchanged successfully. This involves a continual process of send/acknowledgement messages.

Technology communications protocols do the things that we humans often forget to do, namely: (1) check and acknowledge that contact has been made and (2) keep checking and verifying this.

It’s never enough to simply send a message to another party; there needs to be an acknowledgement back that the message has been received. If no acknowledgement has been received then the sender needs to take some further action to establish and confirm that two-way communication has taken place.

So, if computers do this, why don’t we humans follow the same approach?

Appropriate Human Interactions

Of course it is important to check that your messages have been received and understood, and to then also check/verify the next course of action that will be taken and by whom. This comes naturally to some people, whose personality drives them to check up and chase for responses and answers when they send out messages. These individuals are great for incident tracking and SLA management, as well as driving for results for longer term issues or problems.

Unfortunately, this isn’t always a natural condition for technical people and often they need systems (and nagging) to drive them to check up for responses. One way or another there needs to be a culture in organisations that ensures that ‘sending is not enough’. Follow up/chase activity is just as important, and is the responsibility of the sender until a response has been received.

Here are some further recommendations that can help to improve communications and thereby reduce problems:

  • Think about the message that needs to be communicated. Communication will be more successful if there is a clear objective in terms of message that needs to be sent. Try to edit and remove non-essential details that might distract or confuse the key message. Often IT projects can over-communicate too much information that is unnecessary and actually blocks the understating of the key messages.
  • Write using appropriate language for the receiver. There’s no point in using jargon, technical, or IT process language when trying to communicate with non-IT people – so don’t do it! It’s actually quite patronizing and disrespectful to include content that your audience doesn’t understand or have any need to know, and again this will reduce the impact and level of understanding of your intended message.
  • Test the understanding of your messages. It’s useful to use a number of informal feedback loops, for example the coffee machine conversation, to check senses and understanding of what you have communicated. There’s nothing like a dose of reality to help you to improve and refine your messages and the various media that you use to send these out.
  • Simplify / visualize / tell stories. Words and text are useful forms of communication but of course they are only one form of contact. Pictures and simplified short sentences are more memorable and therefore more likely to stick in people’s minds. Nobody tells a child a bedtime story using PowerPoint slides and bullet points – for a good reason. Stories require emotional engagement and use of the imagination for understanding. This actually uses more of the brain than simple text and therefore will be more likely to be retained. Use this principle to send out simple clear messages to individuals or groups.

Overall it’s important that IT people understand that they need to be good communicators to be successful at their jobs. IT people need to be able to use some basic communications skills to show that they are listening and understanding. In other words – even though they are usually listening and understanding, they just need to make it clear to their customers that they are doing so. The great news is that this is not difficult and it will only take a few changes to really make a difference..

Image credit

Like this article? You may also like:
The Service Desk and Relationship Management: All You Need Is Love

Please share your thoughts in the comments or on Twitter, Google+, or Facebook where we are always listening.

Continue reading

We Don’t Do People!

Posted by on March 18, 2015 in Service Desk

In IT, we don't do people?!.

When I started in the IT industry I was a fairly junior hardware engineer. One day I went out with an experienced engineer to learn about a particular mini-computer that he was going to mend. It was a complex problem and I learned a lot from watching him work. On returning to the office our manager told us that she had received a complaint from the customer, because the engineer had been rude and didn’t provide updates about what was happening. The engineer’s reply to his manager was so shocking that I still remember the exact words he used. What he said was “I don’t do people, I only do computers”.


That is an extreme example, but I still see a similar culture throughout the IT industry. There are far too many people in IT who think that their role is to manage the technical components, they “don’t do people”. Even in IT organizations that claim that customer experience is the most important aspect of what they do, I often don’t see the investment of time and resources that would be needed to make this true.

We often represent IT service management as a balance of people, process, products, and partners, like this…

ITSM: A balance of people, process, products, and partners

… but whenever I see a project to implement or improve an aspect of IT, or IT service management, the people aspects usually have insufficient planning and far too little investment. One example of this was a recent post on the Back2ITSM Facebook group, where James Finister described a project Gantt chart that had “change organizational culture” neatly allocated a two week bar.

There are lots of people working in IT who understand the importance of attitudes, behaviour, and culture (ABC) and some IT organizations do invest the time and resources needed to get these aspects of IT service management right. But for every great IT organization I see, there are another 10 that spend all their time thinking about processes and products, and assuming that the people part will just happen. They “don’t do people”.

So what can you do to address these people issues? Unfortunately there are no simple answers, but there are plenty of things that can help. Here’s my advice:

  • Start by thinking about yourself, and how you relate to customers and colleagues. A very powerful learning for me was hearing my colleague saying “I don’t do customers”. This made me reflect on my behaviour and led to major improvements in how my customers saw me.
  • We all have a big effect on the behaviour of people around us. If you demonstrate the kind of behaviour you expect to see from others and share the positive results this generates, then you may start to influence your colleagues, and the culture of your organization.

If you are responsible for managing people or processes in an IT organization, then there are many more things you can do:

  • Think about how you recruit people. If the only factor you consider when taking on new staff is their technical competence then you are storing up problems for the future. One organization I know recruits many of their first level service desk staff from within the business they are supporting. This gives the service desk an enhanced understanding of the issues their customers face, and helps to ensure they display the required level of empathy.
  • Include experiential learning into how you train IT staff. There are some very effective business simulations available and a number of vendors can deliver these. This training really can help your staff understand how their behaviour impacts their customers.
  • Design customer experience into everything you do. Don’t just assume you know what customers want; ask them, engage them, and make sure your processes and tools work for them. Every process, every user interface, and every interaction should be designed to deliver a great experience for your customers. If customers aren’t involved in the design stage then it’s unlikely your staff will be able to get things right.
  • Make sure that the way you measure and reward people promotes the behaviours you want. One organization had a key metric of average time to close incidents. A particularly rude and unhelpful service desk agent could score very highly on this metric, leading to the exact opposite of good customer service.
  • Talk to staff about customer experience. Have regular sessions with all IT staff where you discuss customer experience, don’t just talk about financial and technical metrics. You need to help staff understand how they contribute to customer experience, in the same way as they should understand how they contribute to your financial performance.
  • Finally, you should ensure that people issues are allocated sufficient time, and money, in every IT project. Don’t assume that people will do what you expect, and behave the way you want. Make sure your people understand what you want from them.  Don’t allocate a two week slot marked “change organizational culture” to your project plan. Think about how people might react to your project, and how you can help them to adopt any changes you need. I recommend reading Balanced Diversity – a Portfolio Approach to Organizational Change by Karen Ferris for an overview of how to do this.

If you address these people issues then you can be one of the really great IT organizations that does “do people”, and the result of this will be happier customers and increased opportunities for you to deliver great service.

Image credit

Continue reading
Subscribe
Watch & learn from industry experts about ITSM and help desk hot topics!