Build a Swarming Pilot Project

Optimize your service support and become more DevOps compatible.

Table of contents

1. Project Rationale
2. Execute the Project/DIY Guide
   • Phase 1: Assess Readiness
   • Phase 2: Create a Pilot
   • Phase 3: Build a Process
3. Bibliography
4. Next Steps

EXPERT PERSPECTIVE

The approach to service support may not be one size fits all.

“Support organizations with good self-service models are rethinking their support processes and moving from an escalation-based model to a collaboration-based model. They are collapsing their support tiers, creating a single team of people who collaborate on solving customer issues (playing catch). This is replacing the model of multiple teams that toss issues back and forth through incident routing, rerouting, escalation, and rejection (playing ping-pong).” (Greg Oxton, Executive Director, Consortium for Service Innovation)

Our understanding of the problem

This Research Is Designed For:

• The CIO and service manager who need to increase service support effectiveness and timeliness and improve end-user satisfaction.
• The service manager who wants to lead the team from a silo-heavy organization to a collaborative and customer-focused environment.
• The team that requires cross-functional collaboration and demands different skill sets.
• An organization planning to adopt and scale DevOps or Agile.

This Research Will Also Assist:

• Service teams who want to increase their own effectiveness and move from a help desk to a service desk.
• Infrastructure and application managers who want to decrease reactive support activities within the teams.

The tiered ticket lifecycle leaves gaps in customer service and exhausts your resources

Companies wanting to achieve a more DevOps state need to reconfigure their approach to service support

What is DevOps?

DevOps is an operational philosophy that seeks to promote an improved relationship between Development and Operations in order to break down existing silos and better align the groups in providing customer value.

Collaboration

Development and Operations working together through all stages of the development lifecycle, from design through the development process and into production support.

Communication

Prioritizing high-value modes of communication to break down existing silos and create common understanding and empathy across functions. This approach increases transparency and visibility across the entire development lifecycle.

Integration

Explore methods to integrate the workflows and toolsets between your development and operations groups to become more reactive to changes in business and customer expectations.

Introduce swarming to support the shift to a DevOps and Agile service support environment

How can DevOps help?

DevOps paves a targeted, yet flexible path for the future success of your organization.

It enables IT organizations to:

• Align to the overarching business objectives.
• Break down cross-functional silos and remove bottlenecks.
• Increase cross-team collaboration and transparency.
• Improve the quality and performance of applications.
• Enhance the customer experience.

DevOps has helped organizations realize the following benefits (Source: Puppet Labs):

• Increased release velocity
• Shorter lead times
• Reduced time to recover upon failure
• Improved defect detection
• Lower change failure rates
• Reduced deployment failures and rollbacks
• Increased collaboration
• Increased customer satisfaction
• Improved ability to innovate

Cisco, IBM, BMC Software, Microsoft, and Red Hat have seen massive improvements since adopting swarming practices

What are the benefits of swarming support?

Swarming support creates an atmosphere of collaboration, improving end-user satisfaction and reducing organizational costs.

It enables IT organizations to:

• Create a customer-centric approach.
• Collapse silos and remove bottlenecks.
• Streamline onboarding times and improve skills development.
• Bring development teams to the frontline of support.
• Reduce incident resolution time.

Swarming helps organizations realize the following benefits:

• Decrease onboarding times by 50%
• Faster incident resolution
• Streamline support processes
• Reduce the skills gaps
• Facilitate faster root-cause analysis
• Foster team spirit and skills development
• Increased collaboration
• Increased customer satisfaction
• More time for innovation

Swarming creates higher end-user satisfaction with all other IT services

Embrace collaboration.

• Improves the end-user experience.
• Alleviates the knowledge and skill dissemination between tiers.
• Decreases time and money spent on onboarding by 50%.

Increase business satisfaction.

• Improve confidence that the Service Desk can meet service levels.
• Create a single point of contact for incidents and requests, with technicians owning their tickets through to completion.

Align work with the right people.

• Eliminate the game of service support ping-pong by identifying the right agent to solve the ticket.
• Create visibility to all agents to allow them the opportunity to opt-in and help others solve tickets and foster opportunities for skill building.

Increase efficiency and lower operating costs.

• Empower end users and technicians with a targeted knowledgebase.
• Faster ticket resolution times.

Improve skills transfer.

• Swarming breaks down pesky silos and fosters cross-functional and cross-department learning and collaboration.

By conducting a pilot project you can reduce the risk and maximize stakeholder buy-in to swarming practices

What is a pilot project

A small-scale preliminary study used to assess the feasibility of an approach or project and test methods and procedures prior to being used on a large scale.

Why do a pilot project?

Pilot projects minimize risk, test and validate the benefit of swarming in your unique environment, and get stakeholders to buy into your project.

It enables IT organizations to:

• Validate cost savings and initial productivity.
• Minimize risk by being able to test a new approach in a controlled and live environment.
• Test and validate the efficacy of the program.
• Increase stakeholder buy-in.
• Verify the process is technically stable.
• Identify and address obstacles prior to full-scale implementation.

Info-Tech’s approach to incorporating swarming into your service support model is by creating a pilot project

BMC Software sets the bar high by changing the game of service support with Swarming

CASE STUDY

Industry Software
Source BMC Software

BMC Software

BMC Software is a multinational software company supporting approximately 96% of the Forbes Global 100 companies and 81% of the Fortune 500 companies. BMC produces software and services that assist businesses in moving towards optimized digital operations.

Swarming Initiative

BMC implemented swarming practices as an answer to the two key challenges it was facing: increasingly complex issues and the need to reduce interruptions to support analysts in the form of critical issues. BMC involved the entire team in developing the swarming process and started small with a pilot project as a proof of concept with only 14 people.

Benefits

Some of the key benefits BMC experienced after implementing swarming practices include freeing up managers’ time from being reactive to being able focus on development, fewer escalations to development, improved knowledge sharing, and significant improvement in teamwork and morale. (Source: Consortium, 2010)

Key Findings

• 8% higher customer satisfaction scores.
• 2x – Employees doubled their knowledge within a year.
• 25% faster mean time to resolve (MTTR).
• Reduced onboarding time by 50%.

Info-Tech offers various levels of support to best suit your needs

Diagnostics and consistent frameworks used throughout all four options

Build a Swarming Pilot Project – project overview

	1. Assess Readiness	2. Create a Pilot	3. Build a Process
