Collaborate and promote visibility

Service management work crosses boundaries. An incident may involve the service desk, a network team, an application team, a supplier and the affected business unit. A change may need input from developers, operations, security and the people who will use the result. When these groups work in isolation, information is lost at every handoff, problems are hidden until they become crises and decisions are made without the full picture. The fourth guiding principle asks organizations to work together across boundaries and to make work and its results visible. This lesson explains who to collaborate with, how to communicate with different stakeholders, why visibility matters and how to make it practical without drowning people in information.

What the principle asks

Collaborate and promote visibility means: working together across boundaries produces results that have greater buy-in, more relevance to objectives and increased likelihood of long-term success. Achieving objectives requires information, understanding and trust. Work and its consequences should be made visible, hidden agendas avoided and information shared to the greatest degree possible.

Applying the principle involves:

• Collaboration does not mean consensus: not everyone must agree, but the right people must be involved in the right way.
• Communicating in a way the audience can hear: different stakeholders need different messages, channels and levels of detail.
• Making decisions on visible data: decisions based on hidden or partial information are less likely to be good ones.
• Making work visible so that bottlenecks, waste and risks can be seen and addressed.

Collaboration versus cooperation

ITIL distinguishes collaboration from cooperation. Cooperation means groups pursue their own goals while helping each other where convenient. Collaboration means groups work together toward a shared goal, sometimes setting aside their own interests to achieve it. A service desk that passes tickets politely to a network team is cooperating. A service desk and network team that jointly own a target for restoring service, review incidents together and share knowledge are collaborating.

Silos are the opposite of collaboration. They form when teams are measured only on their own targets, use separate tools, sit in different places and rarely talk. A team that is rewarded for closing tickets quickly may close them by passing them on, even if the customer's problem remains unsolved. Breaking silos often means changing measures and structures, not just asking people to be friendlier.

Who to collaborate with

Collaboration is not only with obvious partners. ITIL encourages involving a wide range of stakeholders, including:

• Customers and users, who know what they need and how the service really performs.
• Internal teams across development, operations, security, finance and support.
• Suppliers and partners, who may hold critical knowledge and capabilities.
• Governance bodies, auditors and regulators, who need confidence that risks are controlled.
• People who seem unlikely partners, such as those who resist a change: understanding their concerns often improves the outcome.

Making work visible

Much of the work in IT is invisible. Unlike a physical production line, nobody can walk past and see a pile of unfinished changes or a queue of waiting requests. Invisible work cannot be managed well: bottlenecks persist because nobody sees them, urgent work crowds out important work, and people take on more than they can finish.

Visual management tools help. A kanban board shows each work item as a card moving through columns such as "to do", "in progress" and "done". Limits on work in progress (WIP limits) prevent too many items starting at once. Dashboards show service performance in real time. A shared change calendar shows what is planned and where conflicts may arise.

Flow efficiency

The share of time that work is actively being worked on is called flow efficiency. In many service organizations it is surprisingly low, often well under 20 %, because work spends most of its life waiting in queues. Making flow visible is the first step to improving it.

Flow efficiency is calculated as \( \text{flow efficiency} = \dfrac{\text{active work time}}{\text{total lead time}} \times 100\% \).

Visibility and trust

Visibility builds trust, and trust enables collaboration. When a team shares its real performance, including problems, stakeholders learn they can rely on what it says. When problems are hidden, stakeholders discover them eventually and stop trusting all reports. The principle therefore asks for transparency about bad news as well as good: an honest account of a missed target, with a plan to recover, is worth more than a report that looks good but is not believed.

Visibility also has limits. Some information is confidential: personal data, security details, commercial terms. The principle asks for information to be shared "to the greatest degree possible", which means sharing as much as is safe and appropriate, not everything with everyone.

Avoiding information overload

More information is not always better visibility. Dashboards with dozens of measures, daily reports to people who do not need them, and notifications for every event can bury the signals that matter. Good visibility is selective: the right information, to the right people, at the right time, in a form they can understand.

Links to other principles

This principle supports focus on value (stakeholders help identify what is valuable), start where you are (the people doing the work know the current state best) and think and work holistically (lesson 6), since seeing the whole system depends on information flowing across it. It is also central to DevOps, which emerged largely to break down the silo between development and operations teams, and to governance, which depends on accurate, visible information to evaluate, direct and monitor (lesson 10).

Practical techniques for collaboration

Several simple techniques make collaboration and visibility part of everyday work rather than an occasional effort:

• Daily stand-ups: short meetings where a team reviews its board, raises blockers and agrees who will help whom.
• Joint incident reviews: technical teams, the service desk and suppliers review significant incidents together, in a blameless format that focuses on learning.
• Shared service reviews with customers: regular meetings that look at performance, upcoming changes and customer priorities.
• Swarming: for complex incidents, bringing the right specialists together at once instead of passing the ticket from team to team.
• Open documentation: knowledge articles, runbooks and decisions stored where everyone who needs them can find them.
• Communities of practice: groups across teams that share expertise on a topic, such as automation or security.

Swarming deserves a closer look because it challenges the traditional tiered support model. In a tiered model, an incident moves from first-line to second-line to third-line support, waiting in a queue at each step. In swarming, the person who first receives a difficult incident pulls in whoever can help, and they work on it together. Swarming tends to reduce resolution time for complex issues and spreads knowledge across teams, though it needs clear rules so that specialists are not constantly interrupted.

Whichever techniques are used, the test is the same: do the people who need information get it in time to act, and do teams work toward shared outcomes rather than defending their own boundaries? If the answer is yes, collaboration and visibility are working, whatever tools or meetings support them.

Key point to remember

Invisible work cannot be managed, and siloed teams cannot deliver end-to-end value. Make work and its results visible to those who need them, share bad news early, and give teams goals they can only achieve together.