Tag Archives: planning

The AI Playbook – 3 Key ITSM Plays to Make When Implementing AI

Share twitterlinkedinmail

AI is one of the fastest growing tech trends across all industries. 20% percent of business executives said their companies plan to implement AI across their enterprise in 2019, according to research from PricewaterhouseCoopers.

AI is the approach of using technologies like machine learning or bots to automate simple and repetitive tasks. The power of AI is clear. It allows for services to be delivered faster to the end user. It eases the burden of resource-strapped teams by automating simple tasks, allowing those teams to focus on larger or more strategic initiatives. It also keeps organizations competitive as new technology has created new consumer expectations that demand speed and agility.

While AI is making a splash for good reason, it is not a sole solution. Investing in AI won’t fix every issue in an organization. In fact, if implemented in the wrong environment, AI can slow down an organization and cause even more problems.

Before you jump and invest a chunk of your budget into an AI tool, you need to first review your ITSM environment. If you want to win at AI implementation, you need these plays in your playbook.

1. Clean up or create your processes

It’s simple: automation only works if you have a process to automate. If there’s no process, your AI tool has nothing to automate. AI will only master what it’s fed. You need to evaluate your current processes and workflows. Look for gaps where the process is slow due to human intervention, bandwidth issues or approval processes. Identify what is too convoluted, unclear or undocumented, too fluid or constantly shifting. This exercise will give you a clear view of what’s needed in your process and what is prime for automation.

When cleaning up your processes, you’ll want to get your entire team involved. You want buy-in from every member and you need to see the big picture of how each member contributes to a process. Meet with your team to map out your processes. Work with them to understand what each step requires and where automation can play a role.

2. Enable cross-department collaboration

AI will not work well in a siloed organization. Many AI tools facilitate integration with multiple backend systems and work across departments to deliver solutions. If your marketing team has a completely different tool, process and system than the sales team and those two departments are unable to come together to create shared processes and systems that deliver an end result, then AI won’t be able to make it better.

Every department must work together to effectively implement AI. They have to create shared processes, enable communication and clearly understand what is needed from each department to deliver a service, product, or result. Handoffs have to be smooth for automation to be able to step in and handle it.

Where in your organization is there confusion over how departments interact with one another? Are there communication issues that need to be addressed? What are the expectations and outputs of each department? It’s absolutely required that every team be on the same page when it comes to processes, approvals, goals, communications, and expectations.

IT leaders should find buy-in from other leaders to help teams integrate successfully. The goal for every leader should be a successful AI implementation that actually speeds up results. When each leader understands that this is only successful with inter-department collaboration, they will be more willing to encourage their teams to work with IT.

3. Identify and map value streams

Mapping value streams evaluates the tools, people and processes in the lifecycle of a service. Mapping value streams gives you two important things: visualization and metrics. Value stream mapping helps organizations visualize of how value and information flow through an organization. By doing so, organizations can see if any steps can be eliminated, refined, consolidated or most, importantly — automated. These metrics and data will help you be able to pinpoint exactly where AI can work, how it should work and what metrics you should use to measure it.

Mapping value streams will make it clear how AI could drive business value. This makes it easier to prioritize future implementations and integrate more AI solutions within your organization.

There’s one last important note for every IT leader to address.

It’s the elephant in the room, so to speak. Staff often feels threatened by AI so every IT leader must be able to express to their teams how AI can fuel their success. There should be no worry that staff will automate their way out of a job.

Instead, focus on the opportunities this can create. What projects are you unable to accomplish because your team is stuck doing manual, tedious, and mundane tasks? What successes are you held back from due to the limitations of manual work? Successful use of automation does require a shift in organizational culture. To create an atmosphere of acceptance, you need to focus on the potential for new projects, more exciting initiatives and a larger role in contributing to business goals.

Lastly, recognize that AI implementation is not one big project. Start small automating something of use and value. Pay attention to your metrics and adjust as the organization needs. Keeping an open mind and flexible approach to these implementations will be key to keeping them successful.

Share twitterlinkedinmail

Are Processes Killing Your Productivity?

Share twitterlinkedinmail

Every IT organization knows that good processes are critical to the success of a company. The right processes can improve efficiency and create an organized workflow. However,when taken to the extreme, processes can kill productivity and ruin your team’s morale.

Let’s take a step back and talk about processes and why they matter.

Processes are a defined sequence of tasks that keep the organization running smoothly. Processes provide organizations with a way to measure progress and productivity, which can help a team feel more efficient and accountable for their work. Standard processes create a consistency of work and provide a foundation for continuous improvement. Lastly, defined processes enable automation, which helps IT become more responsive to business demands.

So we can all agree that processes are a good thing in business. Except for they when they get in the way or go out of control. Many studies are showing that processes are beginning to hinder productivity across the globe.

In a study of U.S. and European companies, The Boston Consulting Group found that “over the past fifteen years, the amount of procedures, vertical layers, interface structures, coordination bodies, and decision approvals needed…has increased by anywhere from 50 percent to 350 percent.”