Best-Practice Toolkit	1.1 Assess current state 1.2 Review swarming best practices 1.3 Identify benchmarks and metrics	2.1 Build the project plan 2.2 Build a communication strategy	3.1 Design swarming processes 3.2 Create an evaluation plan 3.3 Review support best practices
Guided Implementations	Assess current state of service support and collaboration. Review swarming best practices. Identify benchmarks and metrics.	Build your swarming pilot project plan. Build a communication strategy for your pilot.	Design swarming processes. Create an evaluation plan to measure success. Review support best practices.
	Phase 1 Results: Service desk maturity assessment Collaboration assessment Benchmarks, metrics, and reports	Phase 2 Results: Pilot project plan Communication strategy	Phase 3 Results: Swarming processes Evaluation plan to measure success Pilot project support plan

Info-Tech delivers: Use our tools and templates to accelerate your pilot project to completion

PHASE 1

Assess Readiness

Step 1.1 Assess current state

Outcomes

Alignment on the challenges that the service support faces, an assessment of the current state of service desk processes and technologies, and baseline metrics against which to measure improvements.

DELIVERABLES

• Service Desk Maturity Assessment
• Collaboration Assessment

Assess the process maturity of the service desk to determine if swarming is a viable option for you

Where do I find the data? Consult: Service Manager, Service Desk Tools

The Service Desk Maturity Assessment tool helps organizations assess their service desk process maturity and focus the project on the activities that matter most.

The tool will help guide improvement efforts and measure your progress.

• The second tab of the tool walks through a qualitative assessment of your service desk practices. Questions will prompt you to evaluate how you are executing key activities. Select the answer in the drop-down menus that most closely aligns with your current state.
• The third tab displays your rate of process completeness and maturity. You will receive a score for each phase, an overall score, and advice based on your performance.

The tool is intended for periodic use. Review your answers each year and devise initiatives to improve the process performance where you need it most.

Download the Service Desk Maturity Assessment.

Document in Pilot Project Plan

Measure the current culture of collaboration to create a baseline to measure success of the pilot

Collaboration Assessment Questionnaire	Collaboration Assessment Tool
Download the Collaboration Assessment Questionnaire	Download the Collaboration Assessment Tool

Administer the Collaboration Assessment Questionnaire

1.1.2 Administer the Collaboration Assessment Questionnaire

Output: Collaboration Assessment

Participants: Infrastructure Manager, Service Desk Manager, Tier 1, Tier 2, and Tier 3 Technicians

Overview:

Administer the Collaboration Assessment Questionnaire to all technicians prior to the launch to assess the current level of collaboration. Use this questionnaire at the end of the pilot and administer it to both the pilot and non-pilot groups to measure the pilot’s efficacy.

Instructions:

1. Review the template.
2. Modify the questions as needed.
3. If you have a survey tool you use, transfer the questions to your existing tool, otherwise send the survey out to your team.
4. Once the survey has been completed, input the answers into the Collaboration Assessment Tool.

Download the Collaboration Assessment Questionnaire.

Document in Pilot Project Plan

Run the Collaboration Assessment Tool to create a baseline metric for your pilot

1.1.3 Run the Collaboration Assessment Tool

Output: Collaboration Assessment

Participants: Infrastructure Manager, Service Desk Manager, Tier 1, Tier 2, and Tier 3 Technicians

Overview:

Use the Collaboration Assessment Tool to help you understand the issues that are impacting the success of collaboration and shift towards DevOps in your organization. Gain a prioritized list of collaboration drivers and key action steps for moving forward.

Instructions:

1. After administering the Collaboration Assessment Questionnaire, average out the answers for each question and input the averages into the fields at tab 4.
2. Have all managers fill out the “Management Assessment” at tab 3 to identify which collaboration drivers are pain points.

Download the Collaboration Assessment Tool.

Document in Pilot Project Plan

Step 1.2: Review swarming best practices

Outcomes

In this step, we review swarming best practices and establish the rationale for your pilot project that will form the basis of your argument to incorporate swarming practices into your service support model.

OUTPUTS

• Swarming project rationale

EXPERT PERSPECTIVE

To make swarming work, you have to give your teams a lot of autonomy to figure out what is working and what measures they want to improve.

“Discussions around swarming are really important because we need to be out in the DevOps community to help them understand what value add we can bring to them.

Swarming is about setting guard rails and guidelines, not rules. You want people to be able to make great decisions and be flexible in a swarming situation. This is not an advisory board, it is a dynamic and network-based way of working.” (Jon Hall, Principal Product Manager, BMC Software)

Use swarming to lower service support costs, bridge the skills gap, and improve your end-user experiences

Benefits of Swarming

Flexible: The team responds to internal disturbances and external challenges.

Robust: Tasks are completed even if some agents fail.

Scalable: From a few agents to millions.

Decentralized: There is no central control or hierarchy in a swarm.

Self-organized: The solutions are emergent rather than pre-defined.

Adaptable: The swarm system can not only adjust to predetermined stimuli but also adapt to new stimuli.

Speed: Changes in the network can be propagated very fast.

Modularity: Agents act independently of other network layers.

Parallelism: Agents' operations are inherently parallel.

“Swarming is an opportunity to fully utilize the skill sets of each support agent – to create a seamless experience for both internal and external customers.” (Anonymous)

“There is a growing body of evidence that shows that organizations with flat structures outperform those with more traditional hierarchies in most situations.” (Thomas Malone, MIT Sloan School of Management)

The current IT skills gap costs everyone

Swarming reduces time onboarding new technicians time by 50% and bridges the skills gap between technicians through collaboration sessions (BMC).

93% of managers believe there is a skills gap among IT staff.

80% of organizations say the IT skills gap affects at least one area of business.

43% of CEOs say staff productivity is negatively affected by the IT skills gap.

33% of CEOs say security is negatively affected by the IT skills gap.

31% of CEOs say customer service is negatively impacted by the IT skills gap.

31% of CEOs say innovation is negatively impacted by the IT skills gap.

(Source: CompTIA)

Info-Tech Insight

Use swarming to reduce the skills gap and help you achieve your mission and vision as an organization.

Swarming creates the most value in moderate-to-high complexity environments

As companies shift towards automation and self-service, the nature of work that reaches the funnel shifts to a higher percentage of new or complex issues, which require escalation and lead to a bottleneck effect. Swarming allows you to eliminate frustrating escalations, reduce your resolution time, and improve skills transfer.

Tiered Support Model	—›	Swarming Support Model
Tiered Support Model Traditional service support has been organized into three tiers: Tier 1 (service desk), Tier 2 (technical teams) and Tier 3 (applications and IT ops teams) Hierarchical and escalation based Predefined, linear process Limited opportunities to collaborate		Swarming Support Model Swarming has no hierarchy Centers around collaboration between technicians No escalations within support Allows technicians to opt-in The person who takes the case owns it until resolution Managers act as coaches

