Engineering Process Maturity: Assessment and Roadmap

Understand how to assess Engineering process maturity using criteria, evidence, levels, and a roadmap, without confusing documentation, automation, or PMO maturity.

Check it out!

Process maturity is an organization’s capability to execute, control, measure, and improve its processes consistently, reducing dependence on specific individuals and unnecessary variability. In Engineering, assessing maturity does not mean counting how many procedures exist: it means verifying whether processes actually produce predictable results, whether they have clear owners, entry and exit criteria, indicators, controls proportional to risk, and improvement mechanisms.

An organization may have hundreds of procedures and still operate immaturely if decisions depend on tacit knowledge, if different areas interpret the same flow differently, if rework is recurring, or if data do not explain why schedules and results vary. A maturity assessment should therefore examine evidence from the actual process and build an evolution roadmap consistent with criticality and business objectives.

What is process maturity?

Process maturity describes the degree of development of a process or process system in relation to its ability to deliver results in a stable, measurable, and improvable manner. The higher the maturity, the lower the dependence on improvisation and the greater the capability to learn from data, control risks, and sustain performance over time.

The ISO 9001 process approach treats processes as interrelated parts of a system and associates their control with the definition of inputs, outputs, responsibilities, resources, monitoring, measurement, and improvement. Maturity adds a management question: how consistently are these capabilities actually implemented and sustained?

In Engineering, this question can be applied to flows such as:

demand intake and qualification;
design development and review;
document management;
analysis and approval of supplier documents;
technical procurement;
change control;
RFIs and technical clarifications;
inspections, NCRs, and corrective actions;
measurement and acceptance;
commissioning and handover;
management of interfaces between disciplines and organizations.

Process maturity is not PMO maturity

The site already has dedicated content on maturity assessment in Project Management and PMO. The boundary between the two topics is important.

PMO maturity examines capabilities related to project management, portfolio management, governance, controls, methodology, reporting, resources, and benefits realization. Process maturity examines recurring flows, regardless of whether they occur within a specific project.

A document approval process may exist across dozens of projects. A supplier qualification flow may be repeated by different areas. An NCR handling routine may cross projects, contracts, and units. This is the type of cross-functional capability assessed in this article.

Question	Process maturity	PMO maturity
Primary object	recurring flow	capability to manage projects/portfolio
Unit of analysis	process and its interfaces	projects, programs, portfolio, and PMO
Typical indicators	lead time, FPY, rework, WIP, aging, SLA	SPI, CPI, forecast, governance, benefits
Central accountable role	process owner	sponsor, manager, PMO/EPMO
Expected result	process stability and improvement	project predictability and value

A documented process is not necessarily a mature process

Documentation is only one possible form of evidence. A process may be very well described yet poorly aligned with actual practice. The opposite can also occur: an experienced team may perform a routine well but depend excessively on key individuals and be unable to scale, transfer knowledge, or sustain performance when changes occur.

Signs of false maturity include:

an up-to-date procedure that is rarely used;
a flowchart that does not represent real exceptions;
controls performed outside the formal system;
approval that depends on parallel messages;
indicators produced only for reporting;
training without competency verification;
excessive standardization unrelated to risk;
a process that works only because an experienced person intervenes constantly.

The assessment must compare documentation, practice, data, and results.

Process maturity and process management maturity

APQC distinguishes the maturity of a specific process from process management maturity as an organizational capability. This distinction is particularly useful in Engineering.

An individual process may be mature because it has an owner, clear criteria, indicators, and an improvement routine. At the same time, the organization may have low process management maturity if other flows do not follow the same discipline, if there is no process architecture, or if each unit defines its own models without coordination.

The opposite can also occur. The company may have a corporate BPM policy, governance, and tools, while certain critical processes remain immature because of insufficient data, competencies, decisions, or supplier integration.

For this reason, the assessment should define in advance which object is being evaluated:

a specific process;
a group of related processes;
an end-to-end chain;
the corporate capability to manage processes.

Which dimensions should be assessed?

