Tag Archives: Service

IT Reset: How to Re-Prioritize IT Initiatives During COVID-19

Share twitterlinkedinmail

CIOs have had their work cut out for them over the last few months. The sudden shift to remote work has put pressure on IT to create solutions for remote workers using technology that perhaps was older or less capable, support overworked and stressed out IT technicians, and, in general, keep the business moving through the use of technology.

The priority at this time must be ensuring that technology supports essential business processes. But that doesn’t mean IT leaders should freeze any other initiatives until after COVID-19 has passed.

In fact, the worst thing any leader can do right now is “freeze” and wait until life “returns to normal.” There will be no return to the normal as businesses knew it before the pandemic. Even after the immediate threat has passed and businesses can resume working in offices, the way we work will be forever changed because of this situation.

There will be an expectation for the business to provide flexible work environments, more self-service options, tighter security, and better contingency plans for addressing future disruptions like this one.

All of these shifts provide IT with a rare opportunity to hit pause, take a step back, and reassess priorities. Adobe’s CIO Cynthia Stoddard advises, “CIOs now have to rethink priorities, or at least reorder them, and we must reinvent ourselves now as virtual leaders.”

Here are a few ways you can reset your priorities and identify what initiatives you should take on right now.

Cybersecurity

One of the first priorities should be your level of protection against cyber threats. Security is imperative for continuing essential business operations but this unique situation has increased the risk of cyber threats. “Zoom bombing” became a trend over the last few weeks as uninvited guests crashed virtual meetings and get-togethers, often disrupting the session with violent rhetoric. While Zoom quickly adapted to protect its users, this may be just the beginning of more frequent cyber-attacks and threats. As more of the world moves online, hackers will most likely increase the intensity and sophistication of their attacks. CIOs should review their cybersecurity protocols and ensure the proper procedures are being followed.

Productive Remote Work Environments

In addition to cybersecurity, CIOs need to make sure that every person in the organization is equipped to do their job remotely. This might mean you need to more heavily invest or leverage self-service technology or AI. Large investments or initiatives around new technology may have been on the back burner but now is an ideal time to reassess whether you need to make those investments now.

It’s also not just about providing technology. You may need to equip your team to handle and manage it. Are your knowledge bases relevant and up to date? Knowledge bases may not be seen as high priority, but techs will no longer be able to just walk down to an office to troubleshoot a problem. More of the organization could be turning to knowledge bases to navigate technology while they work from home.

Service Delivery

Another area to review is your service delivery processes. There are many facets of connectivity that are out of your team’s hands right now, including different hardware and software being used by team members with different levels of connectivity. Like I mentioned earlier, a service technician can’t simply walk down to an office to troubleshoot an issue. If there were any gaps in your service delivery processes before COVID-19, they are likely more apparent and problematic now. Take this time now to address those important issues.

Refocusing priorities will allow you to emerge from this situation more efficient and capable than you were. This will enable you to refocus on those more urgent tasks.

I mentioned in a previous blog post that CIOs and IT leaders need to focus on enabling outcomes instead of simply delivering outputs. Even though the way we work is rapidly shifting, this is a perfect time to reassess how IT can drive outcomes. We’ll never go back to work as before. So, instead of looking at this situation as a blow to current initiatives, look at it as the perfect time to re-prioritize and prepare for the new future.

Share twitterlinkedinmail

Four Steps for finding your misplaced Service Owner

Share twitterlinkedinmail

Has your IT organization defined services and named service owners?

Have you identified the right person as the service owner?

How do you know?

Let’s start from the beginning

What is a “service”?

According to ITIL®, a service is “a means of delivering value to a customer by facilitating the outcomes that a customer wants without the ownership of [specific] costs and risks”.[1]

A service is not a discrete unit of delivery, but an on-demand flow that is (should be) continually improved to deliver the outcomes required by the ever-changing needs of business.

A key service role is that of the service owner. The service owner “owns” the service – that is, the service owner is accountable for the quality of outcomes resulting from the consumption and use of the service.

Many organizations have identified IT people as its “service owners”.

But who decides if a service is delivering the desired outcomes? Who decides if the service quality is adequate and appropriate? The customer.

That confusing “customer thing”

Who is the customer?

That’s the thing that seems to cause all kinds of confusion within organizations – the term “customer”.

Who is the customer?

  • The ultimate buyer of solutions.
  • The ultimate judge of quality and outcomes.
  • Who the business is trying to entice and retain in the buying of the products and services.

This means that for many services, IT can’t be service owner.

If the service is an “IT service” – that is, the service is provided by IT and consumed within an organization, then yes, someone in IT is (better be!) the “service owner”. But many services that involve the use of technology result in outcomes that are delivered externally – to the true customer. This means that a lot of IT’s work is done in support of delivering value to a customer that is outside of the business.

But typically, IT is not directly involved in interactions with the customer.

Finding the (true) Service Owner

So, who is the service owner? How about the value stream owner?