Automotive companies are using swarming to improve customer satisfaction and decrease ticket times

CASE STUDY

Industry Automotive
Source Genuine Parts Company

Challenge

GPC provides support to over 5,500 NAPA stores, fielding approximately 800 support calls per day.

Found its current tiered model to service support didn’t support DevOps and the company’s goal to bring the development team towards the front line.

High rate of end-user dissatisfaction with their current level of support and slow resolution time.

Wanted to roll out a new service support platform that embraces the DevOps model.

Solution

Started small using existing collaboration tools (24/7 telephone bridge and group chat), that technicians can dial into at any time they have a complicated ticket for group discussion.

Introduced “squads”: small areas of expertise who have scrums 1-2x a week to identify key problems needing attention.

Allowed technicians to sign up for areas of expertise they are confident or passionate in.

Involved key stakeholders from the beginning to maximize buy-in.

Results

Net promoter score increased from -25 to 63 within nine months of deploying swarming.

Net promoter score has remained consistent in the 60-63 range to date.

Created buy-in from other areas in the organization, who are now adopting swarming practices.

Lessons learned in swarming from experts in the field

You may need to rethink your metrics. If you have a lot of metrics focused on individual people and teams it could break your reports.

Give your team autonomy. In order for swarming to work you have to give technicians (who you hired as experts) the space to figure out what is working, what they want to improve, and to self-organize.

Prepare for swarming processes to change frequently and quickly in the early stages. Swarming is a dynamic process, and not a linear routing, and the processes need to have built-in flexibility to respond to the environment.

You may need to incorporate customer service skills training. Technicians who are not used to being in a customer-facing position may need some soft skills training.

Give yourself time to get it right. Success comes through iteration, and that takes time. Give yourself a timeline of at least 3-4 months to see the true benefits of swarming.

“Swarming is really about the cooperation and collaboration between the development group and the operations group. One of the key components is to get the developmental people involved more with the operational group, and the operational group more involved with the development group.” (Paul Dooley)

Swarming

Info-Tech Insight

Not all issues are worthy of collaboration. Collaboration targets the 30-40% of issues that can’t be handled by the initial swarm (end user and support technician).

Assess readiness before launching changes to increase adoption

Just like NASA would never launch a shuttle without doing extensive pre-checks for readiness of both the astronauts and shuttle, so should you take the time to assess the readiness of your team prior to launching changes when possible.

• Processes and standards are well defined and documented.
• Stakeholders believe the new tool and processes can support and improve their practices.
• Users see the value and benefits of the change and are excited for new functionality.
• All relevant users have received proper training and communications and understand any changes expected of them.
• New technology has been tested and is ready.
• Users believe the tool is easy to use to perform the work they are responsible for.
• Governance has been well established.

Info-Tech Insight

By assessing readiness before launching changes, you’ll be able to act proactively to resistance and pushback from your team, instead of going into firefighter mode.

Step 1.3: Identify benchmarks and metrics

Outcomes

In this step we review metric best practices and identify key metrics to track to monitor success of the pilot, as well as determine an ideal target state.

OUTPUTS

• Key metrics to track

Use service support metrics to build a business case for the pilot and track service support improvements

Metrics allow you to quantify success. Select a few key metrics to ensure you’re not over-burdening yourself with work, but are still getting a balanced picture of how your team is doing. Continue to monitor these key metrics throughout your project to monitor progress.

1. Average Cost per Ticket

   Average cost per ticket is the total monthly operating expense of the service desk divided by the monthly ticket volume, and is one of the two foundation metrics of service support.

2. Average Time to Resolve

   Time elapsed from when ticket is “open” to “resolved.” Distinguish between ticket resolution vs. closure, and measure time for incidents and service requests separately.

3. End-User Satisfaction

   One of the foundation metrics of service support. Measure customer satisfaction in the end-user feedback surveys automatically sent out after ticket resolution.

Ensure you are measuring the right metrics, and remember one metric will never give you the whole picture

Don’t put too much emphasis on a single metric. At best, it will give you a distorted picture of your service desk performance. At worst, it will distort the behavior of your agents as they may adopt poor practices to meet the metric.

The solution is to use tension metrics: metrics that work together to give you a better sense of the state of operations. Tension metrics ensure a balanced focus toward shared goals.

Key metrics to think about:

• Time to resolution
• Time between customer logging problem and you providing a solution (temporary or permanent)
• # of days/hours it takes to resolve a problem
• Quality of the fix
• Technical knowledge of the analyst

Don’t forget to include end-user feedback

• Survey customers on a frequent basis
• Follow-up with customers whether it is good or bad feedback

Rely on key internal metrics to build a business case for the pilot and track service support improvements

Think about the watermelon effect – what we want to do is focus on the bigger picture and customer service and collaborative approaches.

In addition to the three key service desk metrics, you want to consider how else as a business you can identify success.

For instance…

• Employee morale and feedback from pilot project participants
• Increasing collaboration score
• The whole team is showing up to meetings for work distribution
• Team members are comfortable coming forward if there is something they feel isn’t right
• Comfort in approaching management about concerns
• Generation of creative new ideas

Watermelon Effect: when on the surface everything looks green and you’re left with the belief everything is fine, however, when you dig deeper you discover the status is in fact red, not green.

Info-Tech Insight

Don’t overdo the metrics. Pick a few key metrics that will help you track your progress and celebrate your success.

Establish baseline metrics and the future goal

1.3.1 Identify key metrics to track

Baseline metrics will give you the foundation to validate that the changes brought on with the swarming pilot are effective.

1. Identify 3-5 key metrics that you want to track to measure the efficacy of the pilot.
2. Record your current metric.
3. Identify your future goal metric.
4. Throughout your pilot, reassess your progress in achieving the future goal metric.
5. At the end of the pilot, review your hypothesized magnitude of improvement (future goal) and your actual magnitude of improvement to measure the efficacy of the program.
   • If you achieve or exceed your future goal metrics, you know the pilot was successfully in meeting the desired needs and can make considerations to expand the project
   • If you fail to reach your desired outcome, troubleshoot as a group to determine how you could improve the pilot to reach your ideal target state.

Document in Pilot Project Plan

PHASE 2

Create a Pilot

Step 2.1: Build the project plan

Outcomes

In this step you define and build your Pilot Project Plan, including identifying key stakeholders, defining the purpose and scope of the pilot, and identifying key milestones for the project.

