Guiding Principles and Four Dimensions of Service Management

A guiding principle is a recommendation that helps an organization decide what to do in all circumstances. It stays useful when the organization's goals, strategy, work or structure changes. It shapes judgment without prescribing a fixed sequence of actions.

Know the seven principles

These seven appear in ITIL 4 and ITIL (Version 5), which PeopleCert launched in January 2026. They are universal: a small public library, a large manufacturer and an external IT provider can all use them. They are enduring: replacing a tool or reorganizing a department does not make them obsolete. Similar ideas in Agile, DevOps and Lean also help organizations use these approaches together.

Adapt guidance to the situation

To adopt and adapt guidance is to take useful ideas and fit their implementation to the organization's needs. A 12-person IT team at a design studio may coordinate routine work through a short shared list. A 2,000-person IT department at a bank may need more formal controls and clearer divisions of authority. Both can keep work simple and practical. The useful amount of structure depends on their work, customers and risks.

A principle and a procedure do different jobs. The instruction "Every change needs approval from the change advisory board" specifies an action. The principle "keep it simple and practical" helps the organization examine whether that approval arrangement is useful for low-risk, routine changes. Staff still follow applicable procedures while authorized people review and improve them.

Consider the principles together

Imagine a team introducing a support portal. It considers what users need to accomplish, which existing articles are reliable, and which small part to try first. It also checks who will maintain the portal and how failed requests will reach the service desk. Several principles shape the same decision.

Review all seven before deciding which deserve most attention. Their order in the list is not a project plan. You do not finish focusing on value and then move permanently to the next principle. A pilot may reveal a new consumer need, sending the team back to its understanding of value while it continues to collaborate and simplify the work.

Focus on value links everything an organization does, directly or indirectly, to value for itself, its customers and other stakeholders. Value comes from what people perceive as beneficial, useful and important. It can involve better outcomes, lower costs or reduced risks.

Identify the people involved

A service consumer can include different roles. In an internal payroll service, employees who check their pay slips are users. The HR director who defines the service requirements is the customer. The finance director who approves its budget is the sponsor. One person can hold more than one role in other services.

These viewpoints help you ask precise questions. Employees need correct pay on time. The customer needs the service to meet its obligations. The sponsor needs a sustainable cost. Other stakeholders may care about security, reporting or the work required to support the service. A decision should account for these needs together.

Connect features to outcomes and experience

Value is partly subjective and changes with circumstances. Video-call performance becomes more important when a team begins working remotely. A feature that pleased users last year may no longer solve their main problem.

Customer experience (CX) spans a customer's interactions with an organization and its products and services. User experience (UX) concerns using a particular product or service. A meeting-room system may successfully save bookings but require eight screens to make one. A two-screen route can create value by reducing effort and frustration, even when both versions produce the same booking.

The distinction matters when choosing measures. Counting completed bookings shows usage. Observing whether people can book the right room easily helps reveal the experience. Talk to consumers and watch how they work so that the measure reflects what matters to them.

Work through a value decision

An IT team wants faster storage to make a monthly sales report run 40% faster. Before buying it, the team asks users how they use the report. They run it once a month and accept its waiting time. Their serious problem is that about 1 run in 10 contains wrong figures.

1. The desired outcome is dependable information for sales decisions.
2. Faster processing would improve speed but leave the reported accuracy problem unresolved.
3. Improving data accuracy addresses the need users identified.
4. The team checks whether fewer incorrect reports actually help users make their decisions.

Value also guides daily operations. When a payment fault prevents customers from buying and an intranet page has a cosmetic error, restoring payment supports the more urgent consumer outcome in this situation.

Weigh competing needs

The cheapest service is not always the most valuable, and the most advanced technology is not always worth buying. Likewise, a user request is an input to a decision, not an automatic instruction to fulfill it. Consider its cost, risk and effect on other consumers. At the start of an improvement, state the expected value in plain words, help staff connect their work to it, and check whether it is being delivered as the work develops.

Start where you are means assessing existing resources before deciding to rebuild. Services, processes, people, tools, data and partner relationships may contain useful work. The assessment decides what to reuse, improve, expand or replace.