In their book “Value Stream Mapping”, Martin and Osterling define a value stream as being “the sequence of activities required to design, product, and deliver a good or service to a customer, and it includes the dual flows of information and material”.[2] They also describe a “value stream champion” as “someone who’s accountable for the performance of the entire value stream. In a hierarchical organization, [this person] is a step or two closer to the work than the executive sponsor”.[3]

ValueStreamGlobal.com describes the role of a value stream owner (VSO) as “an experienced manager or executive servant leader who is accountable to senior management for improving the value to non-value ration of a product family within an enterprise”.[4] Among the responsibilities of the VSO are[5]:

  • Ensuring the Value Stream itself is correctly identified, defined, mapped, optimized, managed, and improved over time…. Including specific definition of the product/service family and related components
  • Coordinate with business functional areas that contribute to the creation of value in the flow.
  • Demonstrate to senior management that the outputs of the value stream are competitive in the marketplace and meet current customer* demand. The value stream must be able to quickly adapt to changing market conditions.
  • Maintain a holistic view of the organization and understand where in the large scheme of things their value stream fits… includes not sacrificing one area for the sake of optimizing another, but to optimize the whole.

“Value stream owner” …. sounds like a “service owner” to me.

Why IT isn’t (always) the Service Owner

If the service owner owns a service from end-to-end; that is, from point-of-origin to point-of-consumption, this means that (in most cases) the service owner cannot reside within IT. While IT may manage and perform activities as part of service delivery and support, IT cannot possibly own a service from point-of-origin to point-of-consumption. Why? Because IT does not have customers – the business does.

IT typically acts upon business needs. Rarely (if ever!) does IT lead business initiatives or interact directly with the (true) customer.

Therefore, the value stream owner must be the service owner. IT’s role may be that of service manager (responsible for particular aspects of the daily operation of a service), but in the situations where value and outcomes are realized by the true customer, IT cannot be the service owner. IT controls only a portion of any given value stream involving the true customer. If IT tries to take ownership of services for which it cannot adequately or appropriately be accountable, it is setting both itself and its business colleagues up to fail.

But on the other hand, since IT does own “IT services”, then IT cannot be passive and wait for something to happen or for someone else to provide IT with its “marching orders” regarding those services. IT must step up and take ownership – in the complete context. This means making the tough decisions like investing in security versus the risk of getting hacked. This means decommissioning infrastructure from the environment as services transition to a retired state.   As the owner for IT services, IT must drive value add, eliminate non-value-added activities, and also drive efforts that are necessary but non-value add – and live with the consequences of those decisions.

But the same applies for any service owner, not just IT service owners. A service owner must drive value added activities, eliminate non-value-added activities, and drive efforts that are necessary but non-value add. And live with those decisions.

That might be a different way of thinking for some. For some, it may be downright scary.

Because with ownership comes accountability and great responsibility.

What’s in the way?

The idea of a service owner being outside of the IT organization may be a bit scary to some. What’s in the way?

  • Attitude – Sometimes the thinking is that if it’s anything involving to technology, it is automatically an “IT issue”. Or conversely, if a colleague didn’t request a feature or ask the right question, then that’s a “business issue”. Organizations must look holistically at how value is created and delivered – there is no room for a “us and them” attitude.
  • Fear of losing control – Sometimes the IT organization feels that if it doesn’t own services, they will no longer have control. The fact is IT really never has been in control. Yes, IT is a part of nearly every value stream – but cannot own all value streams from end to end. It isn’t (should never have been) about control – it is about collaboration.
  • Lack of acumen – There’s often a ‘lack of acumen’ within the organization. IT often lacks business acumen – an understanding how the business works, what influences the business, or understanding the environment in which the business competes. Business colleagues often lack technical acumen – how technology works, how technology could be or is currently used within the organization, or are intimidated by technology.
  • Lack of clarity regarding the value stream – While many may have a deep understanding regarding their particular contributions to a value stream, often there are only a few that have an understanding of the end-to-end view of the value stream.
  • Services really weren’t defined – Rather describe services in terms of value and outcomes, “services” were defined as activities and things.

Four steps for finding misplaced Service Owners

Here’s my four-step approach for identifying and enabling the success of service owners.

  1. Identify and map value streams – Identify and document how value flows through an organization. Mapping the value streams provides a holistic view of the organization.
  2. Identify the value stream owner – While many contribute, who ultimately is accountable for the delivery and quality of the value stream?
  3. Understand the relationship between technology and the value stream – This provides the context for services and where IT “fits”.
  4. Define the service portfolio – Captures how technology underpins and enables value streams and enables fact-based decision-making.

Taking these steps will remove barriers within organizations by depicting how the members of the business work together to deliver value. It also moves the business to act as a complete business – not collections of parts – by enabling the mindset shift to “our value streams”.

In the digital era, all parts of the organization must work together seamlessly to deliver true customer value, and identifying the true  service owner is critical to value delivery.  Our Organizational Value Stream mapping workshop helps you visualize how value flows through your organization, so you can identify the true service owner, correct where there may be bottlenecks and missing handoffs,  and ensure smooth interactions with your customers in the digital age.

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

