how-to guide 5 bad habits that kill it innovation and how

5 bad habits that kill IT innovation and how to avoid them

The Leading Provider of IT Service Management Solutions

Tearing down the roadblocks to better services, business productivity and the elusive competitive edge

How-to guide

How-to guide: 5 bad habits that kill IT innovation and how to avoid them

We often think of innovation as something that causes disruptive, big-bang changes in the way people work, or distinctly new products (or services) offered to customers - but this is only half of the story. Innovations can be categorized as either disruptive or continuous. Continuous innovation is a process of making small incremental improvements, whereas a disruptive innovation is a “quantum leap” to something fundamentally different and better. Incremental innovation is, by nature, easy for end user communities to digest – as the changes are small and everything else remains familiar. Disruptive innovations are precisely that: disruptive. They “level up” productivity, but at the cost of taking end users out of their comfort zones. This adds a larger element of risk. The bigger the change, the more resistance you will meet. The more resistance you meet, the larger the chance of failure if end users or customers reject the innovation.

Innovation may be highly visible to the customer or the end user community: new technology-enabled products or services, new ways of doing business with customers, or a new way of operating the business. Or it may involve less perceptible improvements “under the hood” of IT – designed to deliver better service performance or IT operations efficiency. Innovations may involve fundamental changes to a user interface, or the automation of manual labor to tighten an internal IT process. They may transform the way business is done and have a seismic impact on company revenue. Or simply be one of many incremental improvements that push down the cost of IT operations. Whatever shape or form an innovation takes, there will always be barriers and landmines – issues that you will need to face in order to turn a new concept of idea into a tangible and sustained benefit.

In this how-to guide we look at the 5 bad habits in IT (and to an extent, the business) that prevent companies from turning great ideas into real innovations.

Executive Summary

Bad habit 1: Closed Group Innovation

Bad habit 2: Poor Project Portfolio Management

Bad habit 3: “Fire and Forget” Innovations

Bad habit 4: Fear and Punishment

Bad habit 5: Over-customized ITSM Technology

The 5 key Takeaways

About Axios Systems

Contents

2

But it’s not just IT that is guilty here. Out in the business, innovation is often the preserve of the ivory tower executives – particularly in the more traditional organizations with rigid hierarchies and siloed departments. Ideas and priorities are mooted by closed groups of business leaders, with the belief that innovations are the reserve of the leadership and ideas can only come from the top.

This may partially true when it comes to disruptive innovation, but most incremental innovations come from the people who know the problem best – the staff at the coal face who deal with business problems every day.

So, when conversations about innovation stop at the departmental, hierarchic or geographic boundaries of the organization, innovation will suffer.

Breaking the habitIt’s the job of IT to innovate for the business. If the business doesn’t perceive what IT is doing as innovation, it’s not truly innovation. So, IT people need to be able to put themselves in the shoes of the business managers and the end user community. Ask the questions: “Is what we’re doing here going to benefit the business?” and “Is there a convincing justification for the time and money we’re spending on this?”

In essence, it’s up to the business leadership to decide whether an innovation is worth something to the business or not, so when IT makes these decisions in isolation the likelihood is that many of these “innovations” will be off-track.

The answer is more communication and collaboration all around. In some organizations, IT is deliberately kept out of strategic discussions, citing poor IT performance in the past as a reason why IT can’t be trusted.

However, as much of the innovation we see in business today is technology-driven it makes little sense to exclude the people that know technology best. In this instance, it’s up to IT to nail down the basics and build a reputation for competence (a tricky job when resources are scarce). Then the onus falls on the business leadership to listen to the IT department.

After all, it is IT that will have to build much of the supporting infrastructure – so collaboration at the earliest possible stage is essential.

Bad habit 1: Closed group innovation

When the IT department operates in a silo, detached from the business and focusing too much on the technology, there is a high risk that the two are misaligned and moving in different directions. When misalignment occurs, IT can end up delivering the wrong thing; innovation that the business doesn’t want and which delivers no value. IT people want to embrace new technologies (it’s great for their CVs) so the business ends up with new technology for the sake of new technology.