Observe the current work

Use the desired consumer outcome as your reference point. If the aim is to help new employees become productive, examine what happens between the hiring decision and the employee being able to work. A process document may say access arrives on day one, while observation shows that staff spend several days chasing approvals.

Direct observation is essential because it reveals how work actually happens. Watch people carry out tasks, ask why they take particular steps, and compare their experience with the records. Workarounds can reveal both useful knowledge and weaknesses hidden by a tidy process diagram.

Measurement adds evidence. It can show how often a delay occurs, how much work is involved or whether a change helps. Check what a measure means before trusting it: the data may be old, incomplete or based on definitions that do not match the outcome.

For example, a service desk target asks agents to resolve incidents within 3 hours on average. Agents start closing tickets before the problem is fixed. Reported resolution time improves, but more tickets reopen. Observing a user still unable to work reveals why the favorable average is misleading. Measuring can change behavior, so examine the behavior it rewards.

Separate useful assets from weak ones

An organization plans to replace its service management tool. The assessment finds 600 knowledge articles used daily and a request catalog with mostly outdated entries.

• The articles contain useful knowledge. Review and tidy them, then migrate them into the replacement tool.
• The catalog needs redesign because retaining stale entries would preserve a known weakness.
• The tool decision and the content decisions can differ. Replacing software does not require discarding everything around it.

Good practice can also be expanded. If one office has a clear onboarding checklist that new staff praise, examine whether it can support other offices and what local adjustments it needs. Reuse still involves checking fitness for the new context.

Compare the risks of keeping and replacing

Keeping a flawed component can carry its faults forward. Replacing a working component can lose knowledge, consume time and interrupt a dependable service. Compare both risks with the intended outcome.

A vendor's unsupported tool that cannot meet security requirements must be replaced. Its data, the team's skills and useful processes may still have value. In a rare case, an assessment may find nothing worth retaining; that conclusion follows the evidence.

The principle does not mean preserving the current state. An honest assessment can justify extensive change.

Progress iteratively with feedback means dividing work into manageable sections that each deliver something useful. An iteration is a small part of the work that can be completed and reviewed in a reasonable time. The overall objective gives direction while feedback shapes the next part.

Make each iteration useful

Large initiatives still need a plan. Identify the outcome, dependencies and risks, then choose a first section that can deliver value and teach the team something. Iterations can follow one another or run in parallel when their dependencies allow it. Review the wider plan after each one.

A minimum viable product (MVP) is the smallest version that delivers value and produces useful feedback. For a knowledge base, complete and tested articles for the 20 most frequent issues can be useful immediately. Rough drafts for 500 issues may look more complete while offering users little dependable help. Small does not mean unfinished or unsafe.

Use feedback throughout the work

A feedback loop returns outputs from part of a system as inputs to that same part. A team releases a useful change, learns what happened and uses that information to adjust its work. Consumers, staff, suppliers and measurements can all contribute.

Seek feedback before, during and after each iteration. Before work, it helps clarify the problem. During work, it can expose a misunderstanding while correction is cheap. Afterward, it shows how the result performs in use. Feedback after launch remains valuable for further improvement, but waiting until launch delays earlier opportunities to correct problems.

Work through a staged migration

A company must move 2,000 mailboxes. It plans four waves: 50 IT staff, then 200 people, then 750, then 1,000.

1. The first 50 use the new service and report that shared calendars have lost their permissions.
2. The team traces the problem to the migration script and fixes it.
3. It checks the repaired behavior before moving the next 200 people.
4. It reviews that wave and adjusts the remaining plan as needed.

The wave sizes total 2,000. Learning from the first 50 prevents the permission error from reaching the other 1,950 people. The value comes from using the feedback to change the work; collecting comments without acting on them would leave the fault in place.

Keep the whole outcome in view

Each increment must fit the whole service. A successful email move includes the calendars and shared work people rely on, not just copied messages. Collaboration makes feedback available, and visibility helps everyone understand what changed and why.

