Tag Archives: people

Damn, I Made a Mistake

Share twitterlinkedinmail

 

Buckle up, friends, because this is the one where I share some truths.

I’ve learned many things in my years as a business owner and consultant but a few months ago, I had one of the biggest lightbulb moments of my career.

I made a huge mistake and it was costing me business.

I’ll avoid getting into the nitty-gritty of this mistake but it simply came down to this: I wasn’t listening to my audience and I was basing many of my offers and marketing choices on assumptions about my clients, rather than hard facts gathered by listening to them.

I think for many leaders and consultants, you get to a point in your career where you feel that you’ve seen it all. You learn to trust your instincts and in many ways, this is a good thing. But there comes a point where you start listening to your gut instincts over the voices of those around you. This is where you can start to cost yourself. If you work for yourself, you could be costing yourself business or if you’re part of an organization, you could lose the loyalty of your team and your rightful seat at the table with the C-Suite.

I believe as leaders it’s important to self-reflect on a consistent basis, even when you are moving quickly and chasing big goals. As I reflect on my missteps, I wanted to share three key points that helped me correct my mistakes and will hopefully help you avoid them!

Listen to others

Whether you’re like me and are a consultant, or you’re trying to manage a team and please a C-Suite, listening is a core component of leadership. However, listening is not always easy. You will hear things you don’t want to hear and think, “Well they’re wrong and I’m right so I’m not going to listen to their views.”

Differing views and conflicting opinions are part of business. Modern leaders want the best for their organizations and it’s normal to believe your views are the best. But the next time you hear a conflicting viewpoint and your urge is to “Shutdown and ignore,” I urge you to stop and ask a simple question in return: “Interesting viewpoint. I’d love to dig in on why you feel this way.”

The goal is not to shut down, it’s not to agree and it’s not to give up. It’s simply to dig in for more information. With an open mind and the right questions, you are creating space to find the solution.

Question your assumptions

While you’re working to understand why your team and colleagues feel a certain way, it pays to do the same for your ideas and viewpoints as well.

Questioning your assumptions is a powerplay for every leader.

The IT world changes at lightning-fast speeds. The trends of 6 months ago are now commonplace and the hot new technology of last year has already started being replaced.

In an industry where everything is evolving, your assumptions and beliefs should too. When was the last time you tested an age-old assumption or asked a clarifying question about a process, service or piece of technology to determine if it’s still working?

When you question your assumption, you are creating opportunities for continuous improvement, a hallmark of the modern IT organization.

Commit to learning

Leaders are always learning. This is probably not news to you but I challenge you to view this last point as more than keeping up on the latest trends or reading the latest news every morning. Instead, I encourage you to continue learning about your organization, the end users and your team.

Much like I had to learn more about my clients and their current needs, IT leaders should learn about the other departments, their end users, and, of course, the needs and desires of their own internal IT team just as much as they need to understand the latest piece of software.

This is also a fantastic area for you to encourage your deputies and other members of your team to practice, as well. Every member of your team can learn more about their end users and it will elevate the overall IT organization.

Part of the objectives of a modern IT department is to make an easier, faster and more streamlined experience for users. When was the last time you learned about the needs of a user from the actual user (and not from data or assumptions)?

Leaders make more mistakes than many of us realize. Course correcting along the way is part of leadership and success. We have a little less than half of 2019 left in front of us and this is a fantastic opportunity to look back on this year and ask yourself where you’re not listening, what assumptions your making, and how much you’ve learned so far this year.

I can tell you from experience that while it’s a humbling practice, the outcome of it can lead to more opportunities than you could have experienced otherwise.

Want more? I share more pragmatic leadership advice in my bi-monthly newsletter. Sign up here.

Share twitterlinkedinmail

Enterprise Service Management or Enterprise Silo Management?

Share twitterlinkedinmail

Kelly orders chocolates through her favorite confectioner’s digital storefront from the comfort of her living room. Kelly makes her selection, enters her credit card and shipping information, and presses the “order now” button. Within seconds, she receives an on-screen message from the confectioner, thanking her for her order, and informing her that she’ll have her chocolates the next day.

At the confectioner, Kelly’s request is first processed by the Order Entry Department, who confirms her information and charges the sale to her credit card. Order Entry then creates a sales order, which is sent to the Fulfillment Department. Fulfillment selects the chocolates from inventory and updates the inventory management system with the change. Fulfillment then packages Kelly’s selections and sends the package to the Shipping Department for overnight delivery.

All of this behind-the-scenes activity happened without any involvement from Kelly – other than her single interaction to order the chocolates.

Are your customers enjoying a differentiated experience interacting with your company’s digital storefront?

Are the customer’s interactions seamless and friction-free?

Do materials and information flow smoothly through the organization?

If you’re not able to answer ‘yes’ to the above questions, then you have some compelling reasons to implement enterprise service management (ESM).

Some Popular Approaches to ESM

Many ESM approaches consist of extending the use of the IT service management tool into other areas of an organization, such as Facilities or Human Resources. This is a popular approach that often results in cost optimization of the IT service management tool by using that tool outside of the IT organization.

In a lot of ways, this is a reasonable thing to do. Whether it is a work order being completed by the facilities organization, or human resources on-boarding a new employee, using a tool that facilitates a consistent, repeatable approach to information capture and managing workflow just makes sense.

Another popular approach is establishing an enterprise service desk. Like an IT service desk, the enterprise service desk becomes a single-point of contact for internal employees to receive assistance with any request or issue. Employees benefit from having only a single point of contact for any organizational need or issue. The organization benefits by delivering a centralized approach for managing such contacts, rather than having each department having to individually staff such functions.

Implementing a self-service portal is also a popular approach for ESM. Employees can use a portal to find information or make requests without having to contact anyone. Issues such as requesting a replacement for a burned-out light bulb or updating voluntary benefits can be conveniently managed from an employee’s workplace.

But are any of these approaches really “enterprise service management”? Or are these examples of enterprise silo management?

What You’re Doing is Enterprise Silo Management

Extending the ITSM tool to other areas of the organization may improve the ROI of the tool. Establishing enterprise service desks may help centralize management of internal requests and issues. Implementing enterprise self-service portals can result in time savings for employees. It may even result in optimized departmental processes and workflows.