Or, they are busy upgrading legacy systems and applications, unaware that these technologies are already on the path to obsolescence - as far as the business is concerned.

Business managers may already be eyeing up alternative cloud solutions, or changes in the market may mean the technology is no longer needed. Where there is no communication, there can be no real alignment between what IT does and the business needs.

The other side of the coin is when IT people focus on innovations that will make their own lives easy, dedicating time and resources to shiny new IT operations management tools. Meanwhile, the business is neglected and getting frustrated with an IT department that never seems to do anything for them.

3


Bad habit 2: Poor project portfolio management

• Either IT is too rigid in its stance and refuses to shuffle priorities, favoring the completion of a current project first, then allocating bandwidth for this new innovation. Meanwhile, people out in the business get frustrated. It’s important to them to move forward and they feel like IT is blocking progress. Or…

• IT is too flexible and a running project is shelved to make room. The result: the new project kicks-off, but another has been sidelined - and there is a risk that it may never be completed. Time and resources have been put in, and if the project is never revived and completed, these resources are permanently lost.

An overly flexible IT project portfolio can mean that, at any given time, there may be a number of projects that have been bounced-out of action – half-finished shelfware projects which are quickly going stale.

After a while, the people who were working on them leave the company, or simply forget where they were with their tasks. So it becomes increasingly unlikely that a shelved project will ever see the light of day again.

When business priorities are changing very rapidly, the “project churn” in the IT portfolio may mean that projects are constantly being activated and parked – to the extent that only the smallest and simplest projects come to fruition.

What this means is that the larger-scale disruptive projects – those that will deliver the greatest business benefits – never make it. IT gets the blame again, although it might not be entirely IT’s fault. When business priorities are changing rapidly, IT has no choice but to follow suit.

IT Project Portfolio Management (PPM) is a delicate balancing act. Prioritizing and executing live and pipeline projects in an ecosystem of shifting sands and stretched resources is tough, but this is where the “rubber meets the road” and ideas are turned into tangible innovations (or they wither on the vine).

The broad application of technology across organizations means the IT department will always be juggling a number of projects at any one time. It will be a rare occasion when IT people are sitting on their hands waiting for something to do, so the answer to a request to kick-off another project may often be “No”, or at least “Not yet”.

The current project burden is frequently quoted as a reason for refusal, and this is often quite valid – there’s simply no bandwidth. With tight budget and resource constraints it’s impossible to tackle everything at once.

At this point, there will be some negotiation around priorities, e.g. what could be dropped to accommodate this new project? And this is where the trouble starts:

4


Bad habit 2: Poor project portfolio management(Continued)

So, when it comes to competing for budget and resources, the innovation with the strongest, clearest and best communicated business case wins. In 2013, research by Innotas found that 50% of businesses had a major IT project fail within the previous 12 months. 74% of respondents quoted insufficient resources as the primary cause for failure.

Without the right resources, IT projects fail. Thus, the innovations they support can’t get off the ground and the benefits are never achieved.

If it’s not an official project, it simply won’t get the budget and resources; so, a strong business case is both critical to jumping the barrier into the IT project portfolio, and important in ensuring it remains a priority for long enough to reach fruition.

It’s worth mentioning the impact of mergers and acquisitions (M&As) on an IT project portfolio. The uncertainty that M&As bring mean that the entire portfolio may be put on hold, as priorities are up in the air. Prolonged periods of aggressive acquisition can mean a constant state of upheaval. The project portfolio gets parked, the focus turns to stabilizing IT operations, and innovation stops dead.

At this stage, emerging innovations don’t stand a chance. Not only is the project portfolio a closed book, but access to budget and resources elsewhere will be disrupted. When the opportunities for innovation are weighed up, then it is sometimes just the wrong time for a merger or an acquisition.

However, it’s up to IT to articulate the impact on the IT environment and that includes any portfolio of innovation initiatives. If there is a major transformational initiative underway, there will be a decision to be made between the advantages of innovation versus the benefits of a merger or acquisition.

