When initiating your organization design work, define its scope as clearly as possible

Management Kits-Org-Design-Scope-Blog.png

When it comes to organization work, clearly defining your scope – or your limits – is as important as linking your design work to your strategy and basing it on principles.

Why? Because if you do not clearly define your scope, you might end up designing pieces of the organization you would rather leave alone (at least for the time being).

Many of the better reasons to set limits for your design work have to do with expectations and demands from stakeholders, regardless of whether they are internal or external.

In highly regulated industries, regulatory authorities may have more or less strict demands for how to structure certain functions or their interfaces (e.g. putting ‘Chinese walls’ between functions whose interaction may cause conflicts of interest), or having specific roles with appropriate levels of authority in the first place. Embarking on a design effort, one of the first tasks then must be to fully capture those external demands and integrate the according requirements into your design challenge.

In corporate contexts, there are often internal stakeholders who have legitimate demands on your design challenge. An example from one of our projects was a divisional CEO asking that unit heads for small, but strategically important businesses would be represented in the regional and country organization leadership teams. Her goal was to ensure that those franchises get enough visibility and influence over the dominant but maturing business lines. This “non-negotiable” requirement was directly linked to the enterprise strategy, but at the same time imposed a limit (in the sense of a pre-given element for the structural set-up) on the organization design effort. In other cases, we have seen corporate organizational design guidelines, e.g. including directives concerning appropriate spans of control, the number of layers deemed acceptable, or rules governing the (co-)location of leaders and their teams. Those rules may be more or less clear, but as with external regulations, we recommend explicit sensemaking regarding the actual requirements and their influence on your work. This may involve going back to the stakeholder to ask for clarification or probe design options.

Last not least, stakeholder requirements may not only come from top management, and thus with the blessing of hierarchy, but can result from the demands of peers as well: for example, when the business divisions require certain contact points from enabling functions to ensure delivery of services (HR business partner roles are a typical example).

Identifying, acknowledging, and making sense of such requirements when articulating your design challenge is an important task early on in any design project.

Beyond the limits and requirements imposed by internal and external stakeholders, there are restraints you may want to define all by yourself, in your design team. For example, there may be teams or processes with a particular reputation for their performance and functionality – and you may choose to not touch them needlessly.

A final, and voluntary restraint concerns the level of detail that is delivered as part of your design effort. In other words, you may choose to design by not designing. For example, you may leave detailed organizational set-ups on lower levels to those teams to sort out themselves (and offer your help and guidance to them in turn). A recent user of our Organizational Structure Kit limited a leadership team workshop on organizational links to only identifying the interfaces between units, leaving the details of organizational collaboration to subsequent iterations.

The Organizational Structure Kit comprises a framework section, a tool and an example agenda serving org designers, managers and the facilitators supporting them. It enables them to come up with a crisp and practicable scope to inform and focus their design work.