The same report found that in larger and more complicated organizations, managers “spend 40 percent of their time writing reports and 30 percent to 60 percent of their time coordinating  meetings.”

This does not leave much time to actually accomplish the work that needs to be done.

How can you tell if your process is working or if it is killing your productivity? There are a few ways you can test your processes.

1. Does the process accommodate all projects?

Processes cannot take a narrowly-defined, “one size fits all” approach. l. As an IT organization, your team is most likely handling a wide variety of projects. Your processes have to accommodate the variety of projects while at the same time providing needed consistency.   

Agility is just as important as having a standard process. Today, new technologies are coming to market at lightning fast speeds.Businesses are adopting technologies quickly and demanding that the IT department keep up with supporting these new technologies.

IT needs to be able to react quickly to these needs. If a process was not designed for agility or to accommodate the variablity found within a specific project, IT cannot react quickly. When you insist the process stay exactly the same for every project, you are asking your employees to try to sprint while attached to a ball and chain.

Too many organizations fall into the “process for process sake” mindset. They insist on maintaining every aspect of a process for every project, even when it doesn’t make sense.

If you find that your process has worked really well for some projects but did not work well for other projects, we recommend examining where the process stopped working. Take a look at the areas where flexibilty or a different approach is needed. Don’t lose sight of the end-goal for the process and the goals of the projects.

2. Are you focusing more on the process than the people?

No matter what innovative technology exists, it’s the people who make your business run, not the technology. Process should enable people to take advantage of the technology, not inhibit the use of technology.

When leaders focus too much on the process and ignore the needs of their team, the team doesn’t feel empowered to do their job effectively.

It’s not empowering when individuals are given more responsibility yet still have to obtain a large number of approvals and sign-offs to get anything done. This signals a lack of trust to your team.

Leaders need to start relying on their team’s expertise and experience just as much as they rely on the process. When you start to do this, you can often improve your processes because your team feels empowered to do so.

It’s critical to empower with action, not with permission. When your team is empowered to take action to get the job done, they feel a greater sense of pride in their work, are more invested in the project and more appreciated by their bosses.

When jobs depend on meeting metrics or process approvals, the creativity and innovation of teams suffer. The last thing you want is a team who can’t – or won’t – find ways to innovate and improve.

3. Are you relying on tools too much?

We’ve seen it time and time again. Organizations invest in a very pricey tool. They implement it one way and create a process around it and then they try to force that tool and process onto every problem that arises in the business.

Tools are fantastic but they are not problem solvers. People are problem solvers and your tools and processes should be built around the people and the problem that needs to be solved.

Processes built around tools are doomed to fail but processes built around problems and supported by employee action will always work.

4. Do you have process silos?

Organizations that are siloed will always struggle with processes. For example, what happens when IT has a process for onboarding a new employee and HR has their own process for onboarding and they are completely separate? Undoubtedly, it causes unnecessary extra work and possibly, some confusion for the new member who is being onboarded.

This is where cross-departmental communication and collaboration must come into play. Linking processes across departments and achieving buy-in from team members in both departments will avoid wasted time and energy.

Again, this will rely on your process being agile (see the first point) as you may need to adjust several of your processes to become cross-functional with other departments.

Work with other department leaders to understand their processes and determine how you can combine the two into cross-functional processes. Then clearly define and document these processes so that there is no confusion across teams.

5. Have you avoided process audits?

If you’ve learned anything from this article, we hope you’ve learned that processes are ever-evolving. They are constantly shifting to adapt to the growth of the organization and the specific project at hand.

So it’s necessary to perform regular process audits to ensure your processes are working to the best of their ability and improving the productivity output of your team.

How do you perform a process audit? It’s best to start by looking for any drops in productivity during the process or where output slows down. Additionally, monitor for signs of unhappy teams. Do you see resistance from the team at any certain stage?

Look at your processes and determine if any piece of it does not add value. If you’re unsure, speak with your team on this. Since they are using the processes, they will know what are the most valuable and impactful parts of it.

Let’s be clear on one thing: I am an extremely big fan of having documented, well-defined processes in your organization.

But I want to encourage you as the business leader to always be monitoring processes and keeping your eyes on the end goal and the people implementing and using the processes.

Focus on people and improving communication and innovation so that you can solve business problems. The process will fit naturally and be more powerful when they are viewed as the means to a goal and not the goal itself.

Share twitterlinkedinmail

Fund Services, not Projects

Share twitterlinkedinmail

Businesses are demanding more speed, agility, and responsiveness from their IT organizations. The work that IT does must provide the means for business to quickly realize value.

What does this mean for IT? Roy Atkinson sums it up nicely when he says that IT “must go faster”.

In response, many IT organizations are adopting Agile methodologies to help them “go faster”. But soon after the Agile decision, many IT organizations soon encounter one of the biggest challenges of all.