A useful maturity model should avoid a single score without explanation. The result should show which capabilities are strong or weak and which gaps actually affect process performance.

A structure applicable to Engineering can assess at least eight dimensions.

1. Purpose and boundaries

Does the process have a clearly defined expected result? Are its start and end recognized by the areas involved? Are the process inputs, outputs, and customers clear?

Immature processes often have ambiguous boundaries. One area considers its responsibility complete at issuance; another considers it complete at acceptance. The divergence later appears as delay, return, or conflict of responsibility.

2. Ownership and governance

Is there a process owner or equivalent role with a mandate to monitor performance and promote improvements?

The following should be assessed:

end-to-end accountability;
decision rights;
authority levels;
escalation criteria;
exception handling;
mechanisms for resolving conflicts between functions.

3. Standardization and method

Does execution follow minimally consistent criteria? Are there instructions, checklists, templates, or rules proportional to criticality?

Maturity does not require everything to be rigidly standardized. The objective is to reduce variation that does not add value while preserving room for technical judgment where necessary.

4. Competency and capacity

Do the people who perform or approve the process have adequate competency? Is available capacity compatible with demand?

A process may appear immature because of excessive queues when the primary constraint is actually capacity. It may also appear to lack capacity when much of the workload is rework caused by poor-quality inputs.

5. Data and traceability

Is it possible to reconstruct the history of an item, identify who made the decision, when each transition occurred, and which information supported the decision?

Without traceability, the assessment becomes dependent on perception. Mature processes preserve sufficient evidence to measure and learn.

6. Indicators and performance

Does the process have indicators linked to results and to the causes that explain variation?

The article on Engineering Process Indicators examines lead time, waiting time, WIP, aging, throughput, first pass yield, and rework in detail. In a maturity assessment, the key question is whether these metrics exist, whether they have stable definitions, and whether they drive decisions.

7. Interfaces and integration

Do handoffs between areas, disciplines, suppliers, and systems have clear criteria? Does the necessary information reach the next stage complete?

Process maturity cannot be assessed only within departmental boundaries. Many losses arise precisely in end-to-end processes.

8. Improvement and learning

Are recurring problems treated as isolated events, or do they feed structural improvement? Does the process have mechanisms to analyze causes, review standards, and verify the effectiveness of changes?

Maturity increases when improvement stops being an occasional reaction and becomes part of the management routine.

Maturity is not the number of procedures. The assessment needs to compare the defined process, actual practice, data, and results to identify where the organization still depends on improvisation and which capabilities need to evolve first.

Learn about Engineering Process Diagnosis and Optimization

A practical five-level model

Maturity models do not need to be universal. What matters is that each level has observable criteria. A five-level scale can be useful for structuring an assessment and roadmap.

Level	Dominant characteristic	Typical situation
1 — Reactive	execution depends on individuals	each case is handled differently
2 — Defined	a basic method exists	process is described, but adherence varies
3 — Controlled	responsibilities and controls function	process has an owner, criteria, and traceability
4 — Performance managed	decisions use indicators	flow is measured and causes of variation are investigated
5 — Adaptive and improved	continuous learning	improvements are prioritized by evidence and risk

The scale should not become a simplistic label. The same process may be level 4 in traceability and level 2 in governance. The value of the assessment lies precisely in this decomposition.

Level 1 — reactive process dependent on individuals

At the first level, the process exists because people do the work, but its rules are not explicit enough. Quality depends heavily on individual experience and personal relationships.

Common signs:

lack of clear boundaries;
case-by-case decisions;
information circulating by email or messages;
limited traceability;
rework treated as normal;
highly variable schedules;
difficulty replacing key individuals;
indicators that are nonexistent or based only on volume.

In Engineering, this situation appears when a technical review works because everyone knows “who usually solves it,” but the organization has no consistent criteria for submission, review, approval, and return.

Level 2 — defined but still unstable process

At this level, some formalization already exists. Procedures, flows, and responsible roles have been defined, but actual behavior still varies considerably.