Photo credit:  Pixabay

[1] “ITIL® Service Strategy”. TSO, 2011. London. P. 13

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

[3] Ibid.

[4] https://valuestreamglobal.com retrieved 2/13/2018.

[5] Ibid

*There’s that word again!

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

Is ITIL® doomed to being an “Operations Only” Framework?

Share twitterlinkedinmail

Many organizations have attempted to establish IT Service Management (ITSM) following guidance found in ITIL[1] , but focused only on the operational aspects of the IT organization.

Then those organizations become frustrated that ITSM isn’t working as well as they had hoped.

Why isn’t ITSM working as hoped?  Because the service strategy, service design, and continual improvement phases of ITSM have been largely ignored.  Some aspects of service transition, like change management, knowledge management, and configuration management, have been addressed — but often not very well.  But service operation aspects, like a service desk and incident management, are fairly well-defined.  A “service catalog” – really a portal for managing service requests – is sometimes present, but often lacks distinct (if any) request models.

Frankly, it’s usually been a commendable effort, typically led by an IT Operations organization, in an attempt to establish ITSM and bring some normalcy and consistency into IT.  But many of those efforts ran into a glass ceiling.

What is IT Operations?

Wikipedia defines IT Operations as consisting of the superset of all processes and services that are both provisioned by an IT staff to their internal or external clients and used by themselves, to run themselves as a business.[2]

IT Operations focuses primarily on areas such as:

  • Working with IT Applications, troubleshooting application and performance issues, and specialized integrations
  • Database Maintenance
  • Job scheduling
  • Network Infrastructure
  • Server and Device Management
  • Help Desk – providing user and IT application support
  • Computer operations

Make no mistake – all of these areas are critical for providing business technology enablement.  But to be effective, ITSM has to be more than IT Operations.

Can ITIL be more than Operations?

ITIL was intended and designed to be more than operations.  The core concept of ITIL is to relate IT services to business outcomes and value – from ideation to retirement. But many ITSM implementations based on ITIL didn’t connect what IT does to business outcomes and value. What were some contributing factors for those  implementations?

  • A training industry focused more on certifications, less on how to achieve tangible business value.
  • ITSM tools that were focused on managing day-to-day activities, and less on how ITSM enabled or supported business strategy.
  • Implementation plans that were more focused on managing-by-procedure than on producing measurable business impact and results.
  • IT management looking for “quick fixes” or to “grease the squeaking wheels” of business colleagues’ complaints regarding the services from IT, rather than take the longer (and more valuable) approach to becoming a business innovator, leader, and partner.

Perhaps those IT organizations would’ve been better served utilizing ITOM.

ITOM vs. ITSM – What’s the difference?

ITOM, or IT Operations Management, deals with the day-to-day tasks related to the management of overall infrastructure components, and specific individual application, storage, networking, and connectivity elements of a total IT stack in any given deployment scenario.[3]

ITOM is infrastructure-oriented; primarily concerned with managing the infrastructure components of an IT organization, such as storage, servers, and network.  ITSM is service-oriented; that is, ITSM is concerned with the value chains of people, process, and technology that work together to deliver defined business outcomes and value.

So, while ITSM is concerned about technology, it’s not *just* the technology.  It’s also the people and processes and business outcomes and value – in other words,  services.

The concept of a service is the exact issue where so many operations-focused ITSM implementations fell short.   Those implementations did not define services in terms of business value and outcomes, but rather as lists of things that IT does.  Rather than identify and define the value chains of people, process, and technology that deliver business outcomes and value, they conducted an infrastructure discovery, and called was what found “services”.

Think about it.  When you’re conducting a discovery to build up your ITSM environment, what you’re really doing is taking an infrastructure approach, not a service approach. You’re chasing and recording how an electron travels across a wire. A discovery will never find service assets like processes, documentation, service level agreements, businesses cases, business strategy, service requirements, or a service portfolio.

What’s best for you – ITSM or ITOM?

For some organizations, ITSM may not make sense.  Trying to implement ITSM may not make sense for IT organizations that:

  • Are unable to properly define services
  • Will always be viewed as a “cost center”
  • Do not have a seat at the business strategy table
  • The development and operations teams resist collaboration
  • All that is expected from IT is to take orders and keep the lights on

For these organizations, ITOM may be the better approach – and that’s okay. Managing IT infrastructure in a consistent, reliable, and repeatable way is critical for businesses, and ITOM provides great guidance for doing just that.

But if your IT organization wants to transform not only itself, but the business it serves, then a service-oriented approach – ITSM – is what you need.  But getting ITSM started is not easy.  Sustaining ITSM is just as difficult.   But good ITSM must start from the top – and must have executive business support.

Think like a business exec

While bottom-up, grass roots approaches may have some initial success, such approaches rarely achieve the full potential of good ITSM. Good ITSM must be driven from the top-down. You must have business executive support.  To get business executive support, you have to think like a business executive.  A business executive wants to know things like how ITSM will:

  • Help the business be more profitable
  • Improve productivity
  • Optimize costs