“How do we pay for this?”

A long-standing challenge that many IT organizations adopting Agile methodologies often encounter is the drive for agility using Agile conflicts with traditional budgeting and project cost management and accounting.[1]

Surely someone has figured this out.

Turns out that someone has…. Well, almost.

Problem solved… well, not quite

As I was thinking about this challenge, I started to do some research. I found an article titled “Lean Budgets” which does go a long way toward resolving the challenge.   The article proposed a set of practices that fund and empower value streams rather than projects, while still maintaining financial controls, by establishing portfolios of value streams. This approach seems to address many of the challenges faced by IT organizations adopting Agile approaches.

But I think the problem is not quite solved.

If we only focus on application development and do not consider the total cost of ownership of a service, we’re not providing the full story to the accounting folks. And accounting folks do not like surprises.

If we make funding decisions based only on the application development perspective, isn’t that like buying a new car, loaded with lots of features, but not considering the other costs involved with owning the car? To really understand the total cost of ownership of the car, we also need to consider fuel cost, taxes, licensing, upkeep, and so on. Only then can (should) we make a judgement regarding the value of purchasing (or investing) in that new car.

To bring it back to IT terms, while application development is an important aspect of designing and instantiating a service, it does not represent the entirety of service provision – things like the underpinning infrastructure, on-going maintenance, vendor agreements, and consumer support. Application development is only one part of the cost.

The key is that we have to look at the complete IT value stream, not just the software development component of that value stream. In other words, we need to define services that reflect the complete IT value stream.

A value stream map paints the “big picture”

The key to getting this holistic view is to map the value stream – the complete value stream.

A value stream represents the sequence of activities required to design, produce, and deliver a good or service to a customer.[2] The value stream includes the dual flows of material and information.[3] Application development is just a portion of an IT value stream. Shouldn’t the IT value stream also depict how underpinning infrastructure enables information flow? How external vendors are involved? How consumer interactions are managed?

In my opinion, the short answer is ‘yes’. Value stream mapping, when applied to the IT organization, is a great way to fully understand how the outcomes provided by IT enable business value. In other words, IT services.

Enter the service portfolio

Can a true service portfolio help?

By defining a service in terms of the complete IT value stream provides a holistic view on which real value can then be evaluated. Looking at these IT value streams within a service portfolio provides an organization with a much different perspective and more complete way to evaluate value.

And as Mark Schwartz states in his book “The Art of Business Value”[4], value is “whatever the business decides it is.”

It is not for IT to decide what is and is not valuable to a business. But it is for IT to present a complete picture of what it does – application development, end-user support, maintenance and support, and more – to contribute to business outcomes. This is why defining services in terms of the complete IT value stream is important.

But there’s more that goes into a making a service portfolio even better. A good service portfolio can be enhanced by underpinning it with things like:

  • Customer portfolio – Who is buying what services? What revenue is resulting from provisioning of the service?
  • Supplier and Contracts Portfolio – What vendors are involved in the delivery of what services? How much is the organization spending on vendor support?
  • Application portfolio – What applications support what services?

Providing this information in a service portfolio facilitates informed business decisions about investments in technology by providing the holistic view of services.

Then organizations can fund services, not projects. Fund services, not just application development.

The best of both worlds?

Make no mistake – Agile can provide many benefits for both the IT organization and the business it serves. But by defining the service portfolio and funding services and not projects, organizations can realize the best of both worlds.

This approach allows the IT organization to exploit the benefits of an Agile approach:

  • Smaller and more manageable iterations of work
  • Value delivery more quickly and more frequently
  • The product owner, representing the business, provides guidance regarding desired features and business direction.

The IT organization also realizes the benefits of a service portfolio. A service portfolio:

  • Clearly describes how IT underpins business value
  • Enhances the perception and reputation of the IT organization being a good business partner
  • Enables the business to make informed decisions about IT investment.

The business also benefits:

  • A service portfolio provides business colleagues with a holistic view of IT services
  • Investment decisions can be made based on the ‘complete picture’ of an IT service
  • Based upon service investments, the IT organization can use the best approach to meet business requirements – Agile or otherwise.

Defining a service portfolio is just the way that a business can have the best of both worlds – agility and control.

Need to modernize your service management environment and incorporate emerging practices like Lean and Agile, while still leveraging your existing investments?  With our Next Generation ITSM consulting service, Tedder Consulting can help you get the best of both worlds – contact us today!

For more pragmatic advice and service management insight, click here to subscribe to my newsletter!

Picture credit: Pixabay

[1] “Lean Budgets”, www.scaledagileframework.com retrieved 1/28/2018.

[2] Martin, Karen and Mike Osterling. “Value Stream Mapping”, McGraw Hill Education. 2014. New York.

[3] Ibid.

[4] Schwartz, Mark. “The Art of Business Value”, IT Revolution Press. 2016. Portland, OR.

Share twitterlinkedinmail