Common findings include:

partial documentation;
different interpretations between areas;
manual controls;
indicators produced without a routine for analysis;
frequent exceptions;
deviations handled outside the process;
initial training without refreshers;
improvement driven mainly by complaints.

The main evolution at this level is to move the process off paper and make it executable in daily operations.

Level 3 — controlled and governed process

At the third level, the process already has sufficient structure to sustain performance with less dependence on individuals.

Expected evidence includes:

clear boundaries and result;
defined owner;
entry and exit criteria;
coherent authority levels;
traceable documents and data;
recorded exceptions;
basic indicators;
review routine;
integration with related processes.

This is an important point because many organizations try to automate before reaching this level. Digitalizing a level 1 or 2 process may simply turn disorganization into a workflow.

Level 4 — performance-managed process

At level 4, management stops asking only whether the procedure was followed and begins analyzing the behavior of the system.

The organization monitors trends in:

lead time;
waiting time;
WIP and aging;
throughput;
rework;
first-pass quality;
exceptions;
capacity;
supplier performance;
decision time.

When an indicator deteriorates, there is a routine for investigating causes and making decisions. Measurement is segmented by criticality and avoids comparing different objects as though they were equivalent.

Level 5 — adaptive, improvement-oriented process

The final level does not mean perfection. It means having the institutional capability to learn and evolve continuously.

The process is reviewed based on:

historical performance;
changes in demand;
emerging risks;
lessons learned;
feedback from internal and external customers;
technological evolution;
regulatory changes;
benchmarking when appropriate.

Improvement does not occur merely because someone “had a good idea.” There is governance to prioritize changes, test impact, standardize what worked, and prevent the organization from losing control during transformation.

How to assess maturity without falling into generic questionnaires

Questionnaires are useful for guiding interviews, but they should not be the only source. An assessment based exclusively on self-reporting tends to overestimate maturity because people describe how the process should work.

A robust assessment combines four types of evidence:

documents: procedures, flows, matrices, forms, policies, and instructions;
data: volumes, times, queues, returns, exceptions, indicators, and histories;
real cases: samples of completed, delayed, returned, and critical items;
interviews: perceptions of performers, managers, process customers, and interface functions.

Comparing this evidence reveals relevant gaps. If the procedure says a review should occur in three days, records show eight, and users report that incomplete documents enter the queue, the problem is not abstract “lack of adherence”; there is a concrete hypothesis involving input quality and capacity that needs investigation.

Evidence matters more than perception

Maturity should be supported by verifiable evidence. This avoids overly subjective assessments and allows the evaluation to be repeated in the future.

Examples of evidence:

Dimension	Possible evidence
Governance	owner, decision matrix, review minutes
Standardization	current procedure, checklist, acceptance criteria
Flow	entry and exit records, timestamps
Quality	returns, NCRs, FPY, input rejection
Capacity	demand, throughput, backlog, workload by function
Traceability	revision and approval history
Improvement	completed actions and effectiveness verification

The assessment should also record contradictory evidence. A process may show excellent aggregate SLA performance and, at the same time, high aging among critical items.

Not every process needs the maximum maturity level

Not every process needs to reach the highest level. The target level depends on risk, frequency, impact, variability, and traceability requirements.

A simple, low-risk, low-volume process may operate adequately with basic controls. A critical technical approval, change management, inspection, or commissioning release process may require much greater traceability and governance.

The mistake is turning maturity into a race to “level 5.” The objective is to establish the capability necessary to produce the result with acceptable risk.

How to define the target level

The target level can be defined based on five questions:

what is the impact of a process failure?
what is the variability of demand and complexity?
how many interfaces and organizations participate?
what traceability is required?
how predictable must performance be to support business decisions?

The greater the criticality and interdependence, the greater the likely need for governance, data, and controls.

Maturity and bottlenecks

Low maturity often manifests through bottlenecks, but the concepts are not the same. A process may have a capacity bottleneck even when it is mature. It may also show no apparent queue and still be immature because rework and exceptions are hidden.