In other words, what is the financial impact of ITSM implementation?  This is the first question you must be able to answer – and not having the answer is a blocker.  You won’t get the chance to even discuss the nontangible benefits of ITSM.  To get that top-down support, you have to first think like a business executive.

Here’s a suggested approach for getting the business executive approach support you need.

  • Conduct a business impact analysis – This is a great way to get some attention to the problems that good ITSM can solve. What if the business suddenly lost its IT capabilities?  What would be the impact? A business impact analysis quantifies the impact to the business if IT services were not available.
  • Build the business case – The business impact analysis provides the cold, hard facts. Take those facts and put them into the proper context with a solid business case. Not only depicting the tangible and intangible returns from ITSM – but what will the business feel from ITSM?  Improved productivity?  Cost avoidance?  Improved profits?  Make the case – and sell it!
  • Define services – How is value generated and delivered to the customer – the real customer (not your colleagues) – within your organization? Now how does IT enable or support that generation and delivery of value?  When you answer those questions, you have defined services.  When you’ve truly defined services, you’ve enabled the “value” conversation – a conversation that your business executives want.

Without senior executive support, your ITSM implementation will never move beyond managing the day-to-day.  The impact of good ITSM must be felt in the executive suite – and the only way for that to happen is for ITSM to deliver real business value.  Make the business value of ITSM extremely clear using the tips above – and get your senior executives onboard.

Are you missing senior executive support? Need some help building the ITSM business case?  Perhaps you need to identify and define services?  Tedder Consulting can help – contact us today!

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

Photo Credit:  Pixabay

[1] ITIL is a registered Trade Mark of AXELOS Limited.

[2] https://en.wikipedia.org/wiki/Information_technology_operations , retrieved 10/28/2017.

[3] http://www.computerweekly.com/blog/CW-Developer-Network/What-is-IT-operations-management

 

Share twitterlinkedinmail

The Five Decisions your business makes every day about your IT Organization

Share twitterlinkedinmail

Your business is making decisions about IT. Everyday. From board meetings to daily interactions.

What are those decisions?

  • Invest – A great outcome for IT. The business is willing to spend more or invest new monies into IT. Perhaps the investment is to achieve competitive gain or advantage or enter into a new market space. Regardless, a decision of “invest” indicates that IT has proven itself to be a good partner and a good steward of corporate assets.
  • Use and Maintain – Also a great outcome for IT. Solutions provided by IT are working and IT has proven itself to be a reliable service provider, always ready to help.
  • Leverage and exploit – Another great result. The business envisions ways to use IT to break through business barriers through innovative uses of existing (and perhaps, new) technology. IT is seen as a strategic asset and differentiator.
  • Retire – A ‘retire’ decision could be good…or bad. ‘Retire’ is a good decision when the business recognizes that a solution provided by IT has reached the end of useful life. A ‘retire’ decision is even better when those solutions are being replaced by a new IT investment. But ‘retire’ could be a bad decision for IT, if investments in IT have not realized expected returns or continued use of an aspect of IT is deemed problematic.
  • Avoid – The worse decision for IT. A decision of ‘avoid’ says that IT is just not responsive, provides little or no value, or is just too hard to do business with.

What decision did your business make about IT today? What information did the business use to make that decision? What part did IT play in that decision? Did IT even have a seat at the decision table?

Is technology just a “business tool”?

From a business perspective, technology is a tool that can be used to drive value, increase productivity, or reduce costs. It’s gotten to the point where, just like buying a cup of coffee, a business can get technology in about any flavor it wants — anywhere. Just look at the number and variety of “-aaS” businesses that have emerged over the past few years. Moreover, many aspects of technology have become highly consumerized. This consumerization is evidenced by the ease of use and ubiquity of technology solutions such as smartphones, laptops, tablets, public Wi-Fi – even things like home networking, website construction and cloud storage. The question has become “why should the business get its technology from your IT organization?”.

Should technology be more than just a business tool? Does your IT organization want to be more than a tool? Shouldn’t IT be seen as an asset to the organization?

Making the IT organization a “strategic asset”

If something is to be considered an asset, it must have tangible value. But “value” is tricky, because it is a subjective thing. Value is a perception – the perception that what is received is worth more than the investment and costs it required to receive it. Value is not just about the dollars and cents. Who decides the value of IT? The business that IT serves–not IT. So, how can IT be proactive in influencing that decision?

Defining services, in terms of business value and outcomes, is a critical first step for proactively influencing business decisions about IT. When IT doesn’t define its services in terms of business value and outcomes, it doesn’t help itself. In fact, without such service definitions, IT hurts itself because it commoditizes and obscures what it does. Because a clear mapping of how IT services enable or support business value chains doesn’t exist, the impression of business partners is often that the technology needed by the business can simply be obtained anywhere.

Defining services is crucial for influencing business decisions. But it can’t be the only step.

What decisions do you want your business to make about IT?