But if the goal of your ESM initiative is to only extend the use of IT’s service management tool into non-IT areas of the organization, what you’re doing is Enterprise Silo Management. You’re enabling (encouraging?) your organization to continue working as a collection of siloed departments.

While I would agree that optimizing departmental processes and workflows is a good thing to do, keep in mind that departmental optimization will deliver benefit…to only that department. It’s like speeding up one part of a conveyor belt but ignoring the big stack of boxes on either end. In fact, it’s really not speeding anything up – it is only exacerbating the symptoms of an organization whose interdepartmental workflows are not well integrated.

This is where these so-called approaches to ESM fall short. These approaches don’t enable or deliver a cross-departmental flow of information and work. There’s no end-to-end view of enterprise value streams. Requests or issues that (will) come up within the enterprise still requires the consumer (employee) to know what they need and what organization fulfills that need before they interact with the portal.

By following these approaches, your business will never realize the value of enterprise service management.

Why Your business Needs Enterprise Service Management

Organizations operating within a silo mentality, in which the departments within the organization are poorly connected with (or even isolated from) other parts of the organization, cannot react or respond as quickly as needed to changes in market spaces or business.

Think about it. There is no single part of an organization that can exist in complete independence from the other parts of the organization. The best business value is created when all parts of the business are contributing and collaborating to deliver value in the most effective and efficient way.

And in the digital age, having the ability to quickly shift and react to changes in market spaces is critical for business success.

This is why your business needs ESM – Enterprise Service Management.

Good ESM:

  • Provides business decision support – Good ESM provides transparency into how work is done within the organization. Decisions become data-driven, based on objectives measures captured as part of enterprise value streams.
  • Enables organizational agility – Well defined, interdepartmental workflows enable organizational agility because there is clarity and shared understanding regarding workflows. This helps leaders understand where to pivot if needed. Good ESM results in improved cohesiveness and collaboration within the organization and aligns activities toward shared organizational goals, not on departmental objectives.
  • Improves organizational understanding of the business – Individual departments not only understand their workflows and processes, but also how information, work, and value flow across the organization. There is a greater awareness of the interdependencies between the various departments within the organization.
  • Enables an enhanced customer experience – Good ESM removes the internal friction that gets in the way of a good customer experience.

Moving to Enterprise Service Management

Here are some tips to help you move from Enterprise Silo Management to Enterprise Service Management.

1. Strong leadership is required 
To have success with ESM, the focus must shift from achieving departmental objectives to enterprise goals. Silo mentality must be eliminated from the organization.

2. Teach employees the business of the business 
Many employees today are unaware of how the business operates outside of their own area or department. Having a good understanding of how the business does business helps with ESM implementation and enables improved employee productivity.

3. Map the enterprise value streams
No single part of an organization is independent of the rest of the organization; it takes all parts of an organization to deliver value to its customers.  Mapping value streams at the enterprise levels helps the organization visualize how work and value flows through the organization and to the customer.

4. Define or lean out processes
For each value stream, form a cross-departmental team to define any needed supporting processes. If processes are defined, review those processes to ensure that they are as lean and waste-free as possible.

5. Iterate
Don’t try to instantiate all your enterprise value streams within your service management tool at the same time. Rather, start with a single enterprise value stream, capture any learnings, and then apply those learning to the next value stream-to-tool implementation. (By the way, this approach should be the “new normal” for maintaining your ESM implementation.)

So, should organizations optimize at the departmental level or at the enterprise level? The fact is that to be successful in the digital age, organizations must do both. Doing one without the other only results in internal friction and waste.

Following the above tips will get you on the right path for good ESM that also results in optimized departmental and enterprise work streams.

Share twitterlinkedinmail

The Number One Reason IT Is Unappreciated (and how to change it)

Share twitterlinkedinmail

There’s a quiet mumbling that occurs in every IT organization across the world. You can only hear if you listen very carefully. It’s the quiet sounds of IT organizations feeling underappreciated.

The C-Suite and many parts of the organization don’t fully understand what IT does so they pile on projects and hold off on praise. The IT team members get frustrated with their workloads and the thankless nature of the job. If you’re an IT leader, then you have seen this from both sides.

You know that most of the organization sees IT only as a support team and IT feels like they are an order taker. When other departments have unrealistic needs or timelines and IT pushes back, they are seen as resisters who are blocking productivity.

The truth is, many people in the organization don’t understand the complexities of IT and IT team members are so overwhelmed with work that they can’t take the time to explain to other departments how they are contributing to the business.

There is one person in every organization who can help IT feel more appreciated: the IT leader.

IT Is unappreciated because IT can’t clearly communicate its wins and how those wins contribute to the business. The responsibility of communicating these wins falls onto the IT leader.

Let’s take a look at what every IT leader can do to help their team feel more appreciated.

1. Claiming IT wins

Most organizations don’t pay any attention to the IT department until something is falling apart. But IT leaders can help spotlight their teams by sharing wins and updates from their department.

This can be easily done with a regular IT update, either monthly or weekly. Send this to the C-suite or to other leaders in the organization. You may stop me right there and say “Well Doug, I already do that and no one seems to care.” So I’m going to ask you how you framed these wins?

Because, unfortunately, it’s not enough to just share your team’s wins. Unlike the sales department, IT wins don’t always directly relate to revenue. The C-Suite may not understand how improving service desk response times connects to business goals.

As the IT leader, you must be willing to learn to connect each of your team’s wins to the organization’s business goals.

Most people don’t really care what you do unless it affects them. This isn’t just in business. This applies to everything in life. Think of it this way. If you live in Indiana, you may not care about a thunderstorm in Miami. But you will care if you have a flight booked to Miami and that thunderstorm is delaying your vacation.

As the leader, you need to show your organization how that thunderstorm in Miami is affecting someone in Indiana.

How does IT impact the rest of the organization’s ability to do their jobs and hit their goals? This is the question you must regularly ask yourself when you are reviewing projects and strategies.

When you view your team’s wins or accomplishments through the scope of the rest of the organization, you can better communicate them to others so that they care about those wins. This brings me to our next point.