DELIVERABLES

• Pilot Project Plan

ANALYST PERSPECTIVE

“Pilot projects allow you to see what is on the other side of the fence; they allow you to jump over that fence and feel the new ground beneath your feet. You want to hear, smell, and try it, and feel how it actually works before you make a decision to shift to a new way of doing things.

You can’t just drill a hole in the fence and see what is on the other side. You need to be able to experience it first-hand, to put your feet on the ground, to see if it is shaking, too wet, or too cold, or if it is solid beneath your feet to truly see whether in fact the grass is greener on the other side.” (Igor Ikonnikov, Research Director, Applications, Info-Tech Research Group)

Follow Info-Tech’s pilot project best practices

Don’t confuse a pilot project for a pet project. Formalizing your pilot project, putting it on paper and having key stakeholders sign off, will help ensure it doesn’t become a pet project that easily gets brushed aside.

The importance of timing. Incorrect timing of your pilot can cause further complications (e.g. end of fiscal year). Try not to test two processes at the same time. Furthermore, make sure your pilot is of a long enough duration to see true results (minimum duration should be a few months).

One of the biggest failures is failure to engage with the stakeholders. You need to get buy-in from a large number of people spanning from the system administrators, desktop support teams, security, and potentially your software developers. Engage with the business that the stakeholders support as well.

It's important to establish the success criteria and truly establish the scope of the project. Be sure to have clearly defined goals as well as a process.

Business politics will always be a factor. You need to create a structure so you can get that buy-in and support, and if you have push back at any point you have the documentation to back you up from everyone agreeing to the project in the first place. It empowers you to be able isolate the issues as they arise.

Remember people are humans. Keep it personal and positive. Lead with how it will change their life and people will come back and want to work with you.

Don’t give your project a name. People will form judgements based on their peer group, and the name of the project can taint their perception of it and lead to pre-judgements.

Preserve the integrity of your data by using a structured and scientific approach to your pilot project

Structured Approach

1. Plan and design the pilot study
2. Train participants
3. Support and monitor
4. Evaluate results
5. Make recommendations & improve

Scientific Approach

The scientific approach to conducting a pilot study is to:

1. Measure the current state.
2. Take measurements after the change is introduced and following the change.
3. In an ideal state, you will keep a placebo group to compare the changes to, to further quantify your results.

Finding the right sample size

Use the confidence interval approach when possible to estimate your ideal sample size to measure feasibility of the project

Use Info-Tech’s Sample Size Calculator Tool with your desired confidence interval to determine an ideal sample size.

Info-Tech Best Practice

Use a confidence interval of 75-85%. This allows the focus of your statistics to be on estimation, as well as lets you use a smaller sample size. Note: A confidence interval is a range of values, above and below a finding, in which your population value is likely to fall (Lee et al., 2014).

Use Info-Tech’s Pilot Project Plan Template to help you create your program

Template Overview:

The Pilot Project Plan Template allows you to create your pilot project quickly and document the necessary details involved with designing an effective pilot project.

This template will help you:

• Establish pilot project goals.
• Identify key stakeholders and their roles and responsibilities.
• Define success criteria and evaluation process.
• Record results.

Use this template to create a central repository of all pilot-related details and as a means to enable easy sharing of the project with key stakeholders to gain buy-in and approval.

Download the Pilot Project Plan Template.

Brainstorm as a team and document

2.1.1 Define the purpose, scope, and the roles and responsibilities

Output: Pilot Project Plan

Participants: Infrastructure Director, Service Desk Manager

Overview:

As a group, brainstorm the overall objective, scope, and candidates for the pilot project.

Instructions:

1. Define goals.
   • What is the purpose of the project?
   • How will you measure success?
2. Describe the scope of the pilot project.
   • What are the goals of the project?
   • What will the duration of the pilot be?
   • Where will it be conducted?
   • Who is your target participant group?
3. Identify key project milestones.
   • What are the key tasks and what is the timeline?

Document in Pilot Project Plan

Create a high-level view of your project plan using a tree diagram

2.1.2 Create a high-level project plan

Materials: Sticky notes, Pens and markers, Flip chart paper

Participants: Infrastructure Director, Service Desk Manager

Overview:

Create a tree diagram for a high-level view of your project plan, being sure to brainstorm key activities and tasks that will need to be completed throughout the process.

Instructions:

Using a whiteboard and different colored sticky notes, as a group, brainstorm and identify:

1. What is your overall objective?
2. What are the main activities you will need to accomplish to reach your objective?
3. What are the key tasks that will need to be completed for each activity?
4. Keep a copy of your tree diagram in your Pilot Project Plan.

Document in Pilot Project Plan

Use stakeholder analysis to identify key people to champion the change

You will experience less push back from key stakeholders if you involve them from the beginning and they feel as though they've been heard.

Goal: Create a prioritized list of people who are affected by or can affect your project, and determine how best to communicate with them during the project.

There is no magic list of stakeholders. Key stakeholders will depend on your business, its impacts, and your current engagement objectives; as a result, the list should not remain static.

Outcome: A list of key stakeholders to include in your communication strategy.

Why is a stakeholder analysis essential?

• Ignoring key stakeholders is one of the most common causes of failed IT service management implementations.
• Use the opinions of the most influential stakeholders to shape the implementation at an early stage and to secure resources.
• Communicate with key stakeholders early and often to keep them informed on the benefits of the project.
• Anticipate key reactions of stakeholders to your project and stay one step ahead to earn their support.
• Have your stakeholders sign off on the project to create ownership and increase buy-in.

Brainstorm as a group and identify key stakeholders for the project

2.1.3 Identify key stakeholders

Materials: Sticky notes, Pens and markers, Flip chart paper

Participants: Infrastructure Director, Service Desk Manager

Overview:

Brainstorm and identify key stakeholders for each group.

Instructions:

As a group, identify:

• Key stakeholders, at each level of the organization, for shifting the company culture.
• Are they a challenger or champion?
• Additional notes – how can you leverage them/turn them into a champion?

Document in Pilot Project Plan

Keep training simple

Do not worry about building a formal training manual before you find your best-fit swarming process.

• Don’t overthink your training program for your pilot. Make sure you provide participants with information that empowers them to fulfill the roles you want them to, but don’t overcomplicate the process.
• Conduct half-day to full-day training sessions that incorporate role playing.
• Use your training sessions to communicate key messages and get your team excited for swarming.
• Brainstorm as a group how your team wants to approach collaboration (e.g. what tools they think will be effective).
• Training should be geared at changing behaviors. If you focus on changing behaviors first, the processes will follow.