What else can IT do to positively influence the everyday decisions that business is making about the IT organization?

  • Look at and manage IT as a portfolio – Many IT shops are managed from a list of projects, an annual budget, and an organization chart. As a result, there is little consideration for the strategic use of technology – it’s more about getting projects done within allocated resources. Without portfolio management, those projects often compete for the same resources and in some cases, those projects actually deliver opposing outcomes. Portfolio management takes a different approach through the application of systemic management of the investment, projects, and activities of IT organizations. It formalizes the strategy for the use of technology, and as a result, helps business realize the right returns for the right investments in IT.
  • Establish or enhance your business relationship management (BRM) capability. A BRM capability enables IT to proactively promote its value across the business. The four pillars of BRM –Demand Shaping, Exploring, Servicing, and Value Harvesting[i] – helps businesses realize value by surfacing demand, identifying value, effectively servicing to meet demand, and ensuring insights into and continual improvement of value within the IT portfolio of services, capabilities, and products.
  • You tell the story – don’t just leave it for someone else to do. Be an ambassador for your IT organization. How? By understanding your company’s mission, vision, and goals (MVG), and then identifying for yourself how IT contributes to the achievement of the MVG. But don’t stop there – identify how you and your contributions contribute to MVG. When your story becomes personal, it becomes much more compelling and powerful for those that hear it.

If IT does not tell its story – someone else will. And that story may not reflect the value that IT is delivering. By defining services in terms of business value and outcomes, managing IT as a portfolio, leveraging BRM, and each IT team member being a brand ambassador helps IT tell its story and positively influence the everyday decisions business partners make about IT.

Can your IT organization tell its story – in terms of business value?  Do you know how IT delivers business value?  It’s not about  taking calls at the Service Desk or producing reports – it is about services defined in terms of business value and outcomes.  If your services aren’t defined in this manner, Tedder Consulting can help.  Want to know more? Contact Tedder Consulting today!

 For more pragmatic advice and service management insight, click here to subscribe to my newsletter! If you found this article thought-provoking, please comment below!

[i] Business Relationship Management Institute, “The BRMP® Guide to the BRM Body of Knowledge”, Van Haren Publishing, Zaltbommel, Netherlands. 2015.

Share twitterlinkedinmail

Six PDG (Pretty Darn Good) Reasons for IT to (truly) define Services

Share twitterlinkedinmail

How would you answer the following question?

“How does your IT organization deliver real business value?”

In the October 6, 2016 CIO.com article, “Business value is key to IT success”[1], Mike Sisco describes business value as including five very specific things:

  1. Increase revenue
  2. Decrease cost
  3. Improve productivity
  4. Differentiate the company
  5. Improve client satisfaction

Does your IT organization have a role in delivering business value? Sure, it does. Does your business know what IT does to deliver business value? Unfortunately, in many businesses, the answer is “no”.

Is it the fault of our business colleagues that they don’t know what IT does to deliver value? In my opinion, it is IT’s job to educate the business regarding how it delivers value.

Can your IT organization articulate how it delivers business value? That’s often the challenge with many IT organizations, especially if they’ve not defined services in terms of business value and outcomes.

Services are about “outcomes”, not “things”

Too often, IT organizations will list things like PCs, application access, and password resets as its “services”. Do these things provide (some) value? Yes. But are they services? No.

A service is a means of delivering value for a customer (or business) by facilitating outcomes (or results) the customer wants to achieve[2].   I’m sure you’ve heard or read that definition many times before, but what does it mean? Think about it this way: A PC without application software, network connectivity, and the like does not facilitate an outcome. In fact, in such a scenario, a PC is nothing more than an expensive paperweight. But include the PC as part of a value chain (comprised of software, infrastructure, processes, and people) that results in increased company revenues or improved productivity or client satisfaction, and wham! – you’ve got yourself a service!

Many IT organizations struggle with the critical, fundamental concept of defining its services. The IT organization is unable to identify and map the combinations of people, process, technology, and suppliers – or value chains – that work together to deliver business value and outcomes. Because these value chains aren’t identified or defined, the IT organization struggles to articulate how it delivers value. As a result, IT is often left out of strategic business discussions.

Instead, many IT organizations list the things they do as its “services”. But when an IT organization lists “things” as services, it sends a distinct message to the business it serves. The message? “Welcome to IT – we are here to take your order”.

Is that how you want IT to be known within your company – just as “order takers”? If so, prepare to be outsourced – because by only listing “things” as “services”, you are describing IT as ‘cost’, and not as ‘value’. And your business will look to increase value by reducing cost – in this case, the cost of its internal IT – because it can get those “things” cheaper elsewhere.

Six PDG reasons to define services

