The Complete Blueprint for Aligning Your Service Desk and Development Teams (Process Integration and Best Practices)

If you are working for an IT organization, you are most likely either part of the support team or development team. You also most likely will recognize some or all of the following friction between the teams in your respective role.

The friction from the Support side

As a SUP, you are supposed to answer all questions about a critical application. One day you get a lot of calls from users, complaining that the behavior of the application is changed. You know that a project has released new features, but you don’t know the details. So you can’t tell the user whether the changed behavior is desired or a bug.

You also know a lot of applications quite well, but you’re not a complete expert in any of them. Sometimes you get issues from users that you can’t solve. Sometimes you get requests to change things in an application. So, what do you do?

For one application you know a guy from the development team who can help. But he is busy. So you can’t tell users when you can get their issue solved.

The friction from the Development side

As a DEV, you are eager to develop new features in your specialist area. But
you are annoyed to also get banal questions, for which you really don’t have time.

You might most probably be working on some exciting new features. The deadline for release is close. All of a sudden you get word that there is an urgent change needed in existing functionality. What do you do first? Who can decide?

If you do recognize these frictions, you are working in an IT organization where the Support and Development processes are possibly disconnected.

In this blog post, we will discuss some ideas to integrate these processes and avoid friction altogether.

Note: You can use Exalate for an integration between support and development teams. Exalate is a cross-company integration solution that allows you to integrate data between a variety of work management systems and issue trackers.

The Development Process

Development can be further distinguished between Software, Product, or Service Development. The process for each development type can deviate a bit.

However, core process steps are the same. For the sake of simplicity, we will focus on the Software Development Process, which includes 6 main steps:

1. Planning: To gather requirements from customers and stakeholders, to establish a business case and to determine the project approach
2. Analysis: To analyze requirements; feasibility studies; to analyse impact/improvements on the current systems. And to produce a SW Requirement Specification
3. Design: To determine the architecture, design modularity, data flow etc. And to produce a detailed Design Specification
4. Implementation: to do actual coding and unit testing according to the Design Specification
5. Testing & Integration: To establish a test environment. To conduct functional testing and user testing. And to solve issues that appear
6. Maintenance: To release the product to customers and to gather Issues and Enhancement Requests. This is an ongoing step to keep the Software relevant and high quality.

The circle depicts that this is a continuous process. One development cycle is usually achieved in a Software Development Project. The Project can be managed based on Prince 2 or Agile (Project management methodology is outside the scope of this guide though).

Note: Learn more about Scaling Agile Basics and the most useful frameworks.

The Support Process

The support process is a general term used to depict the activities that help the users of a Software/ Product/ Service.

Most companies define their support process based on ITIL Best Practice for IT Service Management.

ITIL (IT Infrastructure Library) is an extensive framework of best practices to manage IT services. While it is not practical, nor advisable to implement the ITIL process all at once, the processes linked to support activities are often implemented first. These are Incident Management, Problem Management, Service Request fulfillment, and Change Management.

Incident, Problem, and Request management are part of the Service Operation. While Change Management is part of the Service Transition. Among these 4 processes, Incident Management is implemented first in most organizations.

The Need to Integrate the Development and Support Process

From the above overview of the Development and Support process, it is evident that the Development processes for a Software/Product/Service are inter-connected with the Support processes.

• The maintenance step of the Development process overlaps with the activities defined in the Incident/Problem/Request process. 
• The Incident & Change Processes provide inputs to the planning step of the Development process

Process Integration: Problems and Solutions

The Development Process and the Support processes, based on ITIL, have already been established a long time ago and have been successfully implemented in many organizations. Yet the friction described in the first section of this guide is often encountered.

So, what can go wrong while implementing these well-known processes? As it turns out, a lot can go wrong. In the following, we will discuss some common pitfalls and possible solutions.

Breaking Organizational silos

Why Organizational silos occur

When we talk about processes, we also talk about Process Roles. A process
role defines the activities a person with the role needs to perform in the context of a Process.

However, every person in an organization also belongs to a team with a job title. Companies often have separate development teams and support teams, with development teams likely being part of Competence Center, and support teams likely being part of the Operation or Service Department.

A development team is likely to be dedicated to a single Software/Product. While a support team is likely to be customer-facing, covering several Software/ Products.

This organizational setup could induce the teams to implement their processes in an isolated way:

• ƒ  The Development process has a Maintenance step, but the Development team treats it as being covered by the Support team and, in turn, has
  no resource allocation for it.
• ƒ  The Development team has the deep knowledge about a certain SW/ Product. But it is not involved in the Incident and/or Problem Management process when such deep knowledge is needed.
• The Support team has no roles in the Development Process. This gives the feeling that Projects cook things up and throw it over the fence when finished. That leaves the support team to clean up the mess.

