Broadly defined, a service-oriented culture can be said to be a set of beliefs and behaviors of a particular group, directed at activities that are deemed helpful to others. Within the context of IT organizations, those beliefs and behaviors typically revolve around being:
- Reliable – seen as dependable, trustworthy, accurate, and infallible
- Consistent – seen as adhering to the same principles, actions, and outcomes
- Proactive – seen as prepared and controlled, especially when things are not going well
- Responsive – seen as responding in a sympathetic or favorable way
The story of The Phoenix Project speaks to this paradox. The driving force behind missed deadlines, service delivery failures, or unmet expectations is not technical incompetence, lack of supervision, or poor leadership, but unregulated work in progress. Failure to properly manage demand for services through sound project, change, and demand management techniques will create the conditions for poor service delivery. Every IT professional has felt the tension between working on planned tasks versus having to immediately respond to someone who has screamed loudly or dropped the name of someone high above the CIO. That pressure is doubly worse when one has to drop planned tasks to respond to an outage or to fix a major service defect.
The paradox of the operations–concierge divide is that efforts to be immediately responsive to unregulated end user demands results in a reactive IT culture whose performance spirals downward because of the cycle of over-commitment and underperformance. The only way to escape this downward trend is to place a moratorium on the introduction of new work into the system, so that the entire system can catch up and reduce the amount of work in progress. That typically requires an intervention of some sort – either new leadership or executive support that comes right from the top.
The trick to building a proper service oriented culture – one that is characterized by reliable, consistent, proactive, and responsive IT services – is to avoid spiraling into the cycle of over-commitment and underperformance in the first place; and the way to do that is to not say no over and over, but build into the organization the proper project, change, and demand management processes for regulating the flow of work. That means investigating and learning about ITIL and other standard processes, and applying some of the lessons learned from The Phoenix Project. These include:
- Recognize that performance improvements are truly possible only when applied at the constraints that are negatively impacting the flow of work through the organization. Improvements at other places will do little to improve overall service quality.
- Identify and protect the critical resources in the organization, and do everything possible to make sure they are not dragged into serving ad hoc requests on demand.
- Control the flow of work by proactively deciding what work that is to be accomplished, as opposed to letting that be dictated by the tone and volume of ad hoc requests. That requires governance, which is key to deciding which projects should be deferred.