2. Speak business language

In this digital day and age, it is required for IT projects to link to business outcomes and value. Most IT leaders use technology terms that business leaders don’t understand and really, don’t care about. IT often communicates backward. IT loves technology and features and think others do as well. But most others in the organization will only care about the benefits and outcomes of using the technology. The function of technology is not the value. The features are not the outcomes. It’s necessary to focus on the outcomes of every project.

Be willing to look at the data of projects from start to finish. Many organizations justify IT projects by citing anticipated revenue increases or advances in customer satisfaction but many are unable to track these successes after the project is completed. Work with other departments to understand how your IT work contributed to their win.

As an exercise, we recommend dividing a piece of paper into three columns. Label the columns features, benefits and outcomes. Then under each project, service or product, break down them down into each category. You’ll be able to develop value-driven messaging when you view your projects through this lens.

3. Get over the fear of self-promotion

Many leaders struggle with self-promotion but it runs rampant in IT. There is no easy way to release this fear other than to recognize that if you cannot clearly explain how your team is winning, no one else will be able to either.

As a leader, when you self-promote, you are doing so for the benefit of your team members. It’s not bragging or selfish. It’s improving your department and it can improve the entire organization.

When your organization works well. the entire organization runs better. Not only that but when you claim your wins, the organization feels more confident in their own wins and can own them as well. 

If promoting your department truly isn’t for you, there is another option. Many organizations have started hiring IT communications specialists to help market the IT department internally. If you don’t have the budget for it, you may want to enlist help from your marketing department to learn how to better market IT.

4. Be visible

A frequent mistake made by IT leaders is they feel they are too busy to participate in interdepartmental meetings.

While it is tempting to choose to do the work over promoting the work, no one will ever know what you and your team is doing if you are too busy to attend the meetings. No one will know what you’re doing if you’re too busy to attend meetings.

If you want a seat at the table, it’s important to act like you want a seat at the table. Of course, you may point out that you don’t get invited to the high-level meetings. Well, if they don’t give you a seat at the table, you can make one.

Connect with other department leads, form alliances when necessary and support other departments in their goals. These other leaders can help act as a champion for IT when you are unavailable.

If you absolutely cannot be visible and have no choice but to remain in your own department, I recommend being active on emails and quick to respond to voicemails.

5. Training your team to do the same

Finally, it’s important that every IT leader teaches their team to communicate their wins and share the business value of IT. Your team can act as IT department evangelists if you empower them to repeat these steps at their level.

When you talk about your services to your team, identify them in terms of business value and outcomes. Encourage your team to share their wins in your team meetings and ask them about the business value of their wins so that they have a better understanding of how to explain their projects.

How can good SM help IT become appreciated?

1. Defining IT services in terms of business value and outcomes. 

Define and describe the business value and results that your business colleagues get from doing their IT business with you. Remember that PCs and smartphones can be obtained anywhere so you need a case for why they need to go through the IT organization. Create a service portfolio that establishes an understanding of how the business is using technology solutions from IT and how that technology contributes to the business outcome

2. Implementing processes that facilitate, not control, getting work done.

Don’t allow your process to kill your productivity. Too many processes are designed and implemented with “control” in mind. Good process design should enable, not constrain, getting things done. Work with your team to evaluate your processes and measure if they are the most effective way to get the work done.

3. Formalize the business relationship management approach.

Business relationship management focuses on the relationship between the IT organization and the business it serves, as well as the level of satisfaction with IT. Proactively building positive, business-like relationship with key stakeholders helps change the perception of IT from “order taker” to “business differentiator”. 

As much as we don’t want to admit it, there’s politics at play in every organization. IT leaders can hide behind their computers and stay overwhelmed or they can learn to step out and own their team’s wins and communicate their teams’ value.

Share twitterlinkedinmail

What is DevOps?

Share twitterlinkedinmail

“What is DevOps?”

Taken at face value, the question may seem a bit rhetorical, but allow me to explain.

There is no single definition of “DevOps”. If you ask five people “What is DevOps?”, you’ll likely get five different answers.

Need some examples?

Here’s how Gartner has defined DevOps[1]: “A change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach.  DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams.  DevOps implementations utilize technology – especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”

 Take a look at “The DevOps Handbook[2] by Gene Kim and others.  It states that DevOps is “…the outcome of applying the most trusted principles from the domain of physical manufacturing and leadership to the IT value stream.  DevOps relies on bodies of knowledge from Lean, Theory of Constraints, the Toyota Production System, resilience engineering, learning organizations, safety culture, human factors, and many others…the result is world-class quality, reliability, stability, and security at ever lower cost and effort; and accelerated flow and reliability throughout the technology value stream, including Product Management, Development, QA, IT Operations, and InfoSec.”

 One of my favorite definitions is from Rob England (aka “The IT Skeptic”). Rob describes DevOps as follows[3] : “Agile is the approach of working with complex systems anywhere. Lean is the approach of optimizing the flow of work anywhere. DevOps is the application of Agile and Lean to the acceleration of value work through IT.”

DevOps Defined?

Perhaps the best definition of DevOps is credited to Jez Humble, one of the co-authors of “The DevOps Handbook” who coined the term “CALMS”.[4] CALMS is a conceptual framework for integrating development and operational (DevOps) teams within an organization.  CALMS is an acronym for:

  • Culture – A culture of shared responsibility
  • Automation – Automate as many tasks as possible
  • Lean – Visualization of work-in-progress; limit batch sizes; eliminate waste; continuous improvement, focus on customer value
  • Measurement – Data is collected on everything, with mechanisms for providing visibility into all systems
  • Sharing – There are user-friendly channels for facilitating on-going communications

In most DevOps thinking and reading, CALMS seems to be a common theme.  But I also encounter a lot of DevOps “anti-thinking” as well.

What DevOps is not