Do enough analysis to understand the whole, then carry out a useful first increment. Trying to predict every future detail can delay value. Equally, calling work "iterative" does not excuse starting without an objective or ignoring a known dependency.

Collaborate and promote visibility combines joint work across boundaries with access to the information people need. Relevant involvement improves the fit of decisions, builds support and helps improvements last. Visibility lets people see progress, obstacles and effects beyond their own team.

Work across team boundaries

A silo develops when a team pursues its own goals with little information sharing. The service desk may repeatedly handle a software fault while developers never see the pattern. Reviewing frequent incident causes together gives both teams evidence for a lasting fix.

Identify stakeholders by asking who uses the service, pays for it, sets requirements, carries out the work or bears a risk. Customers, users, sponsors, development, operations, security, HR, finance and suppliers may all matter. Give each the appropriate involvement. Some help decide, some contribute knowledge, and some need timely information.

Collaboration does not require unanimous agreement. Hear relevant input, make the reasoning visible, and let the accountable person or group decide. Requiring everyone to approve every detail can delay work without improving the result.

Make information usable

Choose a message, medium, detail level and timing that fit the audience. Senior managers may need a one-page account of business impact and a decision. Engineers need the technical facts for carrying out the change. Users need to know what will happen, when and how to get help.

A shared work board or dashboard can reveal waiting work, spare capacity, unplanned demand and bottlenecks. It is useful when the right people can act on what it shows. More reports and meetings do not necessarily improve visibility.

Suppose a dashboard shows that one application version caused 40% of last month's incidents. The shared evidence identifies a significant source of trouble. Before setting priority, teams also examine business impact, risk and expected value from a fix. Frequency supplies part of the decision, not the entire decision.

Work through a coordination problem

Two teams schedule changes for the same weekend. Each expects downtime for an online shop, but neither sees the other's plan. The combined disruption only becomes clear when the changes begin.

The organization introduces a shared change calendar visible to delivery teams, the service desk and key suppliers. Teams can now spot clashes before the weekend, agree timing and prepare support. The calendar's benefit is the shared understanding it enables; choosing a calendar tool alone would not ensure people use it or discuss conflicts.

Bad news needs visibility too. A delayed supplier delivery belongs on the board early enough for others to respond. Hiding a delay protects the appearance of one team's progress while making the service harder to manage. Explain why the change is needed and what decisions the information supports, so people understand the purpose of sharing it.

Think and work holistically means treating a service as a whole system. Consumers receive an outcome through a combination of people, information, technology, partners and ways of working. Improving one component can leave the outcome unchanged or make work harder elsewhere.

Look beyond a team’s task

A server team reduces the time it needs to set up a new user's virtual desktop by 30%. New employees still wait about a week for access. The team has improved its task, but that task was not the main source of delay.

Mapping the whole flow reveals a long wait for manager approval. The useful question changes from "How fast can servers be prepared?" to "What stops a new employee from being able to work?" The second question includes the manager's decision, the request handoff, technical setup and the point at which the employee can use the service.

This is local optimization: making one part better without necessarily improving the whole. To judge whether a local change helps, check its effect on the consumer's result. A faster handoff may simply put more work into the next team's queue.

Examine the connections

The four dimensions give a practical way to look for missing dependencies: organizations and people, information and technology, partners and suppliers, and value streams and processes. A new monitoring tool needs trained people, reliable service information, supplier support and a workable route from an alert to a response.

No one team sees all of these connections. Collaboration brings different views together. Look for recurring patterns as well as isolated incidents. If incidents rise after every release, explore how development, testing and operations interact. Treating every incident as unrelated may hide a common weakness at a boundary.

Automation can help connect information. A monitoring alert linked to the affected service, recent changes and open incidents gives responders a wider picture than an isolated warning. The information must still be accurate enough for people to use.

Match learning to the system

In a simple, well-understood system, fixed rules can help predict the effect of a change. In a complex system, interactions can produce unexpected effects. Use exploration and feedback to discover what happens in practice, especially across boundaries that are poorly understood.

Holistic thinking works with small iterations. A team can first improve approval for one type of standard request while checking what this means for security, staffing, suppliers and users. It need not change the entire service in one large project.

