Author: contributor

One of the great misconceptions of service management is what it means. This also is the reason why so many service management initiatives fail. Consider a call center, for example, with many people answering phones and replying to emails. It’s true that a service desk is one of the functions (and in some organizations, maybe even a cornerstone) of service management. It’s also true that the customer or user is one of the main characters in the story of service management. The very word “service” implies there is a customer at the end of that service.

However, service management is, at the very core, about designing, delivering and redefining services to the customer base—whether those are internal, external or occasional users of the service. User roles may vary over time and users may become part of the supplier chain, and vice versa. A great example of this is knowledge management, wherein users are typically both consumers and producers of information and, thus, the service.

When we take this higher-level view of the service management practice, our eyes open to new possibilities. In particular, we can see beyond the service desk. The scope of service management widens to the end-to-end delivery of the services in question, retaining the focus on the customer.

Finding the Cure: It’s All About the Customer, and Communication

The happy medium and the much sought-after goal of the harmonization of service management and DevOps can be achieved when stakeholders find common drivers. In both worlds, the respective goals focus on the business, delivering value and doing so quickly.

The following sections present actionable recommendations that can be implemented incrementally across the entire organization. They offer a bottom-up approach. In conjunction with implementing them, senior management needs to support the culture change that is a vehicle, a catalyst and a byproduct of the improvements. In this way, the full benefits of the changes can be analyzed and achieved.

Tip 1: Stop playing ping-pong with issues

We’ve all identified an issue with a system, logged it with IT as a ticket and received updates of the progress while the ticket is handed over from team to team—only to discover weeks later that the development team knew about the bug but had de-prioritized it due to lack of interest.

Surely, by the time the final bit of information reaches users, they are less than satisfied with the result. What’s more, the organization has wasted everyone’s time, not least the time of network, storage and other team members who had to prove it wasn’t their fault in the first place. Finally, development team members could have prioritized their work correctly if they had known about the customer need in the first place.

With so many implications in the above scenario, why does this happen? The reason is simple: less than optimum process interfaces and lack of information flow. When you’ve identified the problem, the solution is easy: Include relevant data from the development teams, such as defect information, in your chosen IT service management solution.

Sometimes, the easiest way is to integrate the defects created in development’s chosen tool set to IT service management’s “problem” records. This way there is no need to change the processes per se, as problem records can be linked to issues (or incidents) easily in the service management tool. The integration simply allows for the information to flow between systems and enables a collaborative approach to issue handling.

In this scenario, when the development team opens a defect, it creates a problem record in the service management system, which, if feasible, could be displayed automatically to users on a self-service portal. Thus, users can search known errors before logging a ticket, resulting in time savings across the whole organization.

Tip 2: Communicate bugs and known issues to everyone impacted

But what happens when a user finds a new issue that has emerged due to a bug that has yet to be discovered by developers and testers? Traditionally, the user might log a ticket, which is then analyzed by the IT service team and forwarded to developers for analysis, coding and testing. That might be last of the ticket the user sees, as the feedback loop often is missing.

The benefits of forwarding the defect information from the user to developers are realized only when there is a way to easily track the whole life cycle of the issue regardless of where it has been initiated. Instead of batch importing records from one system to another, the most advantageous way is to mirror the record sets in the two systems.

In this example, the feedback loop between the customer and the service desk to the development team is achieved when synchronizing problems and defects in the two solutions.

Tip 3: Empower the customer by crowdsourcing bugs and new features

One key metric that contributes to employee satisfaction and retention is the ability of employees to do their jobs well. To accomplish this, they need resources. When employees have all the resources they need to do their job well, more often they are happy than not.

We are all dependent on technology; there are few professions that do not require technical resources to perform their jobs. If there is a hiccup in the finance solution, for example, the finance assistant may well be the first to find an issue after a version upgrade. Or, a team-wide brainstorming session may result in some great “if-only-our-analytics-software-could …” ideas of how to improve the efficiency of the team.

But how best to communicate these issues, and capture the many ideas? Possibly, you might even perform real-time impact analysis on which improvement ideas are important to various business processes, and communicate the urgency of each one to the development organization. The inherent problem in many organizations is that users have only one touchpoint to the “DevOps cycle,” most commonly through the IT service management practice. Meanwhile, the rest of the IT organization may use a number of disparate systems to communicate and assign current work tasks that form a basis of shipping new features and functionalities.

Again, it may be useful to look at the tools already employed throughout the organization, and understand the existing processes and practices. Understanding team functions is important as well, though many teams are fluid in their roles and tool sets used. Once relevant tools are identified, look for mutually beneficial interfaces between them to ensure that users’ requests for new features are not forgotten but logged and picked up by the development team.

In this example, you could integrate a tool that supports the back office (such as a defect management tool) and tools that support users (such as requirements management and project management tools). This allows you to effectively crowdsource and track upcoming features and bugs, keeping the whole organization informed.

Tip 4: Don’t forget suppliers

Include the entire software supply chain in the equation. After an era of outsourcing, insourcing, and multisourcing, many organizations have a diverse supply and sourcing strategy. One of the main reasons for this is to manage risk and ensure business continuity.

Thus, the last remark is to ensure that all the above examples work in a multisupplier environment. This typically involves contractual preparation. New frameworks such as service integration and management (SIAM) help identify risk and reward in supplier collaboration. These are useful tools for both IT service management and DevOps practices.

A great example of supply chain integration is an end user reporting an issue. Once it has been reported, it is then centrally analyzed to find the root cause of the issue and the underlying problem is routed to the correct supplier automatically. By synchronizing the information between supplier and customer, not only is each party kept up to date about current issues, but the pipeline and project customer demand are built by integrating incidents, projects and requirements across the software supply chain.

One of the core aims of both service management and DevOps initiatives is to respond to customer demand as quickly and effectively as possible. Real-time synchronization between solutions is merely a technical solution, but one that has true potential to elevate the response speed.

Reflections

Having examined the above four ways to improve the collaboration of DevOps and service management, there are clear solutions to reforming the partnership to drive quicker customer response and satisfaction. But be forewarned: The four recommendations offered are but advice to improve; an organization’s leadership must truly be committed to a culture change to make change happen.

About the Author /Tuuli Bell

Dr. Tuuli Bell is a Partner Account Manager, EMEA at Tasktop. She is a member of the BCS, the Chartered Institute for IT, and the Institute of Physics. For her, happiness is about discovering opportunities to challenge the status quo and about embracing change, be that organizational change, or professional or personal development. Tuuli’s interests outside work include art, science, and nature. Follow her on Twitter or find her on LinkedIn.