Breaking the habitIn order to release this deadlock, IT needs either more resources or better prioritization. With IT budgets remaining static for the past few years, there isn’t going to be an increase in IT resources.

One option is to automate more IT operations and divert resources that way, but this simply means kicking off more internal IT efficiency projects which can compound the project portfolio problem. That leaves only better project prioritization as the short-to-medium term solution.

In an ideal world, every project would have a solid business case behind it, making the process of prioritization easy: projects that deliver the biggest benefits win. When accepted into the project portfolio, a project should be considered “chartered”, and should only be pushed onto the sidelines by a project with a measurable stronger business case.

However, the reality is that even when the business case for each innovation is clear, it’s not a like-for-like comparison. The absence of a quantifiable justification for each project means that the priorities are often set by whoever shouts loudest and who can most successfully lobby for C-level support.

5


Technology actually works, but people aren’t using it. Nobody is adopting it. They cling to the “last best thing”.

It’s a great example of how excessive technology focus is the root of many problems in IT. Technology specialists tend to think long and hard about problems and the shape of solutions, but spend little time thinking about the human side of innovation – how to get users to adopt the technology they’re about to throw at them.

Pressure from the business means you have a limited window of opportunity to demonstrate a positive impact. No adoption means no measurable benefits. After all that time and effort, the whole thing just got killed – and the reputation of IT just took another hit.

Let’s say you do reach the “critical mass” point – where enough people have accepted an innovation to deliver the benefits that were stated in the business case.

Without the right support, users will quickly “drop off” and go back to old systems and patterns of behavior that they know will work. The business ends up where it started, with some expensive shelfware to boot.

Bad habit 3: “Fire and forget” innovations

Even the best technology in the world can’t be considered innovation if it’s never used. How many times have companies failed to turn innovative new technologies into major competitive advantages because end users or customers have inexplicably “failed” to use them?

The truth is: it’s not a failure of the end user community. It’s a failure on the part of IT to communicate the benefits, train users, provide support and get the innovation across the line in terms of the adoption needed to actually deliver the stated business value.

Deploying technology isn’t the finish line. Adopting a “build it and they will come” attitude simply results in disappointment down the line. It’s the most frustrating feeling – all that hard work put into creating something shiny and new being wasted.

6


Small, incremental improvements to existing systems and services mean end users will only need a little nudge: an email to the end user community to explain the who/what/when/where/why/how will often be enough to bridge the gap. The “why” is the most important component of the mix. It’s important for IT people to remember that what they do has an impact on the end user community.

What might seem like an imperceptibly small change to a developer may have a more profound impact on the way end users do their jobs every day. If they understand why a change is being made (and what the benefits are) they will be more motivated to change their own behavior to suit.

Without a proper explanation as to why you have “fixed” something that didn’t need fixing you can expect resistance, such as “but that’s the way we’ve always done it”. If you can explain what’s in it for them, there’s a better chance they will adopt the change.

More disruptive innovations that take end users out of their comfort zone need a more comprehensive program of communication and training, as well as new support capabilities (have the service desk been trained before the launch?).

If these necessary actions are not followed, the end community won’t be able to step up to a more productive level. End users need to be empowered with knowledge, understanding, motivation and support.

The training plan will need to consider the make-up of the end user community. There may be a mix of baby boomers, Generation X, Generation Y and Millennials. Each will have a different level of technical skill and “digital literacy”, so the training needs to accommodate for different foundations and learning speeds. If you simply hand over the technology, it will never fly.

Of course, familiarity is the better part of intuition and intuition is the better part of usability, so the design of the innovation from the end user’s perspective is a critical aspect which is often overlooked: too much focus on what it does and not how it does it. And once again we’re back to excessive technology focus as the root of all evil in IT.

Bad habit 3: “Fire and forget” innovations (Continued)