Keep it simple and practical means using the minimum steps needed to achieve an objective. Begin with the desired outcome, then check what each activity contributes. Remove a process, action or metric when it provides no value or useful outcome.

Start from the needed result

Outcome-based thinking asks what must be achieved before deciding how to do the work. For a software request, the outcome includes getting suitable software to an authorized user. The form should gather what approval, fulfillment, required controls and reporting need. Collecting every detail that might someday be interesting can make the route difficult to use.

Review each step, form field, approval, report and measure. Ask who uses it, what decision or action it supports, and what would be lost if it were removed. An approval that manages a real risk has value even if the requester finds it inconvenient. A report nobody reads and no control requires is a candidate for removal.

Simplify a request form

A request form contains 25 fields. The team reviews 3 months of requests and checks all the purposes the information serves.

The counts total 25. A common request now shows the 9 regular fields. Relevant requests also show the conditional fields. The team has reduced effort while retaining information needed for real work. Fewer people abandon the form halfway.

Notice why "approvers never read it" would be an incomplete test. A field may still help installation, a security control or reporting. Find out its purpose across the service before discarding it.

Handle exceptions without burdening everyone

Trying to build a separate rule for every rare situation can make the normal route difficult to understand. Design a clear route for common requests and a simple exception route, such as escalation to a named person. People should know when and how to leave the normal route.

Managers may want detailed data while staff want less administration. Resolve that tension by identifying the information actually used in decisions. A smaller useful set can respect staff time while supporting management needs.

Keep required controls

Practical simplicity includes security, safety and legal compliance. Removing an identity check simply because it takes time can create a service that no longer works acceptably. Examine whether a control is needed and whether its design can be simplified safely.

Simple work often takes careful analysis to design. Once understood, it is easier to explain and adopt. Small changes that produce visible benefits are quick wins: for example, removing a duplicate field can reduce effort immediately and build support for further improvement.

Optimize and automate means using resources, especially people's time, to best effect. Optimization makes work as effective and useful as it needs to be in its context. It does not require perfection. Automation uses technology to perform steps correctly and consistently with limited or no human intervention.

Find a suitable future state

A useful path to optimization is to:

1. Understand and agree the context, vision and objectives.
2. Assess the current state.
3. Agree the future state and priorities, emphasizing simplification and value.
4. Secure the right stakeholder engagement and commitment.
5. Carry out improvements iteratively.
6. Keep monitoring the effects to find further improvements.

The desired result depends on the organization. A hospital and a small online shop may have different risks, service needs and priorities. Decide what useful performance means before selecting technology.

Work through ticket routing

A service desk receives 900 tickets a month. Routing each one takes 3 minutes. Its monthly routing effort is:

The team first reduces ticket categories from 60 to 12. Clearer categories reduce routing time to 2 minutes per ticket:

It then automates the 80% recognized by the new rules. That sends 720 tickets through the automated route, leaving 180 for staff:

Simplification saves 15 hours before automation. Automation then saves another 24 hours of manual routing. The final figure is the time staff still spend routing; it does not include any extra monitoring or maintenance effort.

Choose what to automate

Frequent, repetitive, rule-based tasks are good candidates: creating standard accounts, routing tickets, resetting passwords and running a tested restart script. Clarify the rules and remove waste first. Automating an unnecessary approval preserves that approval and may make it harder to remove later.

Keep human intervention where judgment adds value. Staff may need to assess a high-risk change, resolve an unusual request or support an upset user. Make the exception route clear so that a tool's uncertainty does not leave the user stranded.

Measure the result

Define measures before the change and use the same definitions afterward. In routing, track both minutes of manual work and the share sent to the wrong team. Faster routing that increases misrouting can delay resolution elsewhere.

AI suggestions and chatbots are forms of automation too. Check their output and keep people accountable for decisions.

The seven principles interact. Feedback depends on people sharing information. Simplification depends on understanding value. An iteration must fit the whole service. Looking at these links helps you explain why a decision is sound, especially when several sensible aims compete.

Look at the purpose of the action

