Don't disqualify the adhoc organization too quickly

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.

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.

Do you want to learn about how to successfully structure an IT organization? Please get in touch with Cleo van Engelen