Breaking the habitNo communication, no training and no support means no adoption and no pay-off, so putting these three in place as part of the project plan is critical (from day one). They should also be costed and resourced at the business case stage; otherwise you’ll run out of budget and resources on the day of the launch – and without a timescale to set expectations the business is free to pull the plug at any time.

When budgets and resources are purely focused on building the technology, the critical post-launch stages will be neglected.

Innovation means change, and change means deliberately creating a gap between how things work today and how they will work tomorrow. For the technical people in IT, changing the technology is the easy part. Changing people’s behavior to bridge the gap is more difficult. You can change technology overnight, but old habits die hard.

The bigger the innovation, the more you will need to alter end user behavior to enable them to adopt this wonderful new innovation – and the more time and effort that should be dedicated to helping the innovation to “stick”. It’s wrong to assume that end user adoption of everything new (and possibly a bit scary) will happen by default.

7


When a company or department goes out on a limb to experiment with something new and it doesn’t work out, people ask “Who is to blame?” and “How can we stop this from happening again?” These questions can trigger a sequence of events that produce a destructive culture that stifles future ideas and innovations.

When people are called out for past failure it sends a clear message – failure has consequences. Word spreads fast across the corporate grapevine and fear quickly becomes a cultural phenomenon. When staff are publicly humiliated for failure, they’ll be afraid to put forward new ideas again.

Even worse, when staff are fired for failure it establishes the frightening level of personal risk that can be attached to putting a new idea forward. In this way, fear of punishment kills innovation at the root.

The impact of fear can be so widespread that other staff will be too scared to even support a new idea, lest their name be associated with a doomed project.

The second question “How can we stop this from happening again?” also has a profound impact on the ability to innovate. Over time, the processes and structures that are set up to reduce risk can become more and more cumbersome.

The number of hoops that people need to jump through to get the go-ahead for an idea becomes a major barrier to getting anything done. Excessive bureaucracy is the product of successive knee-jerk reactions to failure - and it’s very effective at killing off new ideas.

Governance processes, designed to negate risks by applying layers of review and authorization, eventually strangle the life out of innovation by preventing everything from passing through.

Fear and punishment together create a downward spiral to zero innovation. People will still have ideas, but they’ll remain unspoken. What is left is a system in which ideas can only ever come from the top (see Closed Group Innovation).

Bad habit 4: Fear and punishment

Doing something new naturally feels risky. Disruptive innovation - especially innovation that delivers a competitive edge - means stepping into the unknown.Disruptive innovation may involve experimentation, but not all experimentation leads to disruptive innovation.

As we have already mentioned, innovation requires change and change almost always involves risk. Things can go wrong. Time and money may be wasted. Trust and customers can be lost.

Some customers might even become vocal critics as a result. The stakes can be high, but excessive risk aversion – always focusing on (and expecting) the worst case scenario - means fear can take over.

Rejecting change becomes a default habit and fear of upsetting the status quo overshadows every opportunity. By doing nothing, it may seem like nothing is risked, but while your organization remains static the competition is moving forward. Nothing ventured, nothing gained.

8


The key to breaking the spiral of fear and punishment lies in being able to understand and accept a certain level of risk without shying away from it.

Risks are a part of the problem that you need to solve. By being methodical, most risks can be identified and mitigated to an acceptable level:

• What are the specific risks? (“We tried this before and it didn’t work” isn’t a specific risk)

• What does the best-case scenario look like?

• What’s the worst-case scenario? If everything that can go wrong does go wrong, where do we stand?

• How do the best-case and worst-case scenarios compare? Is the risk worth the potential gains?

• How can we negate the identified risks, and what are the costs associated with negating these risks?

• In hindsight, which risks did we fail to spot? How can we improve our risk-assessment process?

Bad habit 4: Fear and punishment (Continued)

Breaking the habitFor the most part, the solution against fear and punishment becomes obvious when you look at the problem.

A culture of fear is unhealthy and stifles not only innovation but communication in general. Failures are valuable learning experiences (if sometimes expensive), so it’s best to seek out the value that can be gleaned even when something goes wrong. Look at what happened, what went wrong and what lessons can be learned.