Why define your IT services? Here are six PDG (pretty darn good) reasons:

  • Provide transparency into IT – Demystify what IT does, while at the same time, relate IT deliverables to business value and outcomes.
  • Identify what really needs to be managed – Too often, IT organizations attempt to control everything rather than manage the right things. By defining services, what really needs to managed in a CMDB and controlled through appropriate change management can be identified.
  • Enable management of IT as a portfolio, not as a “collection of things” – IT should be viewed as at a strategic investment, and therefore, should be managed as a portfolio. This means that investments in IT should be based on matching those investments to business objectives, developing policies that enable good decision-making, and balancing risk and reward. IT never has an opportunity to be managed as a portfolio if services are not defined.
  • Enable cost modeling – By identifying and understanding what makes up each service, needless redundancy and obsolescence can be identified. By eliminating this redundancy and obsolescence, IT reduces its cost – without impacting quality or results. Cost modeling also facilitates “like for like” comparisons of service solutions and “build vs. buy” decisions.
  • Enable the business to take advantage of IT services – Services provide value by facilitating outcomes. The more business can take advantage of the outcomes of IT services, the higher the value of IT. Defining services not only articulates the IT solutions available to meet business needs, it also aligns IT to business outcomes and helps lead IT in creating business value.
  • Get IT a seat at the table – Defining services helps both business and IT understand the role that IT plays in enabling and delivering business value chains – the activities within a company that result in a product or service that delivers value to a customer. Having the ability to discuss its services in terms of business value will help get IT a seat at the business strategy table.

Define your Services…or else!

So how can you define your services? Start by getting the answers to these questions:

  • What does your business do?
  • What are the activities within your business that result in a product or service that delivers value?
  • How does IT enable or support those business products or services?
  • What are the combinations of technology, process, people, and suppliers that enable or support those business products or services?

Getting the answers to these questions not only will help you define your services, it will also help you articulate how IT delivers real business value.

Want to get started, but don’t know where to start?  Perhaps a quick chat would help!  Click here to schedule a free, no obligation 30 minute session to talk about defining services at your organization.

Image Credit: Olivier Le Moal

[1] http://www.cio.com/article/3128724/leadership-management/business-value-is-key-to-it-success.html, retrieved 12/12/2016.

[2] ISO/IEC, (2011). ISO/IEC 20000-1:2011 Information technology – Service Management – Part 1: Service management system requirements. Geneva, Switzerland: ISO/IEC.

Share twitterlinkedinmail

What message is your Service Catalog sending to your business?

Share twitterlinkedinmail

ISO/IEC 20000:1, the Information Technology Service Management (ITSM) standard, defines a service as a “means of delivering value for the customer by facilitating results the customer wants to achieve.” ISO 20000 continues by stating that a service “is generally intangible”. [1]

In other words, services do not sit on shelves.

Yet many ITSM vendors would have you believe that their tool provides a “service catalog”, when what is really being provided is “request fulfillment”.

Don’t misunderstand – your IT organization can realize significant efficiencies from defining and publishing request models within a centralized portal. But recognize that what you’re doing is not a service catalog. Your portal is providing access to products or activities – service requests – managed via the request fulfillment process – that provide the means to consume a service. The product or activity itself is not a ‘service’.

Why understanding ‘service’ vs. ‘service request’ is so important

Services are the critical foundation for the relationship between IT and the business it serves. When services are described in terms of business value and results, IT is able to articulate how it provides benefit in terms that the business understands. Defined services are outcomes of business strategy – the plan for how the business intends to achieve goals and objectives – and how IT will support achieving those business goals and objectives. By defining services, IT illustrates its capability and readiness to be a strategic partner to the business.

Service requests, on the other hand, are simply a means of achieving those business objectives. Strictly speaking, it really doesn’t matter what brand or type of PC that is being used to access a service. It’s the use of the service – the realization of value and outcomes – enabled by using the PC that actually provides the business value.

Why is understanding the difference between ‘service’ and ‘service request’ so critical? One answer is the difference between an IT organization that is recognized as a ‘strategic business partner’ versus an IT organization that is perceived as an ‘order taker’.

A simple example

Think about the following products: a PC, a MacBook®, an iPad®[2], and a Microsoft Surface®[3] – perhaps all suitable entries in a company’s service request portal. Why would a consumer choose one of these products over another for use with his job? Perhaps it’s the form factor. Or maybe it’s personal preference. Perhaps it’s dictated by a company standard. Maybe it’s the color of the device.

Whatever the reason, can any of the devices listed above just be delivered to the consumer – out of the box – right from the shelf? Basically – no. Most companies require some sort of device protection to be installed – whether that’s simply a userid/password combination or some kind of security software. Then there’s configuring access to the corporate network, without which, none of the devices listed would be useful for the consumer for doing work for the company. Of course, the consumer will need to use corporate applications ranging from email to CRM systems.

Does the device itself deliver value by facilitating the results the consumer wants to achieve? Without the use of appropriate security measures, combined with access to the corporate network and email and CRM systems, the answer is “no”.  So, is the device itself a ‘service’? No.

If this sounds like what was implemented with your ITSM tool’s “service catalog”, do you really have a service catalog?

Move from ‘Order Taker’ to ‘Strategic Partner’

To be clear, I’m not suggesting that you “turn off” your service request portal. But what I am advocating is take what you’ve defined in your request portal and look at each item from the perspective of business value and business outcomes.  By doing this, you’ll be enabled to begin to move from the perception of ‘order taker’ to becoming the strategic IT partner for your business.