Things to consider including if you choose to build a training manual:

1. Pilot objective
2. Roles and expectations
3. Process changes
4. Contact information of key people
5. Incidents outside the scope of the pilot project

Info-Tech Insight

Keep it simple. Use your already drafted project plan to help build out the content in your training manual to simplify your backend work.

Build a contingency plan to mitigate risk

By identifying possible issues that may arise with each task and an appropriate countermeasure, you will reduce the potential impact of these issues derailing your pilot project.

To minimize risks associated with a pilot launch the project team should:

• Establish clear performance objectives and evaluation criteria.
• Involve and continually encourage participants to use the system and processes.
• Expand the pilot through an incremental rollout to other areas of the organization.
• Continually monitor the effectiveness of the program.

Info-Tech Best Practice

Process decision program charts are a fast and easy way to build a comprehensive contingency plan for your pilot project.

Brainstorm as a group how you will track problems and monitor practices

2.1.5 Build a contingency plan

Materials: Sticky notes, Pens and markers, Flip chart paper

Participants: Infrastructure Director, Service Desk Manager

Overview:

Create a process decision program chart (PDPC) to identify, as a group, possible things that could go wrong upon deployment of the pilot and countermeasures to mitigate risk.

Instructions:

Using sticky notes and the previously built project plan, as a group:

1. Brainstorm and identify key tasks that need to be completed to achieve the activity in the deployment of the pilot.
2. For each task, identify potential issues that could occur.
3. Review all potential issues and eliminate any with an X that are improbable or whose consequence would be insignificant.
4. For each remaining potential issue, brainstorm a countermeasure or workaround.
5. Discuss the proposed countermeasures and rank how practical each countermeasure is to solve the potential problem.

Keep a copy of your PDPC in your Pilot Project Plan.

Document in Pilot Project Plan

Step 2.2: Build a communication strategy

Outcomes

Communication plays an integral role in the success of any pilot project. By building a clear communication strategy, which outlines key messages and when they will be delivered from the beginning to very end of your pilot, you will set yourself up for success.

DELIVERABLES

• Communication Strategy

ANALYST PERSPECTIVE

Any time you are considering changing a process or launching a new project, it is vital to get feedback from stakeholders and genuinely listen to their concerns.

“You are building a champion by giving stakeholders an opportunity to voice concerns and getting them to buy into what you are doing. By addressing their concerns and questions – you build a champion out of them.
When you build a champion, you create a team. Be heard, but hear others. You need to acknowledge what they are saying as interesting and valuable and to try to incorporate it where it is applicable.” (John Wethington, Senior Director, Security, Info-Tech Research Group)

A strategy saves time

A communication strategy is not the same as a communication plan. A communication strategy is a thoughtful and synergistic approach to sharing information amongst employees within an organization, anchored in the business strategy, mission, and vision of the organization.

Don't underestimate the importance of communication

Employees will become less resistant and more likely to accept and execute your decision if you share the rationale for your decision.

Why it's important:

Decreases resistance to change:

• When senior leaders inform employees by sharing the rationale for a decision, it makes employees more likely to accept the decision and carry it out.

Builds trust:

• Senior leaders model transparency when they provide the rationale for decisions, and this is a vital step toward building trust.

Demonstrates respect:

• Senior leaders who involve employees by showing that they have thought about the impact of decisions on employees and their work processes demonstrate respect for employees’ work experience and gain their trust.

Prevents misunderstanding:

• Clear communication regarding rationale for decisions from senior leaders prevents the “broken telephone” effect where information becomes distorted and inaccurate by the time it reaches employees.

Employ key communication tactics to make change easier on your team and get them excited for it

1. Lead with a strong pitch. It’s important to have a persuasive “pitch” prepared for your team about shift-left that answers key questions:
   • Why it is happening
   • How it will impact the business and them
   • Key goals and objectives
   • What the timeline and roadmap look like
2. Get buy-in from the top down. Think of buy-in like a river: you want to get buy-in from the top first so it will trickle down. Gaining support from leaders at different levels will make your pitch stronger and ensure managers have time to prepare for questions.
3. Be transparent. Communication is a key factor in ameliorating fears and gossip. Be open and honest early on and often.
4. Ask for feedback along the way. It’s important for employees to know their feedback and ideas are being heard. Ensure your change plan includes a process for gathering input and feedback and you keep lines of communication open between management and employees.
5. Set the right expectations. Make sure you don't say the pilot must be successful; regardless of the results, the pilot will be successful because it will teach you which approach works best for your company.

Info-Tech Insight

Timing is everything. At the beginning, you want to control communications and communicate only to people directly impacted by the pilot, to reduce bias. At the end, you want to communicate openly and widely the findings of the pilot project.

Identify the messages for each of your stakeholders

Why: What problems are you trying to solve? What: What processes will it affect (that will affect me)? Who: Who will be affected? Who do I go to if I have issues with the new process?

When: When will this be happening? When will it affect me? How: How will these changes manifest themselves? Goal: What is the final goal? How will it benefit me?

Info-Tech Best Practice

Use the “Rule of Two” in your communications. Communicate with pilot sponsors once a month, stakeholders every two weeks, your core team once a week, and your direct management team should be kept in the loop the entire time and communicated with before anyone else.

Use our template to capture your communication strategy

2.2.1 Build a communication strategy.

Overview:

Use our Communications Strategy Template to build your communication plan with targeted messages to key audiences.

Instructions:

1. Identify stakeholders affected by the project.
2. Craft key messages tailored to each stakeholder group.
3. Finalize the communication strategy. Assess when communications must happen with executives, business unit leaders, end users, and technicians.
   • Identify common questions and strategic responses.
   • Identify who will send out the communications.
   • Identify multiple methods for getting the messages out (newsletters, emails, posters, meetings).

Download the Communication Strategy Template.

Document in Communication Strategy.

PHASE 3

Build a Process

Step 3.1: Design swarming processes

Outcomes

In this step you define and build the swarming process for your pilot project, including ticket handling guidelines and the collaboration tools to be used to facilitate swarming.

DELIVERABLES

• Pilot Project Plan

Swarming is not a linear process and every company approaches it differently

Follow Info-Tech’s best practices and review how others approach swarming to guide you in building your own processes.

Do not overcomplicate the process to begin with; you can refine it as you go.