When something goes wrong, you have two choices: quit and look for somebody to blame, or think of it as a step forward; the first increment in the path towards success.

Learning from failure:

• Why did things go wrong?

• What can we learn from this?

• Do we really need to scrap everything we’ve done so far?

• How can we correct the situation and build on an imperfect solution?

• What can we do better next time so that we can move further faster?

9


Bad habit 5: Over-customized ITSM technology

Over-customization is a “technology trap” that many IT organizations find themselves in: changing or amending the source code of their ITSM solution to add features and functions that aren’t included in the “out-of-the-box” software.The problems associated with over-customization can start to occur as soon as you take your first step away from the vendor-supplied code-stream - because you are effectively severing the link between what you’ve got and what the vendor will support.

With a non-standard software set-up, you may find that you’re on your own when it comes to upgrades and support. Vendors are obliged to support their software, but when you customize your ITSM tool code, it’s no longer their software – it’s yours.

They have no obligation to support your code, nor provide an easy upgrade path that will work for your non-standard code-stream. No simple upgrade path means you’re more likely to get locked into your current version.

So, you get stuck with your now-outdated ITSM software - locked into a version that looks something like Frankenstein’s monster – and your inability to change it safely means you lose agility.

Combine this with potentially dozens of integrations that connect your ITSM software with other tools in the broader IT operations management arena and you can find yourself in a situation where your solution is far too fragile to touch without major disruptions to IT services and support.

When you part ways with the vendor’s code-stream, you also assume a much larger application management burden which takes resources away from IT operations. More time is spent managing your service management solution and less time is spent actually managing the services themselves. There’s an inevitable hit on Continual Service Improvement (CSI) and service innovation.

In essence, the benefits of customizing the life out of an ITSM solution are outweighed by the application management overheads.

Breaking the habitCustomizations that you make to your ITSM solution are unlikely to translate directly into real business differentiators, so you have to ask yourself “Do we really need this?”

It’s important to look at the bigger picture – the full lifecycle of your ITSM application – and weigh up the pros and cons of aiming to meet 100% of your requirements versus the increased application management overheads that they bring. Are the decisions you’re making today going to cause headaches tomorrow?

It’s also vital to keep control over who is doing what to your ITSM toolset. With a number of IT teams holding a stake in your ITSM solution, you need to make sure you don’t have different teams customizing the tool in different directions.

If you really do have unique operational requirements, look for solutions that provide flexibility the easy way – through in-system configurations that let you mold the tool around your needs without getting your hands dirty with coding.

10


The 5 Key Takeaways

3

4

1

2

5

Inspiration:

Ideas for innovation can come from anywhere in the business.

Execution: Good project portfolio management is the key to executing innovation.

Adoption: It’s not a real innovation until end users (or customers) are benefiting from it.

Confidence: A culture of fear will kill innovation.

Obsession: If you become too absorbed in your ITSM solution, capacity to innovate suffers.

11


AxiosFor more than 25 years, Axios Systems has been committed to innovation by providing rapid deployment of Service Management software. With an exclusive focus on Service Management, Axios is recognized as a world leader, by the leading analysts and their global client base.

Axios’s enterprise software, assyst, is purpose-built, designed to transform IT departments from technology-focused cost centers into profitable business-focused customer service teams. assyst adds tangible value to each client’s organization by building on the ITIL® framework to help solve their business challenges.

Axios is headquartered in the UK, with offices across Europe, the Americas, Middle East and Asia Pacific. For more information about Axios Systems, please visit us:

About the Author

www.axiossystems.com

@Axios_Systems

/axiossystems

Nigel Martin has more than 20 years of experience in global enterprise software. Nigel has written multiple research papers on organizational strategy and holds a doctorate in strategy and organizational brand development.

Nigel can be contacted at [email protected]

Dr. Nigel MartinVP of Global Marketing

how-to guide 5 bad habits that kill it innovation and how

Documents