Here are a few examples of DevOps “anti-thinking” that I’ve encountered.  DevOps is not:

  • A standard – There is no documented “DevOps” standard.
  • A tool – There are literally hundreds of tools (I’m not sure if this is a good or bad thing) that claim to be “DevOps” tools. The point is buying a tool does not make your organization a “DevOps” organization.
  • A best practice – There is no defined “body of knowledge” or designated reference for DevOps. In fact, there are literally hundreds of books about DevOps, and some (highly visible) examples of organizations that have successfully adopted DevOps thinking. But there is no designated DevOps “best practice”.
  • Just automation – While automation is perhaps one of the most visible aspects of DevOps, automation alone is not “DevOps”.
  • A silver bullet for IT issues – Just saying that you’re “doing” DevOps is not the same as addressing communication issues, collaboration challenges, wasteful processes, poor measurement practices, eliminating technical debt, and other organizational problems.

What is DevOps?

So, what is DevOps?  At its core, DevOps is a mindset; a way of working together. DevOps is:

  • About building trust and teamwork, sharing knowledge, taking accountability – Teams build trust when members can rely upon one another. Trust is built when team members openly and willingly share their knowledge and contribute to the success of the team.  When mistakes happen, the member making the mistake acknowledges the error; but more than that, there is no blame; the team works together to resolve the error.
  • About tearing down the walls that exist between working groups within IT – DevOps can only be successful when all parts of the IT team are part of the success.
  • About creating a culture of experimentation and learning – Too many organizations work in fear of failure. Much about DevOps is about empowering and learning.
  • About improving the productivity of the overall organization – Sometimes that means searching out and eliminating waste or streamlining the process. If it’s taking too long to get code to trunk and then tested, what can be done to improve that?  If standing up a new development environment requires manual intervention, what could be done to standardize that work so that manual intervention is no longer required?

Avoiding DevOps “Ditches”

Knowing what DevOps is and is not will help you get on the road to success. Here are five ditches to avoid to achieve success with DevOps.

  • Purchasing and implementing tools before anything else – DevOps adoptions taking this approach usually fall into the old “hammer and nail” syndrome (“when all you have is a hammer, every problem looks like a nail”). Well, just because you own a hammer and can swing it doesn’t make you a carpenter.  One of the most common mistakes with DevOps adoption is too much focus on tool implementation and automation of (often poorly or even undefined) processes. When all you have done is implement a tool without designing processes or developing teams, you’ve not “DevOps”- you’re just using a tool – and likely not getting the full benefit of that tool.
  • Getting hung up on semantics – Developers and operations both have developed their own specific languages for what each group does – and this often causes confusion. Take the time to define and agree on a shared terminology.
  • Developers running over everyone else in the organization under the flag of “we’re doing DevOps” – Once, while at a client site, I heard a “DevOps engineer” (seriously) tell a sysadmin that “I’m about to automate you out of a job.” Not a very collaborative, teamwork attitude, huh?  DevOps is about building teams whose members trust and rely on each other- not trying to dominate or control.
  • Arbitrarily throwing out existing process and procedures – Although a process may not be performing as effectively and efficiently as desired, don’t overlook the fact that there was a good reason why that process was defined and implemented in the first place. In my experience, process design and implementations have been treated as “one time” activities and rarely revisited to identify improvements or needed changes.  Before getting rid of an existing process, first understand the reason for the process, and if that reason still exists today.  Then look for ways to improve that existing process, rather than just throwing it away.
  • Ignoring the need for organizational change – DevOps adoption represents a significant change in the way IT does its work. Without good communication, appropriate training, and a shift to a “thinking / experimentation / learning” mindset, DevOps adoption will fail.

Keep CALMS and DevOps on

Knowing what DevOps is and is not is key for success in adopting DevOps.  Following the CALMS model ensures that you’re addressing the complete extent of DevOps adoption, and not just being fixated on a single aspect.

Need help answering the question “What is DevOps?”  Want to build a fundamental understanding of DevOps?  Tedder Consulting offers the DASA-accredited DevOps Fundamentals class.  Visit  our training page to register for an upcoming class! 

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

Picture Credit: Pixabay

[1] https://www.gartner.com/it-glossary/devops , retrieved 8/11/2018.

[2] Kim, Gene, et al. “The DevOps Handbook”. IT Revolution Press, LLC. 2016. Portland, OR

[3] http://www.itskeptic.org/content/laymans-definition-devops, retrieved 8/11/2018.

[4] https://whatis.techtarget.com/definition/CALMS , retrieved 8/11/2018.

Share twitterlinkedinmail

Let’s Stop Playing “Service Provider” and “Customer”

Share twitterlinkedinmail

The concept – at a high level –  wasn’t all bad.

The concept was that IT organizations should adopt a service-oriented mindset when it comes to working within the business.  The attitude of the IT organization must shift from “technology is cool” to “what’s best for our business”.

So best practice advised IT to become a “service provider” to the “customers” found within the business.

But in practice, IT taking on the role of “service provider” and treating business colleagues as “customers” sends the wrong message to the business – and within IT.

It’s the wrong message

When IT treats colleagues as “customers”, and colleagues view IT as a “service provider”, it puts up barriers with an organization.  Not only does it artificially separate the IT organization from the rest of the business, it makes working with the IT organization needlessly more difficult.  Under the mantra of “the customer is always right”, IT often jumps through unnecessary hoops to make the “customer” happy.  Being referred to as a “customer” gives some colleagues a sense of entitlement in their interactions with IT.  Some within the business make and have unrealistic expectations of the IT organization.

Perhaps even worse, the service provider / customer definition divides the IT organization.  The development team makes demands of the operation team.  The security team makes demands of the development and operations teams.  Demands all issued under the guise of “I am your customer – serve me”.

We’re really not service providers.  They really aren’t customers.

If IT was really a service provider, it would find itself competing in an open market place within a business.  IT would have the ability to (really) sell its services at market rates, scale as needed, and invest in new and emerging technology as it deemed fit. But that is not the reality of enterprise IT.  IT has a budget that has been allocated and agreed within the business to which IT must adhere.  This means is that IT really cannot scale resources or significantly alter or add services without agreement and funding from the business it serves.

If “the business” was truly the customer, they could shop for IT services, both from within and external to the business.  “The business” could contract with whatever service provider it chose and not be concerned with interoperability, security, maintainability, and every other -ability with which enterprise IT must be concerned.  But in reality, “the business” is (mostly) a captive user of its organization’s IT services.