The article on Bottlenecks in Engineering Processes examines queues, capacity, WIP, batches, and approvals in greater depth. In a maturity assessment, these symptoms help identify which capabilities still need to evolve.

Maturity and process architecture

A company can improve isolated processes and still have low systemic maturity. This happens when there is no value-chain view, when macroprocesses overlap, or when important interfaces have no owner.

Engineering Process Architecture helps define where each process fits and which relationships need to be considered in the assessment.

Corporate maturity increases when local improvements are consistent with this architecture.

Maturity and standardization

Standardization is an important capability, but it should not be confused with overall maturity. Rigid procedures can coexist with low capability to measure, govern, or improve.

The next stage of the cluster examines precisely how to standardize Engineering processes without creating bureaucracy. In a maturity assessment, the correct question is not “does a procedure exist?” but “does the standard help produce consistent results and is it adjusted when conditions change?”

Maturity and automation

Automation often appears as a symbol of modernity, but technology alone does not define maturity. A sophisticated workflow can execute poor rules with great efficiency.

Before automating, the process should have at least:

a clear objective;
defined boundaries;
entry criteria;
responsibilities;
authority levels;
exception handling;
minimum data;
relevant indicators.

The Process Management, Workflows, and Technical Approvals solution makes more sense when technology materializes a process that is already understood.

Automating an immature process may simply make the problem faster and less visible. Ownership, criteria, authority levels, exceptions, and indicators should be minimally stabilized before transforming the flow into a workflow.

See how to structure workflows and technical approvals

How to build a maturity roadmap

An assessment creates value only when it becomes a set of prioritized decisions. A long list of gaps without sequencing creates another management problem.

A roadmap can be structured in six steps.

1. Link each gap to its impact

Each gap should be linked to an observable effect: delay, rework, risk, information loss, cost, low predictability, or dependence on a key individual.

2. Identify enabling capabilities

Some improvements unlock several others. Defining ownership may come before creating dashboards. Improving input quality may come before increasing capacity. Stabilizing criteria may come before automation.

3. Separate quick wins from structural changes

Quick wins are useful for demonstrating results, but they should not replace necessary reforms in governance, data, or architecture.

4. Define the target state

The roadmap needs to state which capability is expected to be achieved and how it will be recognized through evidence.

5. Link indicators

Each initiative should have a result measure. If the action seeks to reduce returns, monitor FPY or rejection rate. If it seeks to reduce waiting, monitor lead time and aging.

6. Reassess periodically

Maturity is not a permanent certification. Changes in demand, people, systems, and organization can degrade capabilities that were previously stable.

Example roadmap for a technical approval process

Consider a flow with high aging, frequent returns, and concentrated decisions.

Horizon	Initiative	Expected evidence
short term	define minimum submission criteria	reduction in input rejection
short term	separate authority levels by criticality	reduction in decision time
medium term	formalize owner and review routine	recorded and recurring decisions
medium term	measure lead time, aging, and FPY	reliable baseline
medium term	redesign handoffs	fewer returns between areas
long term	automate stable workflow	traceability and automatic escalation

This type of sequence avoids starting with the tool and attacking symptoms before causes.

How to measure maturity evolution

Progress should not be measured only by the number of completed actions. The objective is to observe whether capabilities and results have improved.

Possible indicators include:

percentage of items with complete input data;
adherence to decision criteria;
reduction of manual exceptions;
reduction in aging;
increase in FPY;
stabilization of lead time;
reduction in dependence on key individuals;
percentage of improvements with verified effectiveness;
quality of traceability;
satisfaction of process customers.

A roadmap may be 100% complete and the process may still perform poorly. Effectiveness verification is indispensable.

Common mistakes in maturity assessments

Assigning a score without explaining the evidence

A “3 out of 5” score without clear criteria rarely guides decisions.

Copying a model without adapting it to context

Models are references, not substitutes for organizational analysis.

Assessing managers only

Performers and process customers often see different problems.

