At its heart, quality is a matter of meeting the business need. In most projects, obtaining a clear understanding of the business need and translating that understanding into product specifications and a project plan can be one of our biggest challenges.

The Information Technology Infrastructure Library (ITIL^®) is a process model for IT Service Management, just as the Capability Maturity Model Integration (CMMI^®) is a process model for product engineering projects.

Can a model that is not about projects help us with our development projects? Absolutely! ITIL can help us to assure the quality of the systems we develop by providing the basis for understanding the business need and taking action on that understanding. ITIL can be our foundation for project success by defining the context for our project and for the product we will build!

What is ITIL?

The British government originally developed ITIL in the 1980's to improve the performance of government IT service groups. Since then, it has evolved and matured as many governments and companies across Europe have embraced and supported it. It has just begun making inroads in the US in the past few years, as organizations have discovered and capitalized on its benefits.

ITIL is a library of documents that describe all of the processes involved with IT Service Management. As the graphic shows, this library is centered around two core books (Service Delivery and Service Support) that describe the core IT Service Management processes.

(Click to see a larger version in PDF format)

Service Delivery comprises the proactive processes for ensuring that IT Services are aligned with business needs and financial constraints.

• Service Level Management -- Agree to and document business customers' requirements for IT services, and monitor actual performance against them.
• Financial Management for IT -- Account for the cost of IT services and make that information available for decision-making purposes. (Also charge users for IT services if such an arrangement is in force.)
• Capacity Management -- Balance demand against cost to ensure that appropriate IT service capacity (e.g. processor cycles, network bandwidth, disk space) is always available.
• Availability Management -- Balance demand against cost to ensure appropriate levels of availability (e.g. 24x7, 99.95%) of IT service.
• IT Service Continuity Management -- Coordinate with Business Continuity Management to ensure that IT services can be maintained or recovered as needed by the business in case of disaster.

Service Support comprises the more reactive processes for ensuring that IT Services actually meet the business needs.

• Incident Management -- Restore IT service as quickly as possible when a service interruption occurs.
• Problem Management -- Identify the root causes of IT service interruptions, devise work-arounds, and recommend permanent resolutions.
• Change Management -- Consider all changes to IT Services, approve them, and schedule them for implementation.
• Release Management -- Ensure that releases of new or changed services do not adversely impact day-to-day operations.
• Configuration Management -- Manage the database of all of the IT service configuration items (including hardware, software, people, facilities, etc.).

Several other books support those two core books, including:

• Security Management -- Ensure that the IT services meet all security requirements (including those imposed by the business customers, the organization itself, and government regulation).
• ICT Infrastructure Management -- Maintain and operate the IT infrastructure (including hardware, networks, operating systems, telecommunications, etc.)
• Application Management -- Maintain the portfolio of applications that are used by IT service customers and run on the IT Infrastructure.

The Application Management process includes all activities that surround building and maintaining the applications. This includes projects to develop new applications, enhance existing ones, fix bugs in them, or upgrade them, as can be see by the inclusion of "Requirements, Design, Build and Deploy" under Applications Management in the graphic.

A Context For Projects

In ITIL, "Requirements" is not the beginning of a project as it is in project-oriented models. Indeed, project initiation follows a very well structured path that culminates in a development project.

• For new applications or enhancements to existing applications, that path starts with the Service Level Management process, as customers express the need for application capabilities that do not currently exist.
• For bug fixes, it starts with the Incident and Problem Management processes as problems are encountered and resolutions to those problems are identified.
• For technology upgrades, it may start with any of the Capacity, Availability, Continuity, Security, Infrastructure, or Application Management process, as the need for structural improvements are identified.

In any of these cases, when the need is identified, it is documented in a Change Request. The Change Management process then brings together experts from all of the other processes to examine the proposed change and determine all of its ramifications, requirements and impacts. The viewpoints include the Customer (through Service Level Management), Financial, Capacity, Availability, Continuity, Security, Application Portfolio, Infrastructure, and Support. Approval of the change results in initiation of a project.

By the time the Application Management process kicks off a development, enhancement, bug-fix, or upgrade project, a tremendous amount of deliberation and analysis as already taken place. The Requirements Engineering activity starts with a lot more than a fuzzy idea or notes on the back of a cocktail napkin. All of the key high-level requirements have been identified, including the functional capabilities that the customer needs, the non-functional requirements (e.g., security, availability, performance), the financial investment that is appropriate, and how it will fit into the application portfolio and IT infrastructure.

Defining "High-Quality"

Because the ITIL processes involve all of the key players, projects that are initiated in that environment are much better positioned for success. The definition of "high-quality" has been worked out, not only from the perspective of the ultimate business customer, but also from the perspective of the financial constraints and technical merit.

The Requirements and Design activities have an excellent basis for producing specifications that depict what should actually be built. The developers have plenty of background information to help them to make appropriate technical choices throughout the project. And when they have questions, it is clear to whom they must appeal to get the answers they need. The testers have all of the information they need to verify the quality of the system from the perspective of all of the stakeholders. And the project manager is better positioned to make trade-offs as the project progresses toward success.

In short, because of the clear and complete definition of "quality," the project begins with a high likelihood of producing quality. A foundation for success is exactly what we all need for our projects!