• Swarming starts as soon as an issue is not solvable at the point of customer contact.
• Get the work to the right person.
• Use a field in the ticketing system to broadcast a question or request for collaboration.
• Connect that person to other smart people.
• Capture what they are doing.
• Support and monitor the project as you go.
• Flexibility and adaptability are key – trust your team to find the best fit of swarming for them.

“It’s about setting guard rails and guidelines, not rules. You want people to be able to make great decisions and be flexible in a swarming situation. This is not an advisory board, it is a dynamic and network-based way of working.” (Jon Hall, BMC Software)

Info-Tech Best Practice

Make sure you align all new processes to industry best practices and company standards. Meet with your pilot team to discuss what is working and make adjustments as needed.

Set clear ticket handling expectations to drive a consistent process

Set expectations

Create and update tickets, but not at the expense of good customer service. Agents can start the ticket, but shouldn’t spend five minutes creating the ticket when they should be troubleshooting the problem.

Update the ticket when the issue is resolved or needs to be escalated. If agents are escalating, they should make sure all relevant information is passed along to the next technician.

Update user of ETA if issue cannot be resolved quickly.

Ticket templates for common incidents can lead to fast creation, data input, and categorizations. Templates can reduce the time it takes to create tickets from 2 minutes to 30 seconds.

Update categories to reflect the actual issue and resolution.

Reference knowledgebase article or document steps taken to resolve the incident.

Confirm incident is resolved with end user either through the end user closing the ticket when they are satisfied with the resolution or through end-user feedback surveys

Close or resolve the ticket on time by having alerts automated when you are nearing SLA cutoff.

Flag the most disruptive and recurring incidents as candidates for swarming to reduce ticket volume

Participants: Service Desk Manager, Service Desk Agents

What You'll Need: Flip chart, Whiteboard

1. Build a list of recurring issues and known errors.
2. Assess which ones are the most disruptive and costly to the business.
   • Identify impact on users, clients, and other departments (number of tickets, time to resolve, departments affected).
   • Identify impact on technicians (number of tickets, time to resolve or apply workaround).
3. Discuss possible fixes. Prioritize high-impact issues and issues that can be resolved quickly
4. Note recurring issues and known errors that will not be resolved. Set the list aside for the knowledgebase discussions.

How IBM approached swarming in the beginning

Started simple using existing collaboration tools.

• Whenever there was an issue the person would go to group chat saying “I have an issue.”

Started a collaboration telephone bridge.

• Kept it open all day long.
• Whenever a complicated ticket came in, analysts would call into the bridge and determine who had the expertise to help them out.
• Group discussion would follow where ideas were generated on the best way to solve the ticket.

If required, the analyst reaches out to end user to get more information.

The analyst who owns the ticket closes it and documents any acquired skills into a knowledgebase article.

Transitioned to using Slack collaboration tool.

• Along with WebEx and the conference bridge when necessary.

Created “Squads.”

• Small areas of expertise, which have scrums 1-2x a week.
• Squads come in with current issues and identify what areas require expertise and make sure they are getting the help they need.

IBM Insights

• Involve your people when you are creating the processes and operation manual.
• Let your people sign up for areas they are either confident in or passionate about learning new skills.
• Your knowledgebase is key – make sure that in any areas that have limited knowledge, time is spent to build up the knowledgebase.
• Use existing collaboration tools.

Ultimate Software reduced its resolution time by 60% within the first year of implementing swarming

CASE STUDY

Industry: Software
Source: Ultimate Software

Challenge

Ultimate Software is a leading provider of cloud-based human capital management solutions.

Have a “people first” philosophy to service support and offer services at no extra charge to end users, including a dedicated account manager, 24-7 phone and online support, and unlimited training.

Ultimate Software recognized a gap in being able to provide a great customer experience with the traditional tiered approach.

End users were frustrated with frequent escalations, having to explain their issue repeatedly to different agents, and long resolution times.

Solution

In 2015, Ultimate Software saw room for growth by converting to a collaborative support model and collapsing its tiers.

Adopted a collaborative approach designed to “swarm” each customer inquiry.

The approach provides the customer with one centralized point of contact and eliminates the traditional ping-pong effect of tickets being bounced around.

The swarm is composed of specialists and different subject-matter experts who work together to solve the customer inquiries quickly.

Results

In 2016, Ultimate Software received wide spread recognition for its customer service, including:

• “Best Customer Service Department of the Year” (Network Product Guide’s 2016 IT World Awards)
• “Support Department of the Year” (Best in Biz Awards 2016)
• TSIA STAR Award for Innovation in the Transformation of Support Services

Decreased resolution time by 60%.

97% customer retention rate.

95% customer satisfaction score.

Only create workflows if you deem them absolutely necessary

Swarming is a non-linear process, making process workflow construction time consuming and challenging. Even worse, workflows can limit your pilot team’s autonomy and ability to creatively collaborate and may impact the overall effectiveness of your pilot.

Consider adopting a knowledge-centered approach to improve knowledge management

The knowledge-centered support follows a continuous loop of capturing, structuring, and reusing knowledge.

1. Capture Knowledge
   Have your team write articles from the customer’s perspective, making information relevant and easily accessible to your end users
2. Structure Knowledge
   Promote consistency by having your technicians use a template when writing new articles
3. Reuse Knowledge
   Technicians should search for relevant knowledgebase articles with every ticket, adding a link to the relevant article when possible.
4. Improve Knowledge
   As technicians reuse articles they should be reviewing them for improvements, flagging them, fixing them, and then publishing the improved version.
5. Monitor Knowledge
   You can improve the quality of your knowledgebase by measuring how effective each existing article is and focusing resources on your most high-demand articles.

Info-Tech Insight

Your knowledgebase can make our break your pilot project. A comprehensive, up-to-date knowledgebase is integral to your team successfully being able to collaborate. (Source: Zorah, 2014)

Leverage existing collaboration platforms and utilize them, don’t try and build new ones

Collaboration Tool Requirements

Tool must allow pilot participants to:

• See incidents, cases, and work that is relevant to them.
• Request help (raise their hand).
• View open requests for help and aged requests.
• Respond to others requests for help.
• View others’ availability status.
• Ask specific people or groups questions.
• Join existing groups.
• Create separate collaboration spaces to swarm with others and work on requests.

“I don’t care so much about how many places collaboration occurs, but more about that there is accountability and visibility.” (Koree Mires, Cisco)

Collaboration tools companies are using for swarming:

• Skype
• slack
• Microsoft Teams
• salesforce
• Cisco Jabber
• Cisco webex
• Jira Software

Brainstorm and document, as a group, swarming practices

3.1.1 Define swarming process

Materials: Pens and markers, Flip chart paper