IT is not a “service provider”.

The “customer” is not an internal group or person.

So, what are we?

What we are is a business.

A business is an organization aligned by purpose, vision, and goals, with each member working for the benefit of the organization and for the success of all other members of the same organization.   It takes all parts of the business – HR, Marketing, Sales, Manufacturing, IT – for a business to have success.  No single part of a business can stand on its own and be successful without interactions with and cooperation from the other parts.

By working as an integrated entity, a business has unlimited potential.  But what a business does not have is unlimited resources.  And when a business loses sight of the fact that it does not have unlimited resources, it often looks like this:

  • Multiple “number 1” priorities

o   But no additional staff is allocated to help

o   And no postponement or cancellation of other initiatives

  • Lack of investment in “keeping the lights on” – not doing the “care-and-feeding” needed to maintain current operations
  • Quality is often sacrificed to meet target dates

And then, IT often becomes an obstacle for getting something done.

Then in an effort to keep up (or dig its way out), IT overcommits and takes on additional work without fully understanding the demand or impact on its (limited) resources.  And when IT can’t deliver, then IT is looked at as being too slow to respond or react to business needs or changes in the business environment.   IT becomes the “black hole” where business innovations go to disappear.

But here’s the conundrum.

Business – by definition – is an opportunistic endeavor.  Success in business means being in the right place at the right time with the right solution.

But to be in the right place and the right time with the right solution means that a business – including its IT capability- must be prepared.

Become opportunistic – holistically

To be opportunistic means that a business must be prepared.  Because when an opportunity does come along, the business has to be able to make a decision based on the best information available.  But too often, business decisions are made based on “gut feel” or seeing only part of the big picture.

And especially in the digital age, technology – managed by the IT organization – is critical for business success.  Here are four things to do to get prepared.

  • Drop the “service provider / customer” speak. All members of the business are on the same team – there can be no “us” and “them” within an organization.  And to be clear, the customer is not part of the organization.  The customer is who a business is trying to entice to do business with the business. The business is the service provider to the customer.  Stop referring to internal resources as “service provider” and “customer”.
  • Define the service portfolio. A service portfolio articulates and establishes a shared understanding about how the business is using and is planning to use technology-based solutions from IT.  But more than that, the service portfolio provides a holistic view of resource commitments, current and future value, and the total cost of ownership for providing those technology-based solutions-all in terms of business outcomes.
  • Map the value streams of the business. Mapping value streams facilitates visualization of how information and material flow throw an organization to create or deliver value to a customer.  A value stream map helps help “connect the dots” regarding how the various parts of an organization (including IT) work together to deliver that value.
  • Share knowledge – all knowledge. Being prepared to seize opportunities depends on having available, timely, accurate, and relevant knowledge from all parts of the organization, throughout the organization. Knowledge is the basis for good decision-making.

How does doing these four things help?  It’s about being prepared to make a timely and informed decision when opportunity knocks.  A business that does these four things not only understands what it is doing today, but also has the needed insight into how its capabilities could be leveraged when presented with an opportunity.

It’s time for another mindset shift

The service provider / customer concept may have been a good way to start the mindset shift that many IT organizations needed.  It’s now time for IT organizations and businesses to stop playing service provider and customer.  The business landscape is rapidly changing, and technology is becoming the cornerstone of a business in the digital economy.  Being prepared is the best way to take advantage of the opportunities presented in the digital economy.

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

Photo credit: Pexels

Share twitterlinkedinmail

5 ways DevOps thinking can cure “Bad ITSM”

Share twitterlinkedinmail

The ITSM highway is littered with implementation efforts that failed to achieve their potential.

ITSM, done well, has proven to be great for business. Unfortunately, for many businesses, implementation efforts resulted in “bad ITSM”.

Many of these ITSM implementations were initiated by the IT operations team, and perhaps had some early successes managing incidents and service requests. But many of these implementations were too focused on tool implementations that didn’t quite hit the mark or process engineering efforts that resulted in unjustified bureaucracy.

IT Operations then tried to push ITSM onto the other parts of IT, with limited (if any) success. ITSM became the bottleneck rather than the enabler.

Can some DevOps thinking be the cure for “bad ITSM”?

What is DevOps?

First, let’s get clear on what DevOps actually is. The key objective of DevOps is getting the development and operations teams working better together. But what is “DevOps”?

The DevOps Handbook[1] defines it as “the outcome of applying the most trusted principles from the domain of physical manufacturing and leadership to the IT value stream. DevOps relies on bodies of knowledge from Lean, Theory of Constraints, the Toyota Production System, resilience engineering, learning organizations, safety culture, human factors, and many others”. DevOps is best thought of as “CALMS”[2] , a conceptual framework for integrating development and operations teams. CALMS is an acronym for:

  • Culture – A culture of shared responsibility
  • Automation – Automate as many tasks as possible
  • Lean – Visualization of work in progress, limit batch sizes, eliminate waste
  • Measurement – Data is collected on everything, with mechanisms for providing visibility into all systems
  • Sharing – User friendly channels for facilitating ongoing communications between development and operations

If CALMS is the foundation of DevOps, can CALMS be a way forward for ITSM?

How DevOps and ITSM are often described

Many ITSM implementations fell short because ITSM was viewed only as something done only by IT operations. In many cases, this perception was deserved because no one outside of IT operations was involved in the implementation.   ITSM was too focused on stability and “status quo”.  As a result, ITSM became a barrier, rather than a way for the operations and development teams to better collaborate.

A recent article[3] described the relationship between development and ITSM as represented in the diagram below:

 

 

 

 

 

The article focuses on the relationship between software engineering and the “IT help desk” (implying that ITSM is just the “help desk”). The article suggested ways to integrate the ITSM and engineering teams, such as providing some method for the “IT help desk” to provide enhancement requests to the engineering team.  Engineering should provide estimates to the help desk regarding planned releases, rather than include the help desk in those planning discussions.  If a help desk representative needs to talk to an engineer about a defect, the representative should not only track such defects in the ITSM tool, but also in the engineering tool….and let engineering know which defect it is within the engineering tool.