Do not identify a principle from a single word. A dashboard is technology, but publishing open changes so other teams can coordinate illustrates collaborate and promote visibility. If the decision concerns using software to perform a repetitive step consistently, optimize and automate is more central.

Several can still apply to the same action. Reusing an effective workflow can support both the current-state assessment and a simpler design.

Resolve tensions in context

There is no fixed ranking of principles. A very simple local shortcut may create extra work for another team. A broad consultation may improve understanding while delaying a small, useful trial. Decide what involvement and scope the situation needs, and explain the evidence behind that balance.

For example, a team should hear from the security specialist whose requirements affect a pilot. It may not need every department to approve every screen. An accountable decision after relevant input can preserve collaboration and still allow a useful iteration to begin.

Follow a monitoring improvement

An organization wants fewer unnoticed outages. It defines that consumer benefit before choosing a tool. It then assesses existing alert rules and keeps those that work. A first iteration covers one critical service, so staff can learn from actual use.

Operations and the service desk agree who handles alerts and can see the work. The plan checks training, service data, vendor support and alert-handling processes. This applies the holistic view through all four dimensions.

The team removes alerts nobody acts on and then automates ticket creation for the remaining useful alerts. Automating the original alert flood would have made poor work faster. The chosen order is supported by the need to simplify and optimize suitable work before automation; it is not a claim that the seven principles themselves form phases.

A strong justification joins an action, evidence and principle: "We kept the tested alert rules because they already identify useful failures, applying start where you are." Simply naming a principle leaves the reasoning unstated.

ITIL defines four dimensions to support a holistic approach to service management: organizations and people, information and technology, partners and suppliers, and value streams and processes. They are perspectives for examining work. They apply to the service management system as a whole and to each individual product or service.

Ask a different question from each perspective

These are not four departments. A service desk touches every dimension. Its people use information and technology, work with external providers, and participate in flows that deliver outcomes to users.

Follow the overlaps

Introducing a monitoring tool is an information and technology decision. It also needs trained staff and clear responsibilities, a vendor support agreement, and a route for responding to alerts. One purchase therefore creates questions in all four dimensions.

Neglecting a dimension can prevent delivery or reduce quality and efficiency. A self-service portal may function technically but become unreliable when nobody owns its content or maintains its request routes. Give each dimension the attention the situation needs. Balance does not mean spending equal time or money on each one.

ITIL (Version 5) applies the same four dimensions to digital products as well as services, using the name dimensions of product and service management.

Scan the external environment

External factors lie largely beyond the organization's control but shape its choices. PESTLE groups them into six kinds:

• Political: government policies, priorities and stability, such as a public-sector policy about data hosting.
• Economic: financial conditions, such as rising energy prices increasing data-center costs.
• Social: expectations and behavior, such as employees expecting remote access.
• Technological: developments outside the organization, such as new AI tools.
• Legal: laws and regulations in force, such as requirements governing personal data.
• Environmental: energy use, equipment disposal and other effects on the natural environment.

Distinguish a government priority from a legal obligation already in force. A new policy direction is political; a binding data-protection requirement is legal. Some developments have several effects: higher energy prices create economic pressure, while energy reporting also raises environmental questions.

Connect each relevant factor to the service. A remote-work expectation may change support hours, access technology, supplier coverage and request routes. PESTLE is useful when it changes the analysis, not when it remains an isolated list of headings.

The organizations and people dimension examines structures, roles, responsibilities, authority, communication, culture, staffing, competencies and leadership. A clear organization chart is useful, but it cannot by itself ensure that a service works.

Make responsibility usable

People need to know who owns a service, who can decide and who performs the work. These arrangements should support the organization's strategy and way of working. When no one owns the whole service, teams may pass a problem between them while each waits for someone else to act.

A named service owner gives people a point of accountability. That person still depends on others to carry out specialist tasks. Clarify how teams communicate and how decisions reach the people who must use them. A role description that exists only in a document does little to help an agent facing an unusual request.

Examine culture and leadership

Culture is the shared values and attitudes that shape how people behave. A culture of trust and transparency makes it easier to report problems early and suggest improvements. Leadership influences that culture through what it rewards and how it responds to bad news.

