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

The mixed message to IT (and how to escape the mixing bowl)

Share twitterlinkedinmail

Do you feel you and your IT organization are living in a mixing bowl?

IT is under incredible pressure to become nimbler and more responsive to business needs. Shadow IT, “as-a-Service” solutions, and requests for new applications are continually appearing from seemingly everywhere to address perceived must-be-done-now business requirements.

On the other hand, if the IT organization fails to take the necessary steps to protect an enterprise’s data, or ensure appropriate control of its systems to comply with laws and regulations, the business may instantly become a headline in social media and internet news outlets.

The line between business and IT has been blurred beyond recognition – in fact, there is no line. Businesses are completely reliant on the use of technology to conduct business. As a result, IT must provide services that are stable, reliable, consistent, and secure – which often puts IT at odds with business requirements for agility and responsiveness.

Without a well-defined strategy for achieving the vision and goals of the business, IT seemingly jumps through hoops in an effort to meet the conflicting requirements between stability and responsiveness.

Without appropriately defined governance, there is no mechanism for finding and following a balanced approach between responsiveness and stability.

Sound familiar? If so, you are living in the mixing bowl.

Is your IT organization in the mixing bowl?

Here are some symptoms of IT organizations finding themselves in the business mixing bowl.

  • Bypassed processes – Because following processes feels rigid or bureaucratic, exceptions are made depending on the person or group within the organization making demands of IT.
  • Ignored testing – Because there seemingly is no time to test potential solutions – and testing is in the way of getting to market – testing is cursory at best and totally ignored at worse.
  • Deferred decisions – Because things can’t wait, decisions affecting plans or longer term needs are deferred.
  • Hidden problems – Because the IT organization is under pressure, problems are hidden rather than openly addressed and resolved.
  • Solution first – Because no one is willing to take the time to fully define the business need, tools and systems are purchased and implemented in attempts to get to market quickly. Unfortunately, this approach always results in “be back” work (to address overlooked or ignored issues) which further adds to the mixing bowl problem.
  • No collaboration – Because people fear losing control of driving their solution to market, there is no involvement from others within the company.
  • Constant “fire-fighting” – Because governance and strategy are lacking, IT becomes really good at band-aiding issues, but never good at real solutions.

What is the result of being in the mixing bowl? Lots of IT spend, but little real value in return.

Can ITSM help?

Yes.  And no.

Yes, ITSM *can* help *if* applied appropriately. Unfortunately, many organizations have approached ITSM implementation as the hammer for what is perceived to be a world of nails.

But just as it takes more than a hammer and nails to build a house, the ITSM professional may have to use different tools from multiple frameworks and methodologies to find that balance between nimbleness and stability. ITIL®[1] is a great process-oriented framework that can be used in the delivery of services. Apply Lean concepts to remove waste. Add in DevOps and breakdown the silos between the development and operations organizations. Leverage Agile to get work done in bite-sized chunks that deliver the most important aspects of business needs first.

Think of this approach as the difference between the novice and the craftsman. While the novice may be able to understand and use a tool, the craftsman knows how to apply the right tool in the right way to get the outcomes that are required.

Can ITSM help? No, ITSM cannot help – even the craftsman – without planning and communication. This means you’ve first got to get out of the mixing bowl.

Escape the mixing bowl

Getting out of the mixing bowl is not easy, but until you do, the world of IT as you know it will continue to be one of fire-fighting and endless jumping through hoops. How can IT get out of the mixing bowl? Good communication and planning are key.

  • Seek first to understand, not to reply – Take the time to understand the problem before trying to apply a solution. Many times business and IT get sideways with each other because both sides are too eager to jump to solution. Set the example – first understand.
  • Learn the business – IT has to go the extra-mile, reach out to business colleagues and learn the business of the business. The business is always looking ahead to identify the next great opportunity. To be successful, not only does IT have to support what is running the business today, but also be involved in emerging business needs and opportunities. In order to be part of the discussion about that next opportunity, IT must understand the business of the business – not just how technology can be used.
  • Don’t defend the status quo – There is a reason why the business is looking for other solutions. Once you understand the drivers and issues from the business perspective, look for ways to leverage existing solutions. It may not be obvious that an existing solution can fit the need – in other words, business colleagues may not know what they don’t know. At the same time, look for opportunities to innovate – don’t leave your business with the impression that it’s “status quo or no”.
  • Lose the tech-talk – Frankly, business colleagues do not care about gigabytes and megaflops. Up your communication game and use analogies and business language, not tech-talk, to help with planning and communications.

