The six ITIL 4 practices that matter for a 200-person IT shop

Start with six, not thirty-four

ITIL 4 defines 34 management practices. That number alone is enough to stall most adoption efforts before they begin; teams see the full catalog, assume all of it is required, and either over-engineer their rollout or quietly give up. Neither outcome is necessary. For a 200-person IT organization, six practices carry the vast majority of the operational value. The rest are worth knowing about, but not worth staffing, measuring, or reporting on until the foundational six are running well.

The six that earn their overhead

Incident management is non-negotiable. If you cannot restore service predictably when something breaks, nothing else matters. The practice needs a clear definition of what constitutes an incident (as opposed to a request or a question), defined severity levels tied to real impact, and an escalation path that people actually follow. Most organizations already do some version of this; the work is usually tightening what exists rather than building from scratch.

Service request management is the practice that shapes how users experience IT every day. Access requests, equipment orders, password resets, onboarding: these are high-volume, low-complexity transactions that should flow smoothly and predictably. When they do not, users lose confidence in IT regardless of how well the infrastructure runs. The goal is a catalog of requests with defined fulfillment steps and expected timelines.

Change enablement (called change control in earlier ITIL versions) exists to prevent you from causing the incidents you just learned to manage. The practice needs a lightweight classification model: standard changes that are pre-approved and repeatable, normal changes that require review, and emergency changes with an expedited path and a post-implementation review. The most common mistake here is treating every change as high-risk, which creates bottlenecks and encourages teams to route around the process entirely.

Problem management is how you stop fixing the same thing repeatedly. The practice distinguishes between reacting to incidents (which incident management handles) and investigating root causes to prevent recurrence. In a 200-person shop, this does not need a dedicated team; it needs a regular cadence where someone reviews recurring incidents and decides which ones justify deeper investigation. Even a monthly review of the top five repeat incidents will produce measurable results within a quarter.

Service level management gives you a shared vocabulary for what "good" looks like. Without defined service levels, every stakeholder has a different expectation, and IT cannot win. The practice does not require complex SLA documents; it requires honest conversations with business stakeholders about what they need, what IT can deliver, and how both sides will measure the gap. Start with three to five services and keep the metrics simple: availability, response time, resolution time.

Continual improvement is the practice that keeps the other five honest. It provides a structured way to identify gaps, prioritize changes, and measure whether those changes worked. The simplest implementation is a register (a shared list of improvement ideas with owners, priorities, and status) reviewed on a regular cadence. Without this practice, the other five will calcify into bureaucracy within eighteen months.

What to deliberately skip (for now)

Practices like capacity management, availability management, and IT asset management are real and valuable, but they add overhead that a 200-person organization may not need yet. Knowledge management is useful but often becomes a documentation project that produces artifacts nobody reads. Relationship management matters, but in a smaller shop, it happens naturally through proximity. The discipline is not in adding practices; it is in resisting the urge to add them before the foundation is solid.

How to decide what matters for you

The test is simple: does this practice reduce a pain your organization actually feels today? If your teams are drowning in repeat incidents, problem management earns its place immediately. If changes routinely cause outages, change enablement is urgent. If users constantly complain about how long requests take, service request management is the priority. Start with the pain, not the framework catalog.

The six practices above are not the only ones that will ever matter. They are the ones that matter first. Get them running, measure them honestly, and let the data tell you when it is time to add the seventh.

← Back to Insights