Suppose agents are judged only by how many chats they close. They may rush conversations even when users still need help. If the intended outcome is useful support, managers need measures and behavior that support solving the user's problem. This connects organizations and people to focus on value and to the quality of feedback.

Check skills and capacity

Competencies are the abilities needed to do the work effectively. Include technical skills and communication skills. Some staff have T-shaped skills: depth in a specialty plus a broader understanding of neighboring areas. A specialist who understands the service desk's needs can explain an issue more usefully at a handoff.

Capacity also matters. A team may know how to run a service but lack enough people to cover its opening hours. Training alone does not solve an uncovered shift. Check the amount and timing of demand as well as the knowledge needed.

Work through a live-chat launch

A service desk adds live chat. The people analysis asks:

1. Who owns the chat service and decides its support hours?
2. Who staffs each period, and can agents handle 2 chats at once without reducing quality?
3. What training helps agents write clear, useful messages?
4. How will agents obtain help with complex issues?
5. Will success measures reward solved problems or only quick closures?

These questions show why the dimension extends beyond headcount. A sufficient number of agents can still struggle if roles are unclear, skills are missing or targets encourage poor behavior. Help each person see how their work contributes to value, so choices during a busy shift support the service's purpose.

The information and technology dimension covers the information and knowledge needed to manage services and the technologies that support them. It includes both service management tools and the information and technology each service delivers or depends on.

Begin with the information

Identify what the service manages, such as customer orders, and what staff need to operate it, such as configuration records and knowledge articles. Then ask how that information is protected, maintained, archived and disposed of.

Useful information must be available, reliable, accessible, timely, accurate and relevant. An article that describes an old application screen may send an agent down the wrong route. A technically excellent knowledge base cannot compensate for content that people cannot trust or access when needed.

Information protection includes who can read or change a record, where it may be stored and how long it may be retained. Data-protection laws, industry rules and contracts shape these requirements. Establish the applicable requirements for the service before selecting a hosting arrangement.

Judge a tool in its context

Service management technology includes ticketing and workflow tools, knowledge bases, inventory and configuration systems, monitoring, analytics and collaboration platforms. Cloud services, mobile platforms, AI and machine learning offer further capabilities.

For a proposed tool, check:

• Compatibility with the current architecture and other systems.
• Fit with organizational strategy and the skills available to support it.
• Regulatory, security and contractual requirements.
• Commercial viability and the ability to continue receiving support.
• Useful automation and other capabilities the service needs.
• New risks or constraints, including dependence on one vendor.

Vendor lock-in occurs when dependence makes changing providers difficult. A product may be easy to buy but costly to leave if data cannot be exported usefully. Evaluate the exit as well as the introduction.

Work through a knowledge-base choice

The service desk compares knowledge-base products. First it checks whether each integrates with the existing ticketing system. It then tests access restrictions so sensitive articles are visible only to authorized staff. The proposed hosting location must meet the relevant data-handling requirements.

The team also asks whether staff can maintain articles without specialist programming. It assigns a way to review content so instructions stay accurate. Tool capabilities, information quality and people who maintain the information all contribute to the result.

Keep judgment around new technology

Culture and the nature of the business affect technology choices. Organizations facing strict regulation or serious consequences from failure may need more cautious adoption. An AI tool raises specific questions about the data it uses, how people check its output and who is accountable for decisions.

A convincing demonstration answers only part of the choice. Examine how the technology will work with the service's real data, users, skills and constraints.

The partners and suppliers dimension examines relationships with other organizations involved in designing, developing, deploying, delivering, supporting and improving services. Contracts and other agreements are part of it, along with the everyday coordination that makes those agreements work.

Understand the type of relationship

Relationships range from formal contracts with a clear separation of responsibilities to flexible partnerships with shared goals and risks. Buying standard laptops from a reseller and developing a new service jointly with another organization need different arrangements.

Almost every service depends on external organizations. Cloud providers, network carriers, software vendors, equipment suppliers, energy providers and building providers can all affect delivery. Identify those dependencies from the service's needs, including suppliers that consumers never see.