Participants: Infrastructure Director, Service Desk Manager

Overview:

Brainstorm and document key swarming processes you want the pilot project participants to use.

Instructions:

1. How will ticket handling change with swarming?
2. Are there ticket exceptions that you don’t want the swarm to handle (e.g. critical incidents)?
3. If needed, draft an incident and service request workflow.
4. Discuss and document the structure of your swarming:
   • How many people in a swarm?
   • How often will they meet?
   • What collaboration tools will they use?
   • Will their roles and responsibilities change? If so, document.
   • Who will their contact be for questions and concerns?

Document in Pilot Project Plan

Step 3.2: Create an evaluation plan

Outcomes

In this step you define and build your evaluation process for the pilot project.

DELIVERABLES

• Evaluation Plan in the Pilot Project Plan

Incorporate evaluation best practices into data collection management

Track the same data across the duration of the pilot project to keep the stakeholders and participants informed.

Collect both quantitative and qualitative data:

Quantitative

• Key metrics and reports
• Collaboration score
• End-user surveys

Qualitative

• Participant surveys
• Debriefing interviews
• Focus group sessions

Build feedback practices to give you a true understanding of how the pilot is working:

• Daily feedback is a critical component when conducting a pilot project to discuss what is working and what is not, and make adjustments as needed.

As the project nears completion:

1. The number of tickets should decrease.
2. Percentage of calls resolved at first contact and at Tier 1 should increase.
3. Average time to resolve and escalate an incident should decrease.

“Feedback is just as important as the delivery and integration – 80% of the work you do is on maintenance work and we need to make sure we get that aligned as well.” (Andrew Kum-Seun, Info-Tech)

Info-Tech Best Practice

Schedule time weekly to collect data. Collecting data at regular intervals allows you to properly monitor the progress of the pilot project and make adjustments as needed.

Use surveys with participants and end users to gain valuable insights into your progress

A simple quantitative survey at the closing of a ticket can alert you to any potential issues with the swarming pilot project and potential areas for improvement.

If a more complex survey is required, you may wish to include some of these questions:

• The professionalism of the analyst
• The technical skills or knowledge of the analyst
• The timeliness of the service provided
• The overall service experience

Add an open-ended, qualitative question to put the number in context, and solicit critical feedback:

What could the service desk have done to improve your experience?

Best Practices

• Use Likert (rating) scales when possible to quantify and simplify.
• Assess whether each question gives an adequate range of responses.
• Administer the questionnaire to participants in exactly the same way.
• Ask participants for feedback regarding ambiguity and difficult questions.
• Discard all unnecessary, difficult, or ambiguous questions.
• Check to ensure all questions are answered.
(Source: Teijlingen et al., 2002)

Info-Tech Insight

Environment and time of day can impact your data. To improve internal validity be sure to administer the questionnaire to all participants in exactly the same manner. For example, all participants have ten minutes, alone in a quiet room, prior to lunch.

Define the feedback and evaluation process to ensure implementation and adoption are on track

3.2.1 Create an evaluation plan

Output: Evaluation Plan in the Pilot Project Plan

Participants: Infrastructure Manager, Service Desk Manager

Overview:

Define how and when the success of the project will be tracked and evaluated.

Instructions:

1. Identify frequency of data collection.
2. Ensure there is immediate follow-up on communications and training to:
   • Validate people’s acquisition of required knowledge and skills.
   • Identify emerging/unforeseen challenges and opportunities.
3. How will you incorporate employee feedback into the program?
   • Will surveys be sent out each quarter?
4. Document your data collection plan.

Download the Pilot Project Plan

Document in Pilot Project Plan

Follow these guidelines when interpreting and documenting findings

Even the most successful pilot project can be rendered useless if the findings aren’t interpreted with care and caution.

When interpreting and documenting findings, include:

• Objectives
• Methods
• Estimated effects
• Measures of variability (e.g. confidence intervals)
• Effectiveness of interventions
• Feasibility of the project moving forward
• Lessons that have been learned and will be informative in planning subsequent studies

Avoid:

• Claiming statistical significance
• Over-asserting findings
• Presenting biased results that favor your desired outcome
(Source: Moore et al., 2011)

Conclude your findings with one of the following:

1. Swarming is not feasible at your organization at this time.
2. Swarming is feasible, but requires adjustments to the process.
3. Swarming is feasible, without adjustments to the process.
4. Swarming is feasible, with close monitoring.

Clearly outline any recommended changes and findings in your debrief and/or proposal.

Info-Tech Insight

There is no such thing as bad results. Even if your results indicate swarming is not feasible, the project is still a success because you avoided wasting valuable resources deploying a larger project that would yield undesirable results.

Step 3.3: Create your support plan

Outcomes

In this step you are given the tools and best practices to support your pilot project moving forward, and determine next steps.

DELIVERABLES

• Support best practices

Equip senior leaders to understand and own their impact in the success of the pilot project

By leveraging insights from neuroscience and psychology, senior leaders can combat resistance to change and motivate their team to reach their desired state.

Trust is crucial

Social tension elicits a threat response, cutting off access to the executive function of the prefrontal cortex, which drives creativity. Building trust and a sense of safety is therefore key in driving employee productivity (Giles).

Change is challenging

Being faced with change elicits a threat response in the amygdala that reduces blood flow to the brain, reducing one’s ability to generate new ideas and making our opinions rigid (Giles).

Connection matters

A sense of belonging activates the limbic brain, which is required to allow higher brain functioning (Giles). This makes fostering connection from the top down an important part of organizational strategy.

Help senior leaders own their impact:

• Reduce resistance to change by framing the change positively and focusing on and being transparent in communication.
• Don’t be discouraged with the data, use it as motivation to continue to build trust within the organization.
• Emphasize future positive change and provide specific actions to improve.

Info-Tech Insight

Leverage basic neuroscience and psychology insights to target the root cause of resistance and get your team motivated to spearhead the pilot project.

Build ongoing support practices to ensure the success of your pilot project

Employee attitudes are greatly impacted by senior leadership

(Source: American Psychological Association, 2016)

Forms of Support:

Feedback Sessions

Hold daily feedback sessions to take a deeper dive into how the pilot project is going, address any ongoing concerns, and get feedback from the team on what adjustments can be made.

One-on-Ones

Hold regular (weekly or monthly) one-on-one sessions with your pilot participants to give them an opportunity to express how they’re feeling in private and address any concerns they are having.

Daily Check-ins

Have a quick meeting or huddle each morning to check in with the pilot project participants to see what is working and what is coming down the turnpike and make adjustments as needed.