Well, doesn’t this sound familiar?

Doesn’t this sound just like the IT operations-centric approach to ITSM, but in reverse?  ITSM is seen as something being done in addition to software development.  Operations must jump through some hoops to talk to the development team.

When does the security team get involved?  Or the QA team?

Isn’t this just perpetuating the so-called “wall of confusion” between the parts of the IT organization?

Isn’t ITSM really this?

For whatever reason, there seems to be this irresistible tendency of looking at IT as a collection of parts:

  • Security – ensures the integrity and confidentiality of data assets; protect data assets from threat or harm
  • QA – provides cost justifiable quality and compliance with regulatory and other requirements
  • Operations – delivers stable, reliable, and consistent IT services
  • Development – encodes and delivers applications and software that solve business challenges

The fact is that it takes all parts of the IT organization – security, QA, operations, and development – working together to deliver viable and valuable services for the business.  No single part of IT can deliver business solutions by itself.

We must stop looking at IT – and therefore ITSM – as a collection of parts.  Shouldn’t we really think of ITSM like this?

 

 

 

 

 

ITSM should be a means of delivering valuable outcomes that businesses require from the use of technology.  It should be Strategy-Design-Transition-Operations as a single, frictionless flow, not a series of gates.  ITSM should be a way to collaboratively align the IT organization to meet shared goals and objectives. ITSM should be about continual improvement, finding ways for the business to improve how it does business, leveraging technology.

If your ITSM isn’t quite where it should be, DevOps can help.

5 ways DevOps thinking can cure “Bad ITSM”

Somehow, ITSM lost its way in many organizations.  But DevOps adoption doesn’t mean that you throw out all of the ITSM work you’ve done – you’re still going to need processes, you still must define services.  Having said that, DevOps can provide a means for organizations to hit the “reset” button on their “bad ITSM” implementations.

Here are five ways that DevOps thinking can cure a “Bad ITSM” implementation:

  • Change the Culture – Like ITSM, success with DevOps starts with cultural change. Cultural change must start from the senior management level and permeate through the organization.  What does this cultural change look like?   Leaders do not allow teams to form siloes.  When errors are found, the team stops work and fixes them, rather than trying to hide the issue or pass the error down the line.  An attitude of collaboration and shared responsibility between development, operations, security, and quality exists from the beginning.  Embed a “DevOps” culture in your ITSM implementation.
  • Drive to automate – Automation first requires effective, well-designed processes.  A symptom of many bad ITSM implementations are processes that are bloated, overly-engineered, and bureaucratic.  Take a DevOps approach and define, simplify, then automate processes. Automation will result in ITSM that is much more effective and efficient.  The more automation, the more responsive the IT organization can be to changes in business needs.
  • Work iteratively – ITSM implementations often suffer from “waterfall-ish” approaches. Take a DevOps approach and work iteratively with process designs, improvements, and solution delivery.  Shift from a “big bang” approach to delivering value in smaller, more manageable and predicable increments – then develop and implement those increments more frequently.  This means smaller release packages or smaller changes, but in return, business realizes value from technology use more quickly.
  • Standardize infrastructure configurations – Both DevOps and ITSM concepts are “technology agnostic”. Having said that, using technology in the best way makes utilizing DevOps and ITSM concepts much easier.  Take a page from DevOps and standardize infrastructure configurations. Define and use a standardized approach to provisioning infrastructure[4] – servers, storage, operating systems, and networks.  The same infrastructure configuration is then used across all environments – development, test, UAT, and production – simplifying testing and validation and improving reliability by removing any variation between environments.  An evolutionary next step would be Infrastructure as Code – which could be codified as a “standard change”!
  • Develop and document test scripts, then continually test – A key DevOps concept is automated testing. This approach allows testing to be done at any point along the development cycle.  Applying this concept to ITSM, develop standardized test and validation scripts and execute those scripts as part of any change, release, or deployment.  Not only will this improve service reliability and confidence in implementing changes, but it can become the foundation for automated testing, and allows for deployments to be decoupled from releases – another key DevOps concept.

DevOps can help organizations realize the promise of ITSM

If your organization is suffering from “bad ITSM”, adopting and adapting these DevOps concepts can help.  But “bad ITSM” cannot be cured overnight, so “start smart”.  Think evolution, not revolution – perhaps start with a service or a process that isn’t performing as needed.  Implement some of these concepts, be willing to experiment and learn, and watch ITSM improve!

 Is your organization suffering from “bad ITSM”? Invite Tedder Consulting to work with you to apply some “Next Generation ITSM” thinking and get back on track!  Contact Tedder Consulting today! 

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

Picture credit: Pexels.com

[1] Kim, Gene, et al. “The DevOps Handbook”, IT Revolution Press LLC, Portland, OR. 2016.

[2] http://whatis.techtarget.com/definition/CALMS

[3] https://devops.com/bridging-gap-itsm-software-engineering/

[4] “Infrastructure as a Service”?

 

Share twitterlinkedinmail

The part of the ITSM Implementation Organizations seem to Skip

Share twitterlinkedinmail

I often see a pattern with ITSM implementations. Perhaps you’ve seen the same pattern. What I’ve seen is that organizations frequently focus on and invest in three of the four “P’s” – Process, Partners, and Products – of the ITSM implementation. What’s missing? The fourth “P” – People.

It’s the “people part” that differentiates the successful ITSM implementations from the ones that don’t quite reach goals and aspirations.   If the “people part” is done right, ITSM becomes rooted within the fabric of an organization; done wrong, the ITSM implementation is on a path for failure.

What does the “people part” done wrong look like? Here are a few examples.

  • Training plans are either not defined, or no objectives have been defined for training; it seemingly is just an item on a checklist of things that must be done. So everyone is sent through some type of mass training, followed by …. well, nothing.
  • If training plans are documented, they’re often ignored or haphazard, because to go through training takes away resources needed to define processes and configure tools during the implementation project.
  • Communication plans consist of a kickoff meeting and an occasional update in the company newsletter or staff meetings.  No opportunity for feedback is provided, much less any discussion about the realization of benefits. No one really understands or has the opportunity to “buy in” to why ITSM is being done.
  • Senior leaders don’t “walk the talk”. Actions speak louder than words. If senior leaders only talk about, but do not exhibit the attitude and behaviors they want to have result of the ITSM implementation, people aren’t going to “walk the talk” either.