Explain the sourcing choice

An organization's sourcing strategy reflects several factors:

• Strategic focus: which work is central to the organization's purpose?
• Culture: does the organization tend to build internally or seek external help?
• Resource scarcity: which skills or equipment are difficult to obtain?
• Cost concerns: can a supplier provide suitable capability more economically?
• Subject-matter expertise: would a specialist improve the work?
• External constraints: what do regulation, policy and codes of conduct require?
• Demand patterns: does seasonal or variable demand call for flexible capacity?

A low purchase price alone does not settle the decision. An inexpensive service without support during the user's operating hours may fail the intended outcome. Likewise, a supplier's specialist knowledge may be valuable even when internal delivery is possible.

Coordinate the whole service

When several suppliers contribute, an internal team or third party can act as a service integrator. It coordinates contributions so that the service works from end to end. This approach is called service integration and management (SIAM).

Outsourcing work does not remove the service provider's accountability to its own customers. If a cloud outage stops an online shop, the shop still needs to communicate with its customers and manage the effect. It also works with the cloud provider through the agreed support route.

Work through outsourced email

Before moving email to a cloud provider, examine availability commitments and support hours. Agree how to report incidents and who manages user accounts on each side. Check data-handling terms, how data will be returned at contract end, and whether backup needs another supplier.

These questions connect to other dimensions. Account responsibilities involve people; data return involves information and technology; incident reporting involves processes. A contract is a starting point for managing the relationship. Performance review, communication and joint improvement keep that relationship useful as needs change.

The value streams and processes dimension examines how activities, workflows, controls and procedures combine to achieve agreed objectives. It makes the route from a consumer's need to a useful result visible, including work carried out by other departments, suppliers and consumers.

Distinguish a value stream from a process

A process can contribute to several value streams. Incident management may help restore a failed service and also support a customer's product launch. Procedures and work instructions describe activities in further detail. In ITIL 4, value-stream steps are built from service value chain activities.

Build a simple map

Name the trigger, such as a request, and the consumer outcome. List the steps in order, identify who or what performs them, and record working time separately from waiting time. Examine handoffs closely: a few minutes of work can sit in a queue for several days.

A laptop request takes 60 working hours. A working day is 8 hours, so that is 7.5 working days. Hands-on work is 0.5 hour to submit the request, 0.5 hour to approve it, 1.5 hours to configure the laptop and 0.5 hour to hand it over. The work totals 3 hours.

Waiting takes 16 hours for approval, 8 hours in purchasing, 24 hours for supplier delivery and 9 hours for a handover appointment. Those waits total 57 hours. Work and waiting together account for all 60 hours.

Only 5% of the lead time is hands-on work. Speeding configuration alone would miss most of the delay.

Use the map to choose improvements

Standard laptops become pre-approved requests. This removes both the 16-hour approval wait and the 0.5-hour approval task. A small stock agreed with the supplier removes the 24-hour delivery wait.

Lead time falls to 19.5 hours, about 2.4 working days. Remaining work is 2.5 hours, so its share is approximately 13%. The larger share comes from reducing total time, even though hands-on work also falls.

Include every contributor

A map containing only IT activities would omit manager approval, purchasing, supplier delivery and the user's handover appointment. Those omitted steps explain much of this delay. Ask who or what performs each action, including automated tools.

A map helps locate a possible improvement; the wider analysis checks whether it can work. Pre-approval needs suitable controls, and stock needs people, funding and supplier arrangements. Revisit the map after a change to see whether waiting moved elsewhere or the consumer receives the result sooner.

A four-dimension analysis begins with the service and the value it should deliver. For each dimension, compare what exists with what is needed. Add relevant PESTLE factors, record gaps and dependencies, and assign actions to owners. Revisit the analysis when the service or its environment changes.

Define the problem and the value

A service desk receives 1,200 tickets each month. Password resets account for 30%, or 360 tickets. At 6 minutes each, resets use 2,160 minutes, or 36 hours, of agent time. A self-service password reset (SSPR) service aims to restore users' access sooner and free agents for more complex work.