Confusing a tool with a capability

Having BPMN, workflow, or a dashboard does not demonstrate that the process is governed.

Rewarding excessive documentation

More documents can increase bureaucracy without improving results.

Ignoring interfaces

Local maturity can hide severe problems between areas.

Creating an impossible roadmap

Hundreds of simultaneous actions dilute resources and reduce accountability.

When is it worth engaging a process maturity assessment?

Engagement makes sense when the organization sees recurring symptoms but cannot determine whether the main cause lies in method, governance, capacity, interfaces, data, or standardization.

It is also useful before larger transformation initiatives, such as BPM implementation, workflow review, digitalization, integration between areas, governance structuring, or continuous improvement programs.

A consulting assessment should deliver more than a score. Expected outputs include:

scope and architecture of the processes assessed;
maturity criteria;
evidence collected;
gaps and strengths by dimension;
associated risks;
current level and target level;
priorities;
quick wins;
evolution roadmap;
indicators for verifying effectiveness.

The Engineering Process Diagnosis and Optimization service was structured to connect this analysis to actual process improvement, avoiding assessments that end only in an executive presentation.

A maturity roadmap needs to link each gap to impact, evidence, an accountable person, and an effectiveness indicator. Without this connection, the assessment becomes only a snapshot of the organization rather than an instrument for transformation.

Structure a consulting process assessment

Final considerations

Engineering process maturity is not the number of procedures, the level of automation, or a score obtained from a questionnaire. It is the actual capability to transform inputs into results in a consistent, governed, measurable, and adaptable manner.

The assessment needs to combine documentary evidence, data, real samples, and the perceptions of those involved. A dimension-based analysis makes it possible to distinguish problems involving ownership, standardization, capacity, input quality, traceability, indicators, and interfaces.

The roadmap should prioritize enabling capabilities and measure effectiveness, not merely task completion. In this way, maturity stops being an abstract exercise and becomes an instrument for reducing risk, rework, and variability in Engineering processes.

Technical references

[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (ISO). The process approach in ISO 9001:2015. Geneva: ISO, 2015. Available at: https://www.iso.org/files/live/sites/isoorg/files/archive/pdf/en/iso9001_2015_process_approach.pdf

[2] APQC. Business Process Management Maturity Benchmarks. Houston: APQC, 2025. Available at: https://www.apqc.org/resource-library/resource-collection/business-process-management-maturity-benchmarks

[3] APQC. What's the Difference Between Process Maturity and Process Management Maturity? Houston: APQC, 2024. Available at: https://www.apqc.org/resource-library/resource-listing/whats-difference-between-process-maturity-and-process-management

[4] APQC. APQC's Process Maturity Model. Houston: APQC, 2024. Available at: https://www.apqc.org/resource-library/resource-listing/apqcs-process-maturity-model

Frequently asked questions

What is process maturity?

It is the degree of development of a process in relation to its ability to produce results consistently, under governance, measurably, and with the capacity for improvement, with less dependence on improvisation and specific individuals.

Is process maturity the same as PMO maturity?

No. Process maturity assesses recurring flows and their interfaces; PMO maturity assesses project management, portfolio, governance, controls, and project office service capabilities.

Does having documented processes mean high maturity?

No. Documentation is one possible form of evidence. A process can be well documented and still have low adherence, limited traceability, high rework, or informal decisions.

Which dimensions should be assessed in a maturity assessment?

Among the most useful dimensions are purpose and boundaries, ownership, standardization, competency and capacity, data and traceability, indicators, interfaces, and continuous improvement.

Do all processes need to reach the maximum maturity level?

No. The target level depends on risk, criticality, frequency, complexity, traceability requirements, and the impact of failures. The objective is to achieve the necessary capability, not pursue the highest score.

When should a process maturity assessment be engaged?

When recurring problems cross organizational areas, when the organization cannot distinguish causes involving method, governance, capacity, or data, or before significant BPM, digitalization, workflow, and continuous improvement initiatives.

Complementary technical materials