To start the move to ‘strategic partner’, answer the following questions for each entry in your request portal (I will use a service request for a PC as an example):

  • How is the requested product or activity being used? A PC is used for multiple purposes – access email, use personal productivity tools, access to corporate systems.
  • What are the technologies and activities involved with fulfilling the request? The PC requires software installation, configuration, physical installation, network connectivity, shared file system access, and other technologies and activities before it can be made usable.
  • Are there any dependencies or relationships between this request model and other request models? Perhaps the PC user also needs access to corporate systems, which may be handled by other service requests.
  • What is the ultimate outcome or result from the fulfillment of this request? Using the PC enables personal productivity for the consumer, which enables her to fulfill her job responsibilities.

As you get the answers to these questions, you will start to recognize similarities in outcomes or dependency patterns – indicators of the value chains that constitute services. Review these dependency patterns to identify the path that outcomes follow from the point(s) of origin to the point(s)  of business value realization  to complete the value chain. When you’ve done that, you have begun to identify services.

Workshops from Tedder Consulting can help you identify and define Services, develop your Service Catalog, and enable your Request Fulfillment process!  Want to know how? Contact Tedder Consulting today for a free 30-minute consultation!

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

Photo credit: conrado

[1] ISO/IEC, (2011). ISO/IEC 20000-1:2011 Information technology – Service Management – Part 1: Service management system requirements. Geneva, Switzerland: ISO/IEC.

[2] MacBook® and iPad® are registered trademarks of Apple, Inc.

[3] Microsoft Surface® is a registered trademark of Microsoft Corporation in the United States and/or other countries.

Share twitterlinkedinmail

The ITSM Paradox

Share twitterlinkedinmail

Paradox [par-uh-doks] noun

  1. A statement or proposition that seems self-contradictory or absurd but in reality expresses a possible truth.[1]

Example: The paradox of many IT Service Management (ITSM) implementations is they actually do not manage IT services.

Many organizations have invested time, energy, and money into establishing ITSM. But in a large number of organizations, the implementation fails to define the critical foundation for ITSM – the identification and definition of IT services.

What have these organizations done? Usually, they’ve bought a tool, deployed a self-service portal, called that portal a “service catalog”, and have listed applications, activities, procedures, and products as “services” within that portal.

Applications, activities, procedures, and products are not services. When companies have done it this way, they have neither a “service catalog” nor have they defined “services”.

What is a service?

A service essentially is a means by which the business or a customer receives value in the outcomes they receive from a service provider. The customer or business does not have to be directly concerned with the combinations of people, processes, technology, and vendors that work together to deliver those outcomes that result in value.

Think about it. For example, a smartphone without the underpinning communications network, suppliers, software, applications, and technical support is nothing more than an expensive paperweight. A password reset might allow the user to access an application or the corporate network, but then what?

By properly defining services, the IT organization demonstrates that it understands what outcomes are needed by the business. Properly defining services illustrates that IT understands what the business values and how what it does delivers those values and outcomes. But that’s not all. By properly defining its services, the IT organization also answers the question “why should the business get its IT services from us?”

Unfortunately, many IT organizations are unable to answer that question, because they’ve only included activities and products in what they are calling a “service catalog”.   While these activities and products are important, they are not services.

What is the impact?

When the IT organization does not define services that reflect business value and outcomes, but rather defines the activities, products, and tools they provide as “services”, here’s the impact:

  • IT becomes commoditized. Let’s face it- the business can get smartphones and laptop computers anywhere. If all IT does is reset passwords, develop applications, and install software, those activities can be outsourced. Define services in terms of outcomes and value and avoid becoming a commodity.
  • IT is perceived as a ‘cost center’ and not a ‘value-enabling partner’. Value is only realized when a customer feels that the benefit it receives from something outweighs the cost of getting it.   By not defining services, IT never enables or promotes the value of what it does. From the business perspective, IT just looks like cost.
  • ITSM cannot meet its potential. Defining services enables the operational aspects of ITSM. Services become the basis for categorizing incidents and requests, provide the blueprints for what CIs should appear in the CMDB, and help enable business-meaningful service level agreements. But it goes much further than that. Defining services enables the business to look at its IT service portfolio and understand its IT capability and how to leverage it. Defining services enables strategic discussions regarding how business can take advantage of advancements in technology while at the same time, ensuring that IT is delivering value now. With properly defined services, IT becomes a strategic asset of the organization.

Break the paradox

Because no two organizations are alike, identifying and defining IT services is a mix of science and art. Having said that, there are some key concepts that will help.

  • Look at the business from the perspective of its customers. What does the customer of the business get? How is value delivered to the customer? Once those two questions are answered, identify how IT contributes to or enables that delivery of value.
  • Just because your name appears on the IT organization chart doesn’t necessarily mean you’re providing a service. A frequent mistake by many organizations is using the organization chart as a guide for identifying services. The delivery and support of a service often involves multiple people from across the organization. How are the people on the organization chart working together to deliver the outcomes that are valuable to the business?
  • A service must “make sense” to the business. In my experience, IT tends to talk to itself about how the business uses IT, rather than talk to the business. Who better knows the requirements, needed outcomes, and what is valued by the business than the business? By engaging your business in the identification and definition of IT services, your service definitions make sense to the business and better partnerships between the business and IT will result.

