Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 29110-5-4: Very Small Entities — Service Delivery Guide
Systems and Software Engineering — VSE Service Delivery Profile
Service Delivery Framework for Very Small Entities
ISO/IEC 29110-5-4 extends the VSE profile framework to service delivery organizations. While Parts 5-1-1, 5-1-2, and 5-2-1 focus on software and systems engineering (development-oriented VSEs), this part addresses the needs of VSEs that provide IT services — including software as a service (SaaS), IT support, maintenance, consulting, and managed services. The service delivery profile defines process areas specifically designed for service organizations, including Service Level Management, Incident Management, Problem Management, Service Request Management, and Service Continuity Management.
The service delivery profile recognizes that service-oriented VSEs face different challenges than development-oriented VSEs. In a service context, the primary customer concern is not “will the software be delivered on time?” but “will the service be available when I need it?” and “how quickly will my issue be resolved?” These different concerns require fundamentally different process areas and performance metrics.
The standard defines two service delivery profiles: Entry Service Profile (for VSEs starting formal service management) and Basic Service Profile (for VSEs with established service operations). The Entry Service Profile requires 4 process areas with 8 work products, while the Basic Service Profile requires 6 process areas with 15 work products. This tiered approach allows service-oriented VSEs to start with minimal process overhead and expand as their service portfolio grows.
| Process Area | Service Profile Level | Key Outcomes | Essential Metrics |
|---|---|---|---|
| Service Level Management (SLM) | Entry + Basic | Define service catalog, establish SLAs, monitor service performance, conduct service reviews | SLA attainment %, service availability %, response time vs. target |
| Incident Management | Entry + Basic | Log incidents, classify and prioritize, resolve or escalate, close and verify | Mean time to resolve (MTTR), first response time, incident volume trend, escalation rate |
| Problem Management | Basic only | Identify root causes, document known errors, implement workarounds, track problem resolution | Problem backlog age, recurring incident %, RCA completion rate, permanent fix ratio |
| Service Request Management | Entry + Basic | Maintain request catalog, process standard changes, fulfill service requests, track request status | Request fulfillment time, request volume, fulfillment cost per request, customer satisfaction |
| Configuration Management (Service) | Basic only | Maintain service CI database, track service dependencies, audit service configurations | CI database accuracy %, audit findings, configuration drift incidents |
| Service Continuity Management | Basic only | Define continuity strategy, develop service continuity plan, test and maintain plan | Recovery time objective (RTO), recovery point objective (RPO), plan test frequency, test pass rate |
Engineering insight: For most service-oriented VSEs, the Incident Management process area delivers the fastest return on investment. A formal incident management process — even at the Entry level with just a ticketing system, priority matrix, and escalation rules — typically reduces mean time to resolve (MTTR) by 30-50% within the first quarter. The key mechanism is systematic prioritization: without a formal process, all incidents are treated as equally urgent, leading to inefficient resource allocation.
Adapting Service Management for Small Teams
ISO/IEC 29110-5-4 recognizes that service management frameworks like ITIL (Information Technology Infrastructure Library) were designed for large enterprises and are impractical for VSEs without significant tailoring. The standard provides explicit guidance on how to scale down ITIL-aligned processes for small teams. For example, ITIL’s 5-stage service lifecycle becomes a simplified 3-stage cycle in the VSE profile: Plan Services, Deliver Services, and Improve Services. The 26 ITIL processes are condensed into 6 process areas that cover the essential capabilities without administrative overhead.
Common implementation challenge: service-oriented VSEs often struggle with the “service catalog” concept because they offer highly customized services rather than standard packages. The standard addresses this by allowing a service catalog that describes service “types” or “categories” rather than fully specified service offerings. For example, a consulting VSE might list “software development consulting” and “IT architecture review” as catalog entries, with SLAs defined per engagement rather than per predefined package.
The Incident Management process is the operational heart of the service delivery profile. The standard defines a 5-step incident lifecycle: detection and logging, classification and initial support, investigation and diagnosis, resolution and recovery, and closure. For each step, the standard provides VSE-appropriate guidance — for example, the classification step uses a simple 3-level priority matrix (Critical, High, Normal) rather than the 5-level schemes common in enterprise frameworks. The escalation rules are also simplified: a Critical incident escalates to management after 4 hours, a High incident after 8 hours, and a Normal incident after 24 hours (with VSE-specific adjustments based on team size and customer agreements).
Critical service risk: without a formal Service Continuity Management process, a VSE is one critical incident away from business failure. The standard requires at minimum a documented continuity plan that identifies: (1) which services are business-critical, (2) what backup/redundancy exists for each critical service, (3) how to recover each service within the agreed RTO, and (4) who is responsible for executing each recovery step. For a small VSE, this plan might be 3-5 pages and tested annually, but its existence can mean the difference between a 2-hour outage and permanent business damage.
Frequently Asked Questions
Q: Can a VSE be certified for both the development profile and the service delivery profile?
A: Yes. Many VSEs offer both development and services, and the standard supports dual certification. In such cases, the organization typically integrates the development and service profiles by using common processes for project management, configuration management, and quality assurance while maintaining separate processes for development-specific and service-specific activities. The combined assessment typically takes 4-6 days.
A: Yes. Many VSEs offer both development and services, and the standard supports dual certification. In such cases, the organization typically integrates the development and service profiles by using common processes for project management, configuration management, and quality assurance while maintaining separate processes for development-specific and service-specific activities. The combined assessment typically takes 4-6 days.
Q: How does the service delivery profile handle customer-owned SLA requirements?
A: The Service Level Management process area explicitly addresses this. When a customer mandates specific SLA targets (e.g., 99.9% uptime), the VSE must assess its capability to meet those targets before agreeing to them. The standard requires a formal SLA feasibility assessment that considers current resource levels, infrastructure capacity, and historical performance data. If the VSE cannot meet the requested targets, it must negotiate adjusted targets or decline the engagement.
A: The Service Level Management process area explicitly addresses this. When a customer mandates specific SLA targets (e.g., 99.9% uptime), the VSE must assess its capability to meet those targets before agreeing to them. The standard requires a formal SLA feasibility assessment that considers current resource levels, infrastructure capacity, and historical performance data. If the VSE cannot meet the requested targets, it must negotiate adjusted targets or decline the engagement.
Q: What tools are recommended for service desk operations in a VSE?
A: The standard is tool-neutral but recognizes that affordable SaaS service desk tools (e.g., Zendesk, Freshservice, Jira Service Management) make the Entry Service Profile accessible to even 2-person VSEs. The key requirement is that the tool supports: ticket logging with priority classification, automated escalation based on SLA targets, and reporting on key metrics (ticket volume, resolution time, customer satisfaction). Spreadsheets are acceptable for Entry profile but become impractical at Basic profile.
A: The standard is tool-neutral but recognizes that affordable SaaS service desk tools (e.g., Zendesk, Freshservice, Jira Service Management) make the Entry Service Profile accessible to even 2-person VSEs. The key requirement is that the tool supports: ticket logging with priority classification, automated escalation based on SLA targets, and reporting on key metrics (ticket volume, resolution time, customer satisfaction). Spreadsheets are acceptable for Entry profile but become impractical at Basic profile.
Q: How does Problem Management differ from Incident Management in the VSE context?
A: Incident Management restores normal service operation as quickly as possible (firefighting mode), while Problem Management finds and eliminates the root cause of incidents (preventive mode). In the VSE context, Problem Management is only required at the Basic Service Profile level because it requires dedicated time for analysis that small teams struggle to allocate. The standard recommends that VSEs dedicate at least 10% of service team time to problem management activities, including root cause analysis and known error documentation.
A: Incident Management restores normal service operation as quickly as possible (firefighting mode), while Problem Management finds and eliminates the root cause of incidents (preventive mode). In the VSE context, Problem Management is only required at the Basic Service Profile level because it requires dedicated time for analysis that small teams struggle to allocate. The standard recommends that VSEs dedicate at least 10% of service team time to problem management activities, including root cause analysis and known error documentation.