Perhaps you’ve read the story about the CFO that asks the CEO “what happens if money is spent training people, and the people leave?” The CEO responds, “what happens if we don’t train them and they stay?”

Maybe you’ve experienced a communication plan that results in a lot of build-up and publicity during implementation, only to result in “radio silence” after the initial implementation is complete.

Dealing with people can be messy. People are human “beings” and not human “doings”, and don’t fit into neat little boxes. Because we’re human, emotions do play a part, so having emotional intelligence is important. People do want to do good work and achieve goals, but if they don’t know how to do the work or why the work is important, it can be a struggle.

This is why “people” is the most critical component of any ITSM implementation. People follow and execute processes, people work with tools and products, people work with partners and suppliers (which are made up of people too!).   People do the work that make organizations successful…or not. It’s widely acknowledged that people generally perform better when they know what is expected and why it is needed.   So why do organizations always want to skip or take shortcuts on the “people part”?

So if you’re just starting your ITSM implementation, or even if you’ve been on the journey for a while, invest in the “people part”. Here’s some of what you’ll get in return:

  • Improved motivation, which in turn drives better teamwork and engagement.
  • Improved customer experience.
  • Engaged team members vested in the success of the organization.
  • Improved reputation and credibility, as internal partners will want to do business with team members who are engaged and vested in the success of the organization.
  • Better management; when managers make investments in their people, their people feel valued and will want to follow them.
  • Improved results, because people do better when they understand what is expected of them.

Photo Credit:  Shutterstock

A solid communication plan is a great first step in investing in the “people part”.  Need some help defining your communication plan?  Download a communication plan template  by completing the form below!

[lab_subscriber_download_form download_id=4]

 

Share twitterlinkedinmail

Shysters, Highwaymen, and others on the ITSM Journey

Share twitterlinkedinmail

Travel in medieval times was always full of challenges and dangers. Travel usually took place during the daylight hours, following roads perhaps built during the Roman Empire period, or following other roads that were not well paved, if they were paved at all. Sometimes the “road” was simply a rarely used path or obscure trail. Travel was slow; usually by foot or perhaps horseback, and journeys took days, if not weeks to complete.   Any journey was quite an endeavor, as people usually traveled in groups, not only for company, but for protection as well. Those traveling had to pack some provisions and hope to find a safe haven with shelter and food along the way in a roadside tavern. Travel was dangerous, as highwaymen hid in the nearby underbrush, looking to rob an unsuspecting party or unaccompanied traveler. Even during stops at a roadside tavern, the travelers couldn’t totally relax. Shysters would approach the traveling party and promise rewards in exchange for a sum of money, but the reward would never materialize, leaving the traveler with nothing. Travelers could also encounter mystics, who like the shyster, for a sum of money, would predict the future; when morning came, the mystic was nowhere to be found. Sometimes travelers found the journey too treacherous and stayed near the tavern or even turned back. Further compounding the journey was the various fiefdoms that traveling party had to pass through. Each fiefdom had its own set of customs and laws, despite the fact that the fiefdoms were all part of the same kingdom. Bad weather, rivers, mountains, and other obstacles presented challenges to the travelers as well.

But for those that planned well, took appropriate precautions, and remained vigilant, the traveling party accomplished their goal and reached their destination. Many times, there was a feast for the travelers to celebrate the successful journey.

Certainly, I think you can agree that modern travel has come a long way since the medieval times.  Medieval travelers encountered challenges, obstacles and shady people on their journeys.

But it occurs to me—are ITSM implementations so different than medieval travel? It isn’t so much of a stretch when you think about it:

Medieval Travel ITSM Implementations
  • Poor or non-existent roads
  • Often trail -blazing – there is no current road!
  • Had a destination in mind before traveling
  • Business Case and ITSM Plan
  • Traveled in groups
  • ITSM implementation team
  • Travel was slow
  • ITSM implementations take time (“journey, not sprint”)
  • Many obstacles and challenges
  • Many obstacles and challenges
  • Shysters, highwaymen, mystics, traveling party
  • People who support, doubt, or resist ITSM

 

Do you see the similarities?   While there is a lot here I could discuss, I’d like to focus on the aspect of people.

Are you encountering shysters, mystics and highway men on your ITSM journey? How are you keeping your traveling party focused on the goal? What are you doing to keep those that want to stop or turn back engaged?

When I think about it, I think that the people we encounter on the ITSM journey generally fall into one of three groups:

  • Believers –This group is energized about the implementation and put heart, soul, and mind into the effort. They don’t become discouraged when the inevitable obstacles and challenges arise, but use those challenges and obstacles as motivation to achieve success.
  • Doubters – Generally the people in this group take a “wait and see” approach. While they may not resist the ITSM implementation, they aren’t quite convinced that it will be successful either.
  • Resisters – This is the group that wants nothing to do with the ITSM implementation, and often work against the implementation.

In your ITSM implementation, you must address all three groups. All three groups are a part of your ITSM “traveling party”. None of these groups can be ignored nor favored to the determent of the others. So how to ensure that all three groups are being engaged? Here’s some suggestions:

  • Believers – Keep in mind that ITSM implementations are journeys – they take some time! Have your believers participate in the development of goals and objectives and identify interim achievements. Celebrate successes along the way, and approach challenges and obstacles as learning opportunities. Showcase the efforts and accomplishments of the implementation. Proactively engage them, solicit and incorporate their feedback on the implementation.
  • Doubters – Develop appropriate measures and reports, and show them the evidence that your making progress. Show this group how the use of continual improvement practices will help overcome challenges. Show them how ITSM is helping the organization achieve its goals and objectives. Proactively engage them and solicit and incorporate their feedback on the implementation.
  • Resisters – This one may surprise you—make them part of the solution! Purposefully include resisters on the process design teams and workshops. Have them articulate specific (not general) areas of concern and engage them to help determine the resolution to those concerns. Proactively engage them, solicit and incorporate their feedback on the implementation.

