A Manifesto for Service Management Agility—Part I

Service managers who have been indoctrinated with the principles of such frameworks as ISO/IEC 20000, CobiT or ITIL may find it difficult to lower their esteem and the importance of maintaining accurate, complete and timely documentation. After all, it is precisely in this area that many organizations show egregious weaknesses. Difficulties in understanding problems, in resolving incidents, in controlling changes and in fulfilling service requests ensue.

Of course, the manifesto is only talking about relative values. It is not saying that the documentation may simply fall by the wayside. To my understanding, the point of the proposition in a service management context hangs on the distinction between meeting specifications and delivering value.

The heritage of the quality management system movement, as expressed in the ISO 9000 family of management standards (including ISO/IEC 20000), is the belief that quality is an issue of meeting specifications. If you deliver precisely what you agreed to deliver, managing its creation and delivery in precisely the ways that comply with the specifications and the standard, then that delivery is supposed to be of impeccable quality. We see the same phenomenon in the project management world. Many would say that we have correctly managed a project if it is on time, within budget and delivers the specified deliverables.

The great difficulty that the agile movement has identified in these beliefs is that our specifications are often wrong. Or at least, our specifications are often incomplete, out of date or rapidly changing. Rather than simply doing what was agreed, we need to find light-weight means for identifying issues and addressing them rapidly and effectively. The key word here is “light-weight”. After all, most project management frameworks recognize that a project, its scope, its plan, the specifications of its deliverables are all subject to change control. But what happens in practice reveals the ineffectiveness and the inefficiency of such controls. In virtually all the projects I have ever witnessed, the management principles have shown themselves to be useful for reducing project scope (which reduces the planned value), re-planning delivery dates (which reduces cumulative lifetime value), or reducing (or increasing!) project resources (both of which reduce value, due to either lower performance or higher costs). I leave aside the costs in terms of demotivation and stress. So, traditional, non-agile methods are good at reducing value and, at the same time, increasing risk. Certain light-weight methods for managing work, such as kanban, are good at increasing value and reducing risk.

Returning to the relative importance of service value and service documentation, the key point is that it is more important to use the potential value of the service output as the touchstone for how we manage services, rather than the degree to which the service meets its specifications. The classic example of this is the customer who contacts a service desk for support. The service desk agent follows precisely the policies and the procedures that have been established. But, because the particular case raised by the customer includes a number of conditions that were not foreseen in the service specification, the output is of no value to the customer. The result? A service that was “successfully” delivered according to the service designers, but one that failed from the customer’s perspective. Who has not had to submit to such frustration?