HOW MANY STEERING WHEELS DOES YOUR CAR HAVE?

An efficient organization should have one non-redundant management system.

Your management system is your steering wheel and an efficient organization needs to have only one steering wheel.

For comparison, just consider a car, and imagine you have two steering wheels, or three, or four…. Would you be willing to have any passengers in that car, knowing that these could use their own steering wheel to also drive that car when you’re already in the driver’s seat? Any idea where you’d end up? Not an attractive perspective, is it?

Then why do we allow our organizations to have so many steering wheels?

As an example, let me show you some of these steering wheels, and their effects.

• The IT team and the HRM team have different steering wheels. To some level, the IT team may have agreements in place on the infrastructure and the support they provide to their customers (their services). But have you seen the agreements of the HRM team? Most likely not, for the simple reason that it’s not very common for HRM teams to make any agreements about their contributions to other teams at all… And is this any better with Finance teams, Catering teams, Legal teams, Housing, Security, or any other facility team?

So, how should they ever cooperate in an enterprise service management strategy?

• The IT team and the business teams have different steering wheels. For decades, IT teams have become increasingly aware of the fact that they are service teams. But what about the (primary) business teams? Would they specify their value creation for their external customers the same way the IT team does this for their internal customers? Think of a municipality, a hospital, or any other line of business. Would they have similar service definitions? Similar service agreements? Similar reporting structures? Similar coordination tools?

So, how should they ever cooperate in an enterprise service management strategy?

• Different IT teams within the IT organization often have different steering wheels. Just compare the steering wheels of Development and Operations – even in organizations that claim to use DevOps techniques. These steering wheels all show different interaction models with the customers, different tools for coordination purposes, different definitions of ‘service’. As a consequence they have different management systems, different steering wheels.

So, how should they ever cooperate in an enterprise service management strategy?

• The Service Desk and the Project Management Office have different steering wheels. Projects are managed from a very different perspective than ‘normal services’. Project management techniques focus on cost, resources, risks, infrastructure output. They are not related to the continuous support of facilities for customers for a long time. They have one goal that is limited in time, and that is to realize the targeted result according to the constraints that were given to the project team. Service delivery has a very different goal that is related to the continuous support of facilities for customers for a long period. As a result, these two have very different management systems, very different steering wheels.

So, how should they ever cooperate in an enterprise service management strategy?

And if projects have different steering wheels than services, what about programs and portfolios? It may be obvious that all differences between service and projects are multiplied for collections of projects in programs and portfolios.

How do you get rid of all those steering wheels?

If you decide to replace all these different steering wheels of teams, task domains and techniques (like agile, Lean, or DevOps) with one enterprise steering wheel, all activities – including project activities – should be organized in the perspective of one integral enterprise management system, to create one integrated steering wheel. All of that can only be solved if the people in the enterprise learn to work from a shared architecture for the enterprise. In this case: an enterprise management architecture.

CONTROL is first of all a matter of MANAGEMENT and only then of TECHNOLOGY

That means they would adopt one underlying set of principles, guidelines, and building blocks for everything they do, including one shared dictionary . This architecture of the organization’s management should enable a systematic approach for each team, each task domain, everything the organization does, to be able to organize an efficient and enterprise-wide delivery of the one thing any modern organization should focus on: delivering value to customers through services.

We live in a Service-Dominant logic era.

The structure of the solution

From a system perspective, this solution should encompass each essential component of the organization, and each relationship between these components. One of the essential components of that system is the process architecture, the logical arrangement of the organization’s activities. Note: this does not include the People component or the Technology component, because these are only involved in procedures and work instructions, not in processes (read: "Demystifying the term PROCESS ").

Projects (programs, portfolios) should be based on the very same process architecture as services, which means that there should be only one underlying process architecture for all projects and services – but also for all secondary facility teams and for all primary business teams. As soon as this requirement is violated, inefficiency will strike.

The more this requirement is violated, the less efficient the organization will be.

Processes are core

The second essential component of the system – the People - always changes: the people that worked in the organization two years ago are not the same people that will work there two years from now. The third essential component of the system - the Technology – also changes constantly: we’re replacing our tooling on a daily base to improve our performance. But the things we do – the Process – will always be the same, unless we migrate to a different line of business. The consequence of this is that all teams, all task domains, and all projects should always follow processes to contribute to the efficiency and to the goal of the current organization: delivering value through services.

What makes this so difficult?

In theory, it’s very simple to achieve this. You only need to put all teams, all task domains, all techniques and all projects in the context of the underlying process architecture, and you’re done.

The difficulty – as always – is in the organizational change that is required. Project-minded people that focus on infrastructural projects simply do not relate to the goal of the organization. After all, any focus on a single component of the system does not relate to the performance of the whole system. These project experts act at a lower level of maturity, mostly at level 1 or 2 of the Value Maturity Model . They focus on the infrastructural change instead of the continuous delivery of services to customers.

And as long as each team, each task domains and each technique holds on to its private steering wheel, nothing will change.

The dot on the horizon

When your organization is infected with these multiple steering wheels – including the project steering wheel – and you want to get rid of that to become one integrated enterprise, then you’ll first of all need to find the dot on the horizon that tells you where to go from here: the enterprise service management system, based on the enterprise service management architecture. Once you’ve determined that enterprise goal, you’ll have to decide whether to approach this in a bottom-up or a top-down approach.

Many of your teams will have invested heavily in their local solutions, their own steering wheels. This is where you should expect to run into resistance when you select a top-down approach. ?Furthermore, a top-down approach will require true leadership from the top of the enterprise, and it is exactly the involved C-level that shines in its incompetence here: they tend to focus on the technological aspects of the organization. Like the city’s alderman tends to focus on leaving an impressive bridge or a new theater after his term in office, instead of solving the local unemployment.

For these – and other – reasons, a bottom-up approach might be more convenient, even though the effect of this approach will take longer to make a difference. In the bottom-up approach, one team that has the need, the knowledge, and especially the guts to take a first step, will start a small deployment project, inviting some of the neighboring teams to just look over their shoulders to see what’s happening - to remove their fear and demonstrate the benefits they could also achieve. When this first initiative is successful, other teams will follow, and the snowball will eventually roll over the whole enterprise.

By the time it’s half-way, the C-level will pick it up and claim ownership of the success.

This will of course only work if the approach towards that dot on the horizon is beneficiary for the enterprise as well as for each team, task domain and technique, but it should also be easy, affordable, cost-effective, and sustainable in all conceivable ways. That will require a solid architecture. And that’s where USM’s new thinking kicks in: the concept of a single steering wheel for the enterprise.

Or in USM terms: the concept of a single link to connect all supply chains and supply networks.