The ITSM journey will take some time. You may have rebuild some worn down roads or in some cases, blaze new trails. There will be those on your journey that want to sell you things you don’t need, or worse, take your money and vanish. You will encounter obstacles and challenges.   But in my opinion the most important part of the ITSM journey is the people that you’ll meet on the way.   Engaging your believers, doubters, and resisters – all three groups – is a key to a successful ITSM journey.

Need some guidance on your ITSM journey?  Tedder Consulting is here to help – contact me today!  Get my monthly insights into all things service management – click here to subscribe to my newsletter!

Share twitterlinkedinmail

We don’t need another hero

Share twitterlinkedinmail

Do you like movies featuring superheroes?  You know the ones – the superhero has some superlative ability, like superhuman strength, or telepathic ability, or super speed, or heat vision, or shape-shifting.   The plots of these movies are generally very similar – it is usually an epic battle of good vs. bad, which means that there is usually some threat or menace that threatens to take over the earth or at the very least, would certainly end life as we know it. Then, just when you think it can’t get any worse, or the last domino is about to fall, the superhero appears and saves the day.

And, if you’ve watched enough of these superhero movies, perhaps you’ve noticed a few other similarities:

  • The hero tends to be a loner, and doesn’t really work well within teams.
  • The hero may save the day, but usually leaves a mess– a big mess—behind that someone else has to clean up.
  • Others usually watch the hero, but few (if any) rarely (if ever) get involved.

Does this sound like someone in your organization?  Do you have a “hero” on your ITSM team?

So while it may be entertaining to watch the hero at the movies, it’s only a movie.  When it comes to ITSM, we don’t heroes.  In fact, heroes are bad for ITSM.  Why?

Businesses depend on IT to be reliable and consistent, which are a couple of the many good reasons why IT organizations undertake an ITSM implementation.  While heroic actions may save the day, by definition, heroic actions are not reliable and are inconsistent. Good ITSM depends on consistent, repeatable and measurable processes.  Efforts from the hero are not repeatable, not sustainable, and frankly, leave a mess.  This ‘mess’ takes the form of damaged relationships not only within the team, but damaged reputations for both the business and the IT organization.  Internal business partners eventually grow tired of the hero, so they often begin to work around the hero, or may even avoid IT altogether.  So while in the near term, the actions of the hero may be appreciated (and even wrongly rewarded!), over the long term, it’s just not good business.

Good ITSM depends upon good teamwork, with everyone working together within roles as part of a team.  In my role as a consultant, I often point out that if it only took one person to do everything that needs to be done within IT, then why is the rest of the IT organization here?   We simply cannot work in silos or alone (as the hero often prefers) and expect long-term success.  Heroes destroy teams.  Heroes cause resentment within teams, because often the hero is treated ‘special’ by management and as a result, acts as if the rules or policies or process definitions do not apply to her.  Ironically, heroes typically have no respect for or trust in management. Compounding the situation is that others on the team notice the special treatment that the hero receives, and become resentful.   If this treatment of the hero continues, the rest of the team begin to watch, and begin to withdraw from the team, only getting involved when absolutely necessary.

Good ITSM depends on knowledge sharing.  The hero tends to hoard knowledge, because to share knowledge would be a threat to their position as the ‘hero’.  Because the hero is so busy “saving the world”, he doesn’t have time to document knowledge, and if anything actually does get documented, it is minimal and difficult to consume.

I’ve yet to see a process RACI matrix that defines a role for the ‘hero’.   We don’t need a hero; we just need good ITSM.

Click here to subscribe to my newsletter!

Share twitterlinkedinmail

Yes, you *can* just turn on your new ITSM tool…

Share twitterlinkedinmail

I understand.  I really do.  Your company has made a significant investment in a new ITSM tool.  Your company needed a new ITSM tool, and it’s just been sitting in the box on your bookshelf, waiting for you to get it in installed and running.   Your CIO has stopped by your workplace a couple of times in the past few weeks, asking how the installation is going, and when she will start seeing those dashboard reports that she heard about.   The features of the new ITSM tool are the talk of the Service Desk Agents, who can’t wait to get their hands on it.  Other managers are absolutely giddy about how the new tool will fix the consistency issues within IT and see the new tool as an opportunity to improve the undeserved poor perception of the IT organization.

So I may be about to say something you would not have expected from me.

Go ahead and install that new ITSM tool.  Turn it on.  Start working with it.  Have your Service Desk start logging tickets in the new tool.  It will be great.  It will work exactly as you’ve imagined…..if…..

If.

If you’ve defined what activities will be performed as part of the execution of the process, and how the process moves from beginning to end through each activity.

If you’ve defined the roles that are involved with the processes you’ve decided to implement, the responsibilities and expectations of those roles, and who is doing what activity within the process.

If you’ve identified what events start the execution of the process.

If you’ve determined what inputs are required for the proper execution of the process, where that input data is coming from, and how you’re going to capture and validate that data within the new ITSM tool.

If you’ve determined who will get the results from the execution of the process and how those results will be delivered.

If you’ve identified how success will be measured, defined the measures that you need to capture from the execution of the process, how you’re going to capture those measures, how you’re going to measure effectiveness and efficiency of the process, and how those measures will be translated and formatted into those dashboards the CIO is expecting (along with whomever else will need reports from the process).

If you’ve defined, documented, and informed your organization of the policies and procedures that help control the use of your processes.

If you’ve gained agreement, support, and sign-off from senior management for the enforcement of those policies that govern those processes.

If your Service Desk Agents have been trained in the optimal use of the new ITSM tool.

If you’ve adequately communicated and educated your organization about the benefits of the ITSM initiative the new tool is intended to enable.

Make no mistake—you do need the functionality that a new ITSM tool can bring to your organization.   But, if you can answer “yes” to all of the ‘ifs’ I listed above, your new ITSM tool implementation will go much better.

Need to get that ITSM tool up and running, but you’ve not defined processes?  Our Process Design Workshop is just the ticket – contact Tedder Consulting today to make it happen!  Get more pragmatic insights to service management by subscribing to my newsletter

Share twitterlinkedinmail