That value statement guides the analysis. Installing a reset feature is an output. Users returning to work securely is the outcome the service needs to achieve.

Check all four dimensions

Organizations and people: Name a service owner. Train agents to help users enroll and to handle cases the tool cannot solve. Explain the new route to users clearly. Review agent targets: a falling reset-ticket count should support the improvement, not make successful agents look less productive.

Information and technology: The identity platform needs secure verification, such as multi-factor authentication (MFA). Users must enroll verification methods and keep them current. Log reset events for security review and maintain clear knowledge articles. A working reset feature cannot help someone who has no usable verification method.

Partners and suppliers: For a cloud tool, check availability commitments, support hours and data-handling terms. Sending verification codes by text introduces a messaging-provider dependency. Identify how a failure reaches the right supplier and who coordinates the response.

Value streams and processes: Map "regain access to my account" from a forgotten password to the user working again. Include a simple service desk fallback for users without an enrolled method. Update the incident and access processes touched by the change.

Connect external factors and gaps

Data-protection requirements shape what verification information is kept and for how long: a legal factor. Expectations of round-the-clock access are a social factor. New verification options, including authenticator apps and passkeys, are a technological factor.

A gap such as missing enrollment has connected actions: the identity team enables the feature, the service owner arranges communication, and agents help users prepare and recover through the fallback. Recording only "technology ready" would hide the dependency on people and processes.

Estimate and review the effect

If 70% of the 360 resets move to self-service, 252 no longer reach agents. Their avoided manual effort is:

The remaining 108 resets still need support. This is an estimate of agent time released, not a reason to remove the fallback. After launch, check actual uptake, successful access recovery and remaining demand. Revisit the dimensions when usage, suppliers, technology or requirements change.

A good improvement plan connects evidence to decisions. The seven principles guide the choices throughout the work, while the four dimensions help check what delivery needs. Several principles can support one decision, and a later finding can change an earlier choice.

State the value and establish the starting point

New employees wait 10 working days on average for a laptop, accounts and building access. Their managers report that much of the first two weeks is lost. The desired outcome is productive work from the first day, with a good first experience of the organization.

Focus on value: Measure the share fully equipped on day one and the average days until they are equipped. A count of created accounts alone would miss missing laptops or building access.

Start where you are: Observe 5 recent onboardings. HR already holds start dates 3 weeks ahead, but IT receives late emails. The existing laptop imaging tool works well. Keep that tool and address the information handoff that delays preparation.

Learn through a useful trial

Progress iteratively with feedback: Try the changed approach in one department with about 25 hires per quarter. Review feedback from new employees and managers after each month. Use the results to adjust work before including more departments.

Collaborate and promote visibility: HR, facilities, IT and the laptop supplier use a shared onboarding board. Each new hire's preparation status is visible to the people coordinating the work. They can address missing items before the employee arrives.

The trial needs a clear objective and useful completion criteria. It is small in scope, but a new employee still needs the combination of equipment, accounts and access to work.

Check dependencies and simplify

Think and work holistically: Check roles and training, the link between HR and IT systems, supplier delivery terms and the complete value stream. A quicker imaging tool would not fix a late hiring notification or an unavailable building pass.

Keep it simple and practical: Remove a duplicate step where IT asks a manager to confirm a hire HR has already approved. Its repeated confirmation adds waiting without reducing risk in this case. Necessary authorization still has to be present in the confirmed HR record.

Optimize and automate: Once the flow is simpler and reliable, let a confirmed hire record trigger creation of standard accounts. Give unusual access needs to staff who can use judgment. Check actual readiness and errors as the automated route is introduced.

Explain the decision, not just its label

A useful justification says: "We reused the imaging tool because observation showed it already worked well; this applies start where you are." Another says: "We removed the repeated hire confirmation because it added waiting without reducing risk; this applies keep it simple and practical."

Naming a principle without the evidence leaves the choice unexplained. Show how the decision contributes to the desired outcome and what will be checked afterward. The principles overlap in this reasoning; they do not assign one compulsory stage to each item in the plan.