Want more pragmatic insight to service management issues? Please  subscribe to my newsletter!

[1] ITIL® is a registered trademark of AXELOS Limited.

Image credit – Thomas M. Perkins

Share twitterlinkedinmail

Don’t point that finger at me!

Share twitterlinkedinmail

There are a few life-lessons I’ve learned that I can happily attribute to my mother.  I’m sure many of you have some life-lessons and words of wisdom that you can chalk up to your mother as well.  Nuggets like “you don’t get a second chance to make a first impression”.  Indeed!  How about “to make a great omelet, you have to break a few eggs “?  Spot-on.

Here’s one that applies to ITSM.  “Be careful when you point a finger at someone….there are always three fingers pointing back at you.” Well, now…there’s something to think about.

Over the years, I’ve gotten into more than a few conversations about how to make ITSM “stick”.   I don’t know what it is about us IT types….we often seem to think in absolute terms.   It’s either “on” or “off”.  It’s either “black” or “white”….there doesn’t seem to be room for the “gray”.

And while I fully agree that successful ITSM implementations feature clearly defined and “lived” roles and responsibilities, I sometimes run into a perception that ITSM is about “penalty” or “punishment”.    I’ve heard things like “they didn’t follow the process”.  Who is “they”?  Don’t we all work for the same organization?  Isn’t “they” really “us”?   Or “we met the terms of our SLA”.  Sure “we” did.  But when was the last time “we” did a Service Level Review with the customer to ensure that the terms of the SLA were still relevant?  Did “we” develop SLAs that actually have customer signatures, or did “we” document a set of objectives that were decided and agreed upon within IT?  Besides, SLAs are not sticks that are to be used to hit customers over their collective heads, nor are SLAs intended to sit on shelves collecting dust, referenced only when it’s convenient for us.

ITSM is not supposed to be painful nor is ITSM about punishment or blame.  ITSM is about consistency and repeatability, driving effectiveness and efficiency.  Good ITSM is a result of good planning and good execution of that good plan.  ITSM is about continual improvement.  ITSM is about people and being inclusive of people, not segregating people.  It’s not about a number of ITSM-certified folks deciding what’s best for other IT people.  It’s not about just IT people thinking about what is best for the business.  ITSM is about collaboration between the business and IT and moving forward in a planned and agreed way, with shared goals, working to ensure optimal delivery and support of services with acceptable levels of risk at the best cost.

So if and when ITSM isn’t working as expected, don’t point fingers.   I’d like to suggest that you ask the following questions to get to ‘why’:

  • Have you educated your organization about the goals, objectives, and business benefits of the ITSM implementation?

How will ITSM improve what the business does?  How will it improve working both with IT and within IT?  What does “success” look like?  Understanding and educating the organization about the goals of the ITSM implementation, how the implementation of ITSM will enable outcomes needed by the organization, and how ITSM will contribute to business success will help everyone understand why we’re doing ITSM…which will help ITSM ‘stick’.

  • Have you documented your processes? Is your documentation ‘consumable’?

If you’ve not documented your processes, quite frankly, they don’t exist.  No one can say what you were thinking when you designed the process, but put it in writing and everyone can read, discuss, and internalize the process.  Also, be sure that your documentation is ‘consumable’.  What I mean by that is documentation should be easy to read and follow a consistent approach to documentation so the reader knows what to expect when reading the document.  Personally, I’m a big fan of concise, focused documentation – for example, a Policy document should talk just about the policy, rationale, benefits and consequences.  It shouldn’t discuss procedures, roles, etc.; those are subjects for a different document.  Likewise, when I read the procedure document, I can quickly read what needs to be done and how to do it.   I like bite-sized documentation chunks that I can quickly read, understand, and apply.

  • Have you clearly defined roles and responsibilities? Do process actors understand their roles and responsibilities?

People generally perform better when they understand what is expected of them.  People are critical for successful processes – processes will not work without people.  Executing formally designed and on-going training, communication and awareness plans are critical for winning the hearts and minds of those you depend upon for a successful process – the people that interact with it.

  • Have you made your processes effective, yet as simple as possible?