How to break Organizational silos

The way to break the organizational silos is to implement process and process roles across these teams. You will have to assign Process Manager roles to be responsible for the end-to-end process.

In practice, the following setup should help. For the Support processes, ITIL recommends a 3-tier support structure:

• ƒ1st line (Service Desk) is SPOC (single point of contact) for all IT Services and part of the Support team or outsourcing partners
• ƒ2nd line support, a cluster of IT Application/Services, is part of the Support team
• ƒ3rd line support has expert knowledge of a SW/Technology. It is part of the Development team. The 3rd line support role is typically involved in Incident resolution, Problem root-cause analysis and Change implementation.

The Development team assigns clear support roles and reserves resources. This reservation must not be taken by the project. Process Manager roles need to be assigned to the Support team.

But these roles have end-to-end Process responsibility. I.e. an Incident Manager is functionally responsible for 3rd line support performance.

For the Development process, support teams have to be involved in the following steps:

• ƒPlanning: the Change Manager from the Support process is one of the stakeholders to raise requirements.
• Test and Integration: 2nd line support is part of activities to set up the functional/ user test environment and will be the coordinator of UAT.
• Maintenance: The Change Manager (or Release manager if implemented as an ITIL process) is involved in deciding on the go-live criteria and timing, to minimize the impact of the project go-live to the live environment.

Breaking Information Silos

Why Information silos occur

The divide of Development/Support teams is often reflected in separate toolsets used to execute the processes and to store information/knowledge.

This adds to the barriers in Process integration.

Support teams generally choose an ITSM tool, with an end-user interface that handles each process with a corresponding ticket and workflow.

Development teams, on the other hand, generally choose a Project management /SDLC tool where each process step produces a number of documents specific to that step.

Enduser & IT Support knowledge is stored on ITSM tools, owned by the support team. Functional & Design teams will document on the PM tool, owned by the Development team. Without consulting each other, the content becomes outdated over time.

Development and Support processes use different terminologies. E.g. Incident vs Defect, Change vs Enhancement, etc. . When an Incident needs to be handled by the Development team, it has to be transferred over to another system & becomes a Defect.

How to break Information silos

The way to break these information silos is to align the tools used for their respective Processes. There could be several ways to achieve this. Following are some scenarios.

Ideally, implement both ITSM and PM on the same platform. In this case, both Development and Support team works in the same tool. That means:

• ƒ No tool barrier for Development teams to fulfill their roles in the Support processes & vice versa.
• ƒ All information is stored on the same platform i.e. Support teams can easily consult the Project status or check included functionalities in a project release. Development teams can check the Incidents caused by a Project Change.

The above scenario is, however, not always feasible. The reason could be that the tools are already established and migration is too costly. Or there is no agreement on common tools. Or teams flat-out prefer different tools.

Another reason could be that a part of the Support and/or Development work is outsourced and the outsourcing partner is using a different tool. In this scenario, integration needs to be implemented between the tools to reduce the barrier and increase the efficiency of the teams.

• ƒ It needs to carefully considered which processes are executed in both tools and how an integration can make the process execution seamless across those tools.
• ƒ The integration technology applied needs to be Secure, Flexible and reliable. Otherwise the integration will hinder process integration more than help overcome it.

Let’s Verify the Process

Having discussed the process issues and solutions, we would like to get back to the frictions listed at the beginning of this guide and check whether our proposed solution can help avoid those issues.

This is what it will now look like from the support side:

• As a SUP you would not be surprised if a lot of users call after a project goes live. You were involved in the User Acceptance test and know what new functionalities are released. You can explain to the user whether it is indeed an Incident or just a new feature.
• As a SUP you get an Incident about an application which you can’t solve. You assign the Incident to the 3rd-line support team, these are experts of this application. Because it is a high priority Incident, it is picked within 30min as defined by the SLA

This is what it will now look like from the development side:

• As a DEV you are allocated 20 percent of your time to do 3rd line support work. You also work on a project. But your project manager will respect the time you need to spend on support in his planning.
• As a DEV you need to work on an Emergency Change, although you also have a project deadline. But you know this is agreed between the Change Manager and Project manager, defined by the SLA.

Conclusion

There are many touching points between Development and Support processes. It is important to avoid silos in the process, teams, and tools. We discussed how you can break Organizational silos using process and process roles, based on ITIL best practices.

We also covered how you can break Informational silos by having teams in the same environment or by integrating their tools effectively. (note that you can use Exalate to set up such an integration)

Defining an integrated process with the support of integrated tools and clear process roles in the teams is the way to make both Development and Support a success for your customers.