Are you managing activities or services?  Does your business need for IT to make the shift from “cost center” to “value partner”?  Tedder Consulting can help with defining services, designing effective processes, and changing the perception of the IT organization.  Let’s get started – contact Tedder Consulting today!

 Don’t miss my future blog posts!  Click here to subscribe to my newsletter!

[1] www.dictionary.com, retrieved 6/5/2016

Share twitterlinkedinmail

Are you buying the bike or the result?

Share twitterlinkedinmail

What are some common uses for an exercise bike?

  • Use the handlebars to hang clothes upon
  • Use to collect dust
  • Use as an uncomfortable seat while watching TV or reading a book
  • Use to maintain or improve muscle tone and cardiovascular function

Let’s consider for a moment that you bought an exercise bike for the last reason – to use to maintain or improve muscle tone and cardiovascular function.  Why is this important?   Because you wanted to achieve some result or outcome.  Perhaps you wanted to lose some weight.  Or maybe your doctor recommended a program of diet and exercise to help reduce the risk of a heart attack. Perhaps having an exercise bike gave you a way to exercise during inclement weather.   Maybe you just wanted to feel better.

How do you know that you’re achieving your desired outcome?    Is it the amount of time you spend on the exercise bike?  Well, if you’re only sitting on the bike while you’re watching TV, that’s probably not a good indicator of achieving the outcomes you wanted.  Is it the number of revolutions that the bike’s wheel turns while you’re pedaling?   While that would indicate (proper) use of the bike (versus using the bike for hanging clothes), just pedaling without adding some resistance to the wheel may not enable your achievement of the desired outcome.

Is riding an exercise bike the only way to achieve the outcomes I listed above?  No.  You could regularly participate in an aerobics class or racquetball league at your local health club.  Or you could jog daily, regardless of the weather.  There are a number of ways to be enabled to achieve the outcomes you want – using an exercise bike is just one way.

Now put on your ITSM hat.   Is the exercise bike the “service”, or is it a means to consume or utilize a service called “Personal Fitness Services”?  Does the provisioning of an exercise bike alone provide the valuable outcomes that you identified?   Does the number of revolutions on the bike indicate achievement of the outcome, or just the use of the bike?  How should achievement of the outcome be measured?

The concept of a “service” is the core, fundamental concept of an ITSM implementation, but too often, this is where so many ITSM implementations “go off the rails”.  If you don’t identify, define, describe, and measure services in terms of the outcome and the value to the business, your ITSM implementation will not achieve its full potential.  In fact, I would even argue that if you don’t get the concept of “service” right, your ITSM implementation will (eventually) fail.

Too many ITSM implementations focus only on the operational aspects of a service.  They focus only on the “what” and “how” and give no thought to the “why”.  The emphasis is often on implementing some kind of tool so that IT can manage tickets, without taking the time to understand the value and outcomes of what IT provides to the business.

As a result, a tool gets stood up fairly quickly and IT does experience some success.  Incidents are captured and (many are) resolved, requests are routed and fulfilled, and life in IT seems good.  Then IT decides that it wants to exploit its new ITSM capability and become more proactive.  IT wants to move beyond password resets and resolving server failures and understand the business impacts of requests and issues.   And then IT hits a wall.  Because IT did not take the time to understand the “why” and map the value chains of how the various components, processes, and teams of people work together (oh, by the way, “processes” and “people” will never appear on a discovery!) to deliver those outcomes required by the business.  The IT organization will struggle to evolve from reactive order-taker to a proactive business partner.

Or perhaps the business needs to reduce cost and before cutting costs in IT, wants to understand the potential impact of any cost reductions.   Perhaps the business would like to leverage existing services to improve enterprise efficiency and effectiveness and is looking for IT to lead the way. But because IT never took the time to define its services beyond “we provide exercise bikes”, IT is not prepared to step up to help the business.  If only IT had taken the time to identify its services in terms of value and outcome – “Our service helps you achieve and maintain a healthy lifestyle, which will keep your healthcare costs down and improve your overall well-being” – the IT organization could lead the way.  Instead, IT becomes a bystander.

This is why identifying and defining services is so critical.  The business really does not care what specific softwares and hardwares are being used.  The business really doesn’t want to learn how to speak geek. What the business wants is to understand – in business-relevant terms – is what IT does to deliver or enable outcomes required for business success.  What is the value that IT provides to the business it serves?  How can the business leverage IT to drive new lines of business and competitive differentiation?   How can IT be used to drive efficiency within the business?

But too often, IT doesn’t take the time to identify, define, and understand its services in terms of value and outcomes.  Why?

Click here to subscribe to my newsletter!

Share twitterlinkedinmail