Celebrate Successes

Celebrate successes regularly by presenting your team with key metrics and data on how the pilot project is going and highlighting key performers.

Info-Tech Best Practice

Make time for daily 15-minute feedback sessions with your pilot team to discuss what is working and make adjustments as needed.

Don’t let temporary drops in participant support derail your efforts

Change curve:

1. Honeymoon of “Uninformed Optimism”: Tentative support and enthusiasm for change before people have really felt or understood what it involves.
2. Backlash of “Informed Pessimism” (leading to “Valley of Despair”): People realize they’ve overestimated the benefits (or how soon they’ll be achieved) and underestimated the difficulty of change.
3. Valley of Despair and beginning of “Hopeful Realism”: Sentiment bottoms out and people begin to accept the difficulty (or inevitability) of change.
4. Bounce of “Informed Optimism”: More optimism and support when people begin to see bright spots and early successes.
5. Contentment of “Completion”: Change has been successfully adopted and benefits are being realized.
(Source: Based on Don Kelley and Daryl Conner’s Emotional Cycle of Change, qtd. by Mind Tools)

Info-Tech Insight

By communicating to your team and stakeholders that highs and lows are a normal part of the change process, you can reduce resistance and pushback when you fall in the lower parts of the change curve.

Debriefing is an integral part to your evaluation and moving forward

Debriefing Agenda:

1. Organize IT project lead observation and debriefing sessions.
2. Hold debriefing sessions with the participants of the pilot project.
3. Communicate results of the pilot project with the entire organization.
4. Based on the pilot results, develop a proposal to obtain future funding.

Info-Tech Best Practice

Use a neutral response to comments. Be careful of how you respond to feedback and comments from debriefing session participants as you could not only create interviewer bias, but you may alienate participants with dissenting opinions and lose valuable knowledge.

Bibliography

“2016 State of DevOps Report.” Puppet Labs, 2016. Web.

“Cisco Systems Inc. Market Cap: 205.12B for Nov. 14, 2018.” YCharts, 14 Nov. 2018. Web.

Dodd, Julie. “Collaborative Support: The Ultimate Difference in Service.” Ultimate Software Blog, 6 Jan. 2017. Web.

Giles, Sunnie. “The Most Important Leadership Competencies, According to Leaders Around the World.” Harvard Business Review, 15 March 2016. Web.

Hall, Jon. “ITSM, DevOps, and why three-tier support should be replaced with Swarming.” Medium.com, 16 Dec. 2016. Web.

“Kelley and Conner's Emotional Cycle of Change.” Mind Tools. n.d. Web.

Malone, Thomas. "Will collective intelligence change how we work?" MIT Sloan Executive Education, 3 Apr. 2016. Web.

Lee, Ellen, A. Whitehead, R. Jacques, S. Julious. “The statistical interpretation of pilot trials: should significance thresholds be reconsidered?” BMC Medical Research Methodology, 2014. Web.

Moore, Charity G., R. Carter , P. Nietert, and P. Stewart. “Recommendations for Planning Pilot Studies in Clinical and Translational Research.” CTS Journal, 2011. Web.

“State of the IT Skills Gap: Full Report.” CompTIA.org, Feb. 2012. Web.

“Swarming: Considerations for Starting Out.” Consortium for Service Innovation. n.d. Web.

“Intelligent Swarming: Collaboration on Steroids” Consortium for Service Innovation. n.d. Web.

“Intelligent Swarming” Consortium for Service Innovation n.d. Web

Teijlingen, Edwin, R., and V. Hundley. “The Importance of Pilot Studies.” Nursing standard (Royal College of Nursing (Great Britain): 1987). 16. 33-6. June 2002. Web.

Zorah, Sarah. “Get your team started with knowledge-centered support.” Atlassian Blog, 12 Nov. 2014. Web.

Research contributors and experts

Greg Oxton, Facilitator & Executive Director Consortium Service Innovation Greg Oxton is the executive director of the Consortium for Service Innovation, a nonprofit alliance of customer support organizations that develop innovative ways to address the challenges of customer service and support. Before joining the Consortium, Greg held management positions in customer service, operations, planning, support strategy, at IBM, N.E.T., and Tandem Computers.

Jon Hall, Principal Product Manager BMC Software Jon Hall is a principal product manager in the BMC Remedy ITSM Product Management team at BMC Software, focused primarily on the evolving toolset marketplace and innovative new solutions for service. He has 18 years of experience in ITSM.

James Karioki, Senior Manager Advanced Problem Determination & Technical Support Manager IBM James Karioki is the senior manager of advanced problem determination and technical support manager at IBM, with over 10 years experience in the field. James contributed to increasing customer satisfaction and driving process improvements at IBM by helping transition service support to a collaborative model, and he has written numerous articles on collaborative support on LinkedIn.

Koree Mires, Senior Business Operations Manager Cisco Koree Mires is a senior business operation manager at Cisco with over 18 years experience working at the company. With extensive experience in strategy development and working in a cross-functional setting, he has been a champion in improving processes, developing strategies, and helping shift Cisco to a collaborative service support model.

	Paul Dooley, Author & Certified ITIL, HDI, and ITSM Instructor Paul Dooley has over 30 years experience in IT services and support and over 15 years as a certified ITIL and HDI instructor. Paul is currently the president and principal consultant at Optimal Connections, LLC which delivers IT service and support training to business and organizations.
	Adam Maino, Director of Support North America APAC at FinancialForce Adam Maino has over 18 years working in technology, in the tech sector and Finance. Adam was the project manager for implementing intelligent swarming at FinancialForce and championed and mentored Tier 2 analysts and product managers in adopting the KCS project and collaboration.

	Judith Platz, Vice President, Support Services Research, Technology Services Industry Association (TSIA) Judith Platz is the vice president of support services research for TSIA, working with support services members to streamline their processes and workforce in order to operate more efficiently and become more customer service focused.
	Eric Ohnemus, Director of Customer Satisfaction Genuine Parts Company Eric Ohnemus is the director of customer satisfaction at Genuine Parts Company and has over 17 years experience in the industry. Eric chose to implement swarming practices to bring the development team to the front line and support DevOps.

Related Info-Tech research

Structure Your DevOps Adoption Using a Metrics-Driven Approach
Set measurement-based objectives the organization can strive for collaboratively.

Implement Agile Practices That Work
Improve collaboration and transparency with the business to minimize project failure.

Related Info-Tech research

Standardize the Service Desk
Strengthen your service desk to build a strong ITSM foundation.