Don't disqualify the adhoc organization too quickly
By Cleo van Engelen
Who doesn't recognize these objectives? IT service delivery must be predictable, continuous, and of high quality. The 'business' should be able to rely on IT service delivery to achieve their goals. And even though all reports are nicely in the green, the business still seems not to be getting what they need: speed and innovation.
The paradox of IT-Service delivery?
In most organizations, IT service delivery is designed to provide quality, predictability, and continuity. We measure the quality of a service by delivering an uptime of 99.x%. Predictability is demonstrated by planning fixed maintenance periods and sending proper notifications to stakeholders about them. Continuity is ensured by implementing a lengthy and intensive process of change and release management. Lots of ITIL, lots of processes, lots of accountability points, lots of hierarchy, and lots of bureaucracy.
Don't get me wrong: all these things have utility and necessity, and they've become best practices for a reason. However, they make IT and IT service delivery anything but flexible. And precisely that flexibility can be a necessary condition for serving the business.
In our practice, we often use models to assess the maturity of an organization. Such models imply that a higher level of maturity is better. However, this maturity is then expressed in terms of predictability, quality, and continuity: secured in processes and procedures. My experience is that low maturity in these aspects doesn't necessarily mean a lack of quality, but rather a shift in focus. The focus on realization, flexibility, and results. So, my idea is: let go of the model and look at what is necessary and desired. Don't automatically disqualify adhoc service delivery.
Embrace adhoc service delivery
With a more adhoc service delivery, the focus shifts. In an adhoc organization, it's easier to respond to needs, incidents, or other types of changes. To make such an organization or service run, a lot of responsibility for the outcome needs to be placed with the people. This responsibility isn't secured in established (standardized) processes and procedures but is secured by the involved and qualified employees "who know what's needed." In an adhoc organization, there's more freedom for these employees to act with a focus on results.
Especially within the government, this is difficult to justify. Setting up an adhoc organization or service also brings uncertainty with it. In my view, the success of an adhoc organization depends on leadership: daring to steer towards results and not towards the process. Daring to intervene in incidents but not becoming paralyzed if something goes wrong (daring to fail?). At the management level, there must be support for and clarity about what such an organization / project / program can deliver AND what it is not. In the case of a specific vision or goal, adhoc organization or service delivery can be a perfect match.
Want to know more?
Do you want to learn about how to successfully structure an IT organization? Please get in touch with Cleo van Engelen