ITSM is not about who can devise the most complex or intricate processes.  While there may be situations that require a high degree of complexity, generally speaking, simpler is better.  The simpler the process, the easier the process will be do it.  The easier the process is to do, the higher the probability for success.

  • Have you clearly defined and published meaningful measures for your ITSM implementation? Do you celebrate those measurable successes? Do you take and publicize actions when those measures indicate opportunity for improvement?

Without measures, ITSM programs will become invisible quickly.  Having and publicizing measures lets everyone know how ITSM is going, and the visibility of those measures will also help make it “stick”.   Having measures that are relevant and meaningful to the business are even better.  Yes, it is important to understand how many Incidents you had this month.  However, it’s more meaningful to the business if your measures illustrate that because of effective Incident Management, the business was able to meet or exceed its widget production goal for the seventh consecutive month!

Remember, when it comes to an ITSM implementation within an organization, we’re all on the same team.  Finger-pointing won’t help.  Getting to the ‘why’ will help make ITSM ‘stick’.

Has your ITSM implementation not delivered what you were hoping for?  Let Tedder Consulting help with workshops or consulting services that will stop the finger-pointing and deliver success.

For more service management advice and opinion, please click here to subscribe to my newsletter!

Share twitterlinkedinmail

How to have Fun in your ITSM Implementation

Share twitterlinkedinmail

ImageThe formula for having fun in your ITSM implementation to me is really simple.  You need to (wait for it)…”plan”.

“Plan”.  Yes, it’s a four-letter word, and it’s a good four-letter word, but the lack of planning is often a primary cause of failure in an ITSM implementation.  Too many times, ITSM implementations look something like this:

  1. “Let’s do ITSM!”
  2. Assemble a team—usually folks that aren’t doing anything else at the time
  3. Buy some tools and software (“we’re going to need them anyway”)
  4. “Let’s squeeze in some training”—so one or two people go away for three days and get a certification
  5. “Okay, now let’s configure the tool”
  6. Roll the new tools and software out to a target IT group along with a few slides that talk about how to use the tool
  7. Put out a couple of fires that resulted from misconfiguration in the tool
  8. Coerce other IT groups to use the tool; over time, ignore the ones that don’t use the tool
  9. After a few months, start to wonder why things aren’t working so well OR (better yet) move on – quickly—to the next project

Maybe my illustration above is a bit extreme, but many of you reading this may recognize these attributes in your current (and perhaps struggling) ITSM implementation.   I will tell you that while a plan will not necessarily make ITSM implementation a breeze, it will help smooth the path.   But overlook the critical step of planning and you’ll be looking for that next project (or job) sooner than you think.

So how do you develop a good ITSM plan?  A Google search on “how to plan” will return thousands of results, but I think good ITSM planning boils down to a very simple formula:  “Plan your work, then work your plan”.

Plan your work:

  • Define clear goals and objectives for ITSM.
  • Ensure the goals and objectives are aligned to business vision, goals and objectives
    • This helps put ITSM in business context and helps you guard against “geek-speak”.  While you will likely (and should!) have a few technical objectives of the ITSM implementation, the better you can tie ITSM to business goals and objectives, they better ITSM will go.
  • Define the strategy for achieving goals and objectives
    • “Strategy” is often confused with and misused as “vision and goals”.  These two terms do not mean the same thing.  “Strategy” is how to achieve “vision and goals”, and provides the roadmap for getting there. Define and document your strategy.
  • Define and identify roles (including the often overlooked “sponsor” role), capabilities, resources, measures, and the time needed for achieving the goals and objectives.
  • Get buy-in and visible support from your sponsor.

Work your plan:

  • Execute your strategy.  Do what you said you were going to do.
  • Communicate successes, as well as setbacks (you will have some) and what you’re doing to remediate those setbacks, on a regular, periodic basis.
  • Keep your sponsor engaged.  You need to enable your sponsor so that she can knock down barriers and help with unforeseen events to keep you on target.
  • Celebrate successes, whether that be the achievement of milestones, hitting those measures you defined in your plan, or the identification of new learnings.
  • Periodically review your plan and adjust strategy as needed without losing sight of the goal.  Remember, the “goal” is the target.  The “plan” is how you’re going to get there, not why you’re doing it.  Sometimes folks become so locked into running the plan that they fail to notice that they’re going off-course toward achieving goals.

The best part of planning for me?  Watching the plan work and achieving those goals and objectives defined within the plan.    How fun is that?

Click here to subscribe to my newsletter!

Share twitterlinkedinmail