Under-engineering
“Under-engineering” is when an operating model’s capabilities are not sufficiently engineered to meet the performance expectations. It does not refer to the amount of design and engineering work which could be substantial, but whether that design and engineering work has been good enough.
There are many reasons a project or change programme’s capabilities may be under-engineered which are covered in the section below. Under-engineering is a substantial risk to project or change programme success.
This page looks at how a change team can go about obtaining a holistic and complete understanding of the operating model to ensure that all aspects of the operating model are covered. If an aspect is not covered due to time and budget constraints it can be highlighted to the programme owner’s for risk assessment and mitigation decisions.
The last section on this page covers real examples of under-engineering which I have seen and been involved in remediating. Our objective is to ensure remediation is not required or at least minimized.
The impact of an under-engineered capability in a transformation programme is that it can lead to operational inefficiency, objectives not being met, and increased operational risk. Rectifying under-engineered capabilities can cost additional money and time during which business and operational risks may be substantially elevated.
Avoiding under-engineering
Potential reasons for under-engineering include:
Not fully understanding the complexities and nuances of the problem being solved
Lack of experience or expertise in the subject domain
Cost constraints leading to too simple solutions
Time constraints leading to insufficient analysis
Not fully understanding the actual need
Aiming for simplicity instead of addressing complexity
Aiming for a minimum viable product which then lacks critical functionality
Over reliance on existing solutions which may not be suitable
Overlooking non-functional requirements
Inadequate testing.
Under-engineering still occurs despite the use of best practices by business architects, business analysts, and product owners, and the use of stakeholder working groups and cross-functional teams etc.
Avoiding under-engineering requires a holistic understanding of the operating model and a technical understanding of how the operating model works or needs to work.
This page shows how an operating model can be understood holistically and completely by looking at the elements of an operating model across four layers. Knowing all the elements at these four levels allows the full scope of work to deliver a robust operating model to be identified and covered in the project plan.
The page covers a lot of content. If you are a hiring manager you may prefer to connect with me via LinkedIn and discuss the approach.
Importance of operating model capability elements
The anchor point for understanding how an operating model works is understanding what it does - i.e., its capabilities.
My frame for considering how an operating model works is to consider what impacts a capability across four layers: ‘single act’ (a task), multi-act’ (a process), multi-service (operations), and organisation (as part of a system). It is a useful framework for considering what has been missed.
Whilst a ‘single act’ capability may seem a granular starting point, 60% of elements which may affect the outcome can be identified at a ‘single act’ level (as my diagrams below show) so it is a useful way of simplifying how an operating model works. The additional three layers add in elements to consider when more complex capabilities are built, when a team is covering multiple capabilities, and when the capability is impacted by the wider organisation and environment.
Refer to diagrams below for the elements.
Operating model elements at single-act level
‘Single-act’ level is the lowest capability element level in the operating model.
Even at ‘single act’ capability level there are many factors which can influence the performance of the act and, depending on the impact of the act, on the performance of the operating model for stakeholders.
Changes to capabilities need to consider the impact on each of the elements because they come together to result in the outcome of the act. Many of the factors can have significant impact on their own, let alone in combination.
Execution performance can be impacted by environmental impacts to the factors, such as changes in demand and staff attrition.
Impacts of single-act capability omission or under-engineering
Even at ‘single-act’ capability level an omission or under-engineering can have significant performance impact. For large transformation projects it is likely impossible to cover all capabilities sufficiently well and there will always be ‘emerging properties’ of an operating model which are only evident after deployment. These adjustments are usually covered off in a warranty period.
Understanding of how the act works is necessary to ensure that a new design will work as required
An act is not only about information technology, even when it is fully automated
Digitisation requires granular understanding of an act to convert a manual process to digital
Automation of the act also requires granular understanding of the act to write the required code
Moving to a digital business model changes the performer of the act to the customer who may not be in possession of the required knowledge and skills
Moving to a digital business model changes the performer of the act who may not complete the act to the required standard or conduct (including fraud)
A change to one of the components of an act may require changes to other components for the act to be performed
Poor design of a component of the act affects the outcome of the act
An act performed by a human may be reliant on the knowledge and skills of the person so will be performed differently by another person with a different outcome
A human performer may be covering for undocumented elements of the act which need to be known by a different performer or for automation.
Customers experience detail so can decide to buy, or repeat buy, on the basis of their experience on a single act
Some acts have more impact than others, but some have significant impact or may be critical
A single act in a sequence can prevent progression or completion
A single act in a parallel network can prevent completion
An act may not be able to be started unless the required inputs are available
An act may need to be repeated if it is not done to standard
The need for an act to be performed needs to be known
The time taken to perform the act depends on the act itself, the effectiveness of supporting tools, the available and accessibility of knowledge, the standard of the inputs, the presentation to the performer, and the level of automation
There may be a time in which the act needs to be completed
The performer of the act needs to be available
The outcome of the act needs to be fit for purpose
Understanding of how the act works provides the basis for effective root cause assessment for problem solving.
Organising the elements
The factors in a ‘single act’ capability design can be grouped into 9 categories which usually have specialists in a change project. Even at ‘single act’ level the challenge of avoiding under engineering becomes clear. The challenge increases when we look at more complex capabilities.
Although these elements have specialists in a change project, who has the responsibility for ensuring that they all stitch together as a whole so that the operating model performs as expected?
Does that person have the full breadth of experience, skills, and knowledge to perform that role, or is there over reliance on the ‘line’ contributors to have sufficient vision and knowledge to look beyond the current operating model and effectively design a ‘to-be’ operating model?
Additional operating model elements of a multi-act capability
‘Multi-act’ level is the second level up in capability elements of an operating model.
The number of ways operations performance may be impacted or change projects fail to deliver on their expected benefits increases when we expand the view to ‘multi-act’ capabilities.
In addition to the elements of a ‘single act’ capability we have additional elements to consider in the capability design, plus many of the elements in the ‘single act’ capability will apply to each of the acts in a multiple act capability.
The multiple acts in sequence and parallel has created a process. The grouping may make up the entire process, or make up a sub-process which combines with other acts and/or sub-processes to complete an end-to-end process.
The individual activities or sub-processes may make up a capability, or the entire end-to-end process may be inside a capability.
The end-to-end process activities create a service which is how users (which may also be customers) access a capability. A service may utilize one or more capabilities. Execution teams may handle many services which brings in the next layer of operating model elements.
Additional operating model elements at a team level
Operational (team) level is the third capability element level in the operating model.
It is rare that an operational unit will handle only one act (task) or one service. Usually they will handle many. Handling many services adds additional elements to operational performance.
These elements often fall outside of a project scope until the business impact analysis (BIA). By that point the impact is pre-determined whereas it should be addressed up-front before the design sign-off.
Additional operating model elements at an organisation level
This is the highest level in the operating model - impacts from the rest of the organisation and from the environment.
At this level operational performance is impacted by changes in the organisational structure, allocation of funding & resources, changes to the products and services required to meet the customer proposition, regulatory change etc.
For longer projects the anticipated benefits can be consumed before the change is delivered due to business changes.
Under-engineering examples at each of the four levels
Real examples at ‘single-act’ level
At a ‘single-act’ capability level there is the potential for key elements to be under-engineered which significantly effect performance. It may be a single action, but it may not be a trivial action.
For example, KYC Periodic Refreshes need to be completed by a review date set by the organisation’s financial crime risk custodians. A failure to meet that date results in a risk assessment and the potential for risk mitigation restrictions on the client. Multiple cases result in a need to mitigate the risk across many customers.
The operating model element is a need to manage the execution of the KYC periodic review during the time period allowed to complete it. Under engineering of the capability for staff to track progress against a timeline results in a significant impact to business. It is just one operating model element but has a significant impact.
Real examples at ‘multi-act’ level
At a ‘multi-act’ capability level all the operating model elements of a single-act capability still exist plus all the elements which stitch together the single-act capabilities into the more complex capability.
A multi-act capability usually involves one or more processes so this is the realm of Process Reengineering.
Onboarding is a good example of where under-engineering can result in poor performance. There is a lot of scope for activities which could be performed in parallel to be performed in sequence, for many handoffs due to organisational specialization without the means to manage resultant queue delay and impact to turnaround time.
Real examples at ‘multi-capability’ level
At operational level an entire management science comes into the picture - operational science.
Operational science is largely about flow to ensure all requests are met on time. Achieving that objective can become very complex when a team handles multiple service requests, the demand rates is varied, there is high variety in the service requests, there are different time requirements for each of the services, and there are different priorities for the services requested.
The operational elements to achieve the required flow can be impacted by the capability designs in the layers below, and also by organisational changes in the highest of the four levels.
Real examples at organisational level
At organisational level another science comes into the picture - systems science.
Systems science is about how changes in the system the operating model is part of, and how changes in the environment that affect the system, impact the operating model. The system in question is the organisation.
Businesses are constantly evolving making changes which affect the operating model, and reacting to environmental changes such as customer changing expectations or new regulations. For longer term projects the original benefits can be used up or eroded by the time delivery occurs, which brings in an essential discipline in project management: benefits management.