MASP in Engineering: Problem Analysis and Solution Method for Quality

Understand MASP in Engineering, its 8 stages, relationship with PDCA, applicable tools, and how to verify effectiveness and standardize quality solutions.

Check it out!

MASP — Problem Analysis and Solution Method is a structured approach to identify a problem, understand its causes, define actions, execute them, verify effectiveness, standardize the result, and record lessons learned. In Engineering, it is useful when a failure, nonconformity, process deviation, or performance problem requires more discipline than an immediate corrective action, but not necessarily a complex statistical project such as DMAIC.

The method is strongly associated with the PDCA cycle and organizes problem solving into logical stages. The main benefit is not “filling out a MASP form,” but preventing the team from jumping directly from a symptom to a solution without evidence.

What Is MASP?

MASP stands for Problem Analysis and Solution Method. In Brazilian quality-management literature, the method is presented as a structured sequence based on PDCA, with stages for identification, observation, analysis, action planning, execution, verification, standardization, and conclusion.

In practice, MASP works as an investigation and improvement roadmap. It connects tools such as Pareto, check sheets, Ishikawa, 5 Whys, scatter diagrams, and 5W2H within a single logic.

This matters because isolated tools do not solve problems. An Ishikawa diagram can organize hypotheses. A Pareto chart can show where to concentrate effort. A 5W2H can organize actions. MASP defines when and why each resource enters the problem-solving process.

MASP Is Not Synonymous With a Single Tool

Another common mistake is to call MASP a “quality tool” as if it were equivalent to a histogram or Pareto chart. Technically, it is better understood as a problem-solving method within which specific tools can be applied.

This distinction changes the quality of the work. When MASP is treated only as a form, the team tends to fill in fields retrospectively to justify a solution that has already been chosen. When it is treated as a method, each stage must produce evidence for the next one.

What MASP Is Used for in Engineering

MASP is particularly useful for problems that present one or more of the following characteristics:

• recurrence;
• significant impact on quality, schedule, cost, or safety;
• non-obvious cause;
• multiple areas or disciplines involved;
• a history of corrective actions that failed to eliminate the problem;
• a need for traceability of the investigation;
• a need to verify whether the solution actually worked;
• potential to standardize the learning for other teams or projects.

It can be applied to design, construction, inspections, manufacturing, procurement, commissioning, maintenance, technical documentation, and Engineering administrative processes.

Typical examples include recurring nonconformities, systematic approval delays, document rework, repeated equipment failures, interface discrepancies, manufacturing defects, poor field-data quality, and recurring punch-list items.

Relationship Between MASP and PDCA

PDCA is a general improvement cycle. MASP details this cycle for disciplined problem solving.

A practical correspondence can be viewed as follows:

MASP	PDCA	Objective
Identification	Plan	clearly define the problem
Observation	Plan	understand conditions and patterns
Analysis	Plan	identify relevant causes
Action plan	Plan	define countermeasures
Execution	Do	implement actions
Verification	Check	assess effectiveness
Standardization	Act	incorporate the new method
Conclusion	Act	record results and lessons learned

The critical point is that most of the reasoning happens before execution. If the team jumps quickly to “Do,” it tends to treat symptoms.

Stage 1 — Problem Identification

The first task is to define the problem objectively. Expressions such as “the construction site is disorganized,” “the supplier is bad,” or “the process is slow” are perceptions, not operational definitions.

A good definition should clarify:

• what is happening;
• where it occurs;
• since when;
• how often;
• which requirement, target, or expected condition is not being met;
• what impact is being observed;
• what the investigation boundary is.

For example, instead of “there is too much design rework,” a better definition would be: “28% of the electrical documents issued in the last quarter were returned for a second revision because of inconsistencies among load lists, diagrams, and calculation reports.”

The second formulation defines the population, period, discipline, and type of deviation.

Quantify Before Explaining

At the identification stage, the team should not yet be debating the cause in depth. First, it is necessary to prove that a relevant problem exists and measure its magnitude.

A Pareto Chart can help when there are several categories of deviations. A Check Sheet is useful for structuring data collection before analysis.

Stage 2 — Problem Observation

After defining the problem, it is necessary to understand how it manifests itself.

This stage answers questions such as:

• does the problem occur all the time or only under certain conditions?
• is there concentration by supplier, discipline, team, equipment, or location?
• is there an associated time, phase, version, or operating condition?
• has the problem increased recently?
• are there differences among projects, contracts, or facilities?

Observation prevents the team from investigating an aggregated problem that actually contains distinct populations.

Stratification as an Analysis Discipline

If 100 nonconformities are mixed into a single dataset, the cause may appear diffuse. When they are separated by source, type, phase, or technical responsibility, patterns may emerge.

For example, a company may discover that 70% of document returns occur only in multidisciplinary packages issued before final coordination. In that case, the nature of the problem changes: it is no longer simply “poor document quality” and instead involves issue maturity and interface governance.

Stage 3 — Cause Analysis

This is the most sensitive stage. The objective is not to list possible causes, but to arrive at causes supported by sufficient evidence to justify action.

Useful tools include:

• Ishikawa Diagram;
• 5 Whys;
• Scatter Diagram;
• document analysis;
• structured interviews;
• field inspection;
• trend analysis;
• comparison between failure and non-failure conditions.

Ishikawa organizes hypotheses. The 5 Whys deepen causal chains. A scatter diagram can test quantitative relationships. None of these tools, by itself, guarantees that a cause has been demonstrated.

Apparent Cause vs. Controllable Cause

Many investigations stop at descriptions such as “lack of attention,” “human error,” “supplier failure,” or “poor communication.” These formulations are not very actionable.

A more useful analysis looks for system conditions:

• ambiguous requirement;
• missing acceptance criterion;
• poorly defined responsibility;
• unvalidated input data;
• approval without minimum evidence;
• a workflow that allows premature issue;
• an instrument without valid calibration;
• an interface without a defined owner;
• a procedure that does not match actual practice.

Root Cause Analysis — RCA deepens this reasoning for failures with greater criticality or complexity.

Stage 4 — Action Plan

After the relevant causes have been supported, the team defines countermeasures.

A quality action should be linked to a specific cause. If the cause is “incomplete entry criteria,” a coherent action may be to create a release gate with minimum evidence. If the cause is “inadequate instrument,” the action may involve replacement, calibration, or a change in method.

5W2H helps turn a countermeasure into an executable plan, but MASP requires something more: the action must have causal logic.

Criteria for a Good Action

A robust action should answer:

• which cause it intends to eliminate or control;
• who is responsible;
• when it will be implemented;
• which resources are required;
• what risk of side effects exists;
• how implementation will be verified;
• which indicator will demonstrate effectiveness.

The action does not end when the task is marked complete.

Stage 5 — Execution

Execution appears simple, but it fails when the plan has not been detailed or when multiple actions depend on different areas.

At this stage, it is important to control:

• responsible parties;
• deadlines;
• completion evidence;
• scope changes;
• dependencies;
• communication;
• training;
• document updates.

If an action changes a procedure but the team continues using the old version, implementation has not actually been completed.

Controlled Implementation

When risk is high, it may be prudent to test the solution on a limited scale before standardizing it. This reduces the chance of introducing an improvement that solves one problem and creates another.

Stage 6 — Effectiveness Verification

This stage distinguishes an executed action from a solved problem.

The question is: did the undesirable behavior actually change?

Verification should use metrics compatible with the original problem. If the problem was rework rate, verify rework rate. If it was defect recurrence, measure recurrence. If it was lead time, compare lead time before and after.

Tools such as a Control Chart, Histogram, and process indicators can show whether a consistent change occurred.

Three Possible Outcomes

Verification can lead to three scenarios:

1. effective — the expected result was achieved and is sustained;
2. partially effective — improvement occurred, but the problem persists;
3. ineffective — no change compatible with the causal hypothesis occurred.

In the last two cases, the method should return to analysis. The MASP should not be “closed” merely because the actions were executed.

Stage 7 — Standardization

When the solution demonstrates effectiveness, the new method must be incorporated into the working system.

This may involve:

• procedures;
• review criteria;
• checklists;
• templates;
• specifications;
• training;
• digital systems;
• responsibilities;
• indicators;
• audit criteria.

Engineering Process Standardization is important to prevent improvement from depending only on the people involved in the initial project.

Standardize Without Creating Bureaucracy

Standardization does not mean producing lengthy documents for every improvement. The level of formalization should be proportional to risk, recurrence, and the need for repeatability.

A system validation rule may be more effective than a ten-page procedure that nobody consults.

Stage 8 — Conclusion and Learning

The final stage consolidates what was learned.

A robust conclusion records:

• the original problem;
• confirmed causes;
• implemented actions;
• measured results;
• gains achieved;
• unforeseen effects;
• remaining open items;
• opportunities for replication;
• lessons for other processes.

This record turns a local solution into organizational knowledge.

Example of MASP Applied to Engineering Documentation

Consider a company with a high rejection rate for documents on first issue.

Identification

35% of the documents in a given discipline are returned because of inconsistencies among related documents.

Observation

Stratification shows that 80% of occurrences are concentrated in documents issued before interfaces with automation and electrical disciplines are consolidated.

Analysis

Ishikawa and sample analysis show that the workflow allows formal issue before interface closure and does not require evidence of coordination.

Action Plan

Create a technical gate with an interface checklist, defined responsibility, and coordination evidence before issue.

Execution

Implement the gate in two pilot projects and train coordinators.

Verification

After two cycles, the return rate falls from 35% to 12% and remains stable.

Standardization

The gate becomes part of the corporate workflow and issue checklist.

Conclusion

The solution is replicated in other disciplines with adjusted criteria.

The example shows why the method is more valuable than simply opening an action to “review documents more carefully.”

MASP vs. PDCA

PDCA is broader and can be applied to any improvement cycle. MASP structures a specific application of PDCA for problem solving.

Criterion	PDCA	MASP
Nature	improvement cycle	problem-solving method
Level of detail	broad	detailed
Focus on cause	depends on application	explicit
Quality tools	optional	normally integrated
Effectiveness verification	Check	specific stage
Standardization	Act	specific stage

MASP and PDCA do not compete. MASP operationalizes PDCA for problems that require disciplined investigation.

MASP vs. DMAIC

DMAIC also structures problem solving, but it has a different origin and emphasis.

Criterion	MASP	DMAIC
Structure	8 traditional stages	Define, Measure, Analyze, Improve, Control
Foundation	PDCA and quality management	Six Sigma
Statistical emphasis	variable	usually greater
Typical complexity	low to high	medium to high
Application	quality and general improvement	data- and variation-driven problems

For a problem with a large volume of data and a need for modeling and advanced statistical analysis, DMAIC may provide a more suitable structure. For many Engineering problems, MASP is sufficient and simpler to operationalize.

MASP vs. RCA

RCA focuses on identifying the causes of a failure or event. MASP covers a broader cycle: problem, cause, action, implementation, effectiveness, and standardization.

An RCA can be used within the MASP analysis stage when criticality requires a deeper causal investigation.

MASP vs. A3 Thinking

A3 Thinking organizes problem-solving reasoning in a concise and visual way. It can document part or all of an investigation journey.

MASP is more prescriptive in its stages. A3 emphasizes reasoning, communication, and alignment. In many organizations, both approaches can coexist.

Which Tools to Use at Each MASP Stage

Stage	Possible tools
Identification	check sheet, Pareto, indicators
Observation	stratification, histogram, flowchart
Analysis	Ishikawa, 5 Whys, scatter diagram, RCA
Plan	5W2H, prioritization matrix
Execution	action plan, visual management
Verification	control chart, indicators, histogram
Standardization	procedure, checklist, workflow
Conclusion	lessons learned, A3 report

Selection depends on the question. It is not necessary to use every tool in every MASP.

Common Errors When Applying MASP

Choosing the Solution Before the Analysis

When the solution is decided at the beginning, the stages become retrospective justification.

Confusing Cause With Blame

The method should explain system conditions, not merely identify a person or supplier.

Using Data Without Criteria

Large spreadsheets do not necessarily mean good evidence. Definitions, sampling, and traceability matter.

Creating Many Actions Without Causal Linkage

An extensive plan may create a sense of control, but actions unrelated to the cause do not increase effectiveness.

Closing After Execution

The verification stage is essential. A completed action is not synonymous with an eliminated problem.

Failing to Standardize

Without incorporation into the process, the organization risks relearning the same lesson in another project.

When Not to Use MASP

The method may be excessive for isolated occurrences with an obvious cause, low risk, and a direct solution.

It may also be insufficient when there are:

• serious accidents;
• critical safety failures;
• complex systems with multiple mechanisms;
• a need for probabilistic analysis;
• forensic investigation;
• specific regulatory requirements.

In such cases, specialized methods such as formal RCA, FTA, FMEA/FMECA, or incident investigation may be more appropriate.

How to Integrate MASP Into Engineering Governance

The method becomes stronger when it does not depend solely on individual initiative.

Minimum governance can define:

• criteria for opening a MASP;
• the person responsible for the investigation;
• mandatory participants;
• minimum evidence by stage;
• approval authorities for the plan;
• closure criteria;
• the deadline for effectiveness verification;
• how lessons learned will be recorded.

This prevents relevant problems from being handled only through messages, meetings, and disconnected actions.

Final Considerations

MASP is useful because it requires the organization to follow a logical sequence: define the problem, observe how it occurs, demonstrate causes, plan countermeasures, execute, measure effectiveness, standardize, and learn.

In Engineering, this discipline reduces the risk of correcting symptoms and improves decision traceability. The method can be simple or deep according to the criticality of the problem, but the logic remains the same: evidence before action and effectiveness before closure.

Technical references

[1] BRAZIL. Ministry of Education. Quality and Productivity: Lesson 12 — Problem Analysis and Solution Method — MASP. Brasília: MEC. Available at: https://redeetec.mec.gov.br/images/stories/pdf/proeja/qualidade_produt.pdf

[2] AMERICAN SOCIETY FOR QUALITY. PDCA Cycle — What is the Plan-Do-Check-Act Cycle? Milwaukee: ASQ. Available at: https://asq.org/quality-resources/pdca-cycle

[3] AMERICAN SOCIETY FOR QUALITY. What is Problem Solving? Steps, Process & Techniques. Milwaukee: ASQ. Available at: https://asq.org/quality-resources/problem-solving

[4] AMERICAN SOCIETY FOR QUALITY. Quality Tools & Templates. Milwaukee: ASQ. Available at: https://asq.org/quality-resources/quality-tools

Frequently asked questions

What is MASP in quality management?

MASP is the Problem Analysis and Solution Method, a structured approach to identify, observe, and analyze a problem, define actions, execute them, verify effectiveness, standardize, and record lessons learned.

What are the stages of MASP?

The traditionally presented stages are identification, observation, analysis, action planning, execution, verification, standardization, and conclusion.

What is the relationship between MASP and PDCA?

MASP is a structured application of PDCA logic to problem solving. The first stages concentrate planning, execution corresponds to Do, verification to Check, and standardization/conclusion to Act.

Are MASP and DMAIC the same thing?

No. Both structure improvement, but MASP is associated with the quality-management tradition and PDCA, while DMAIC originated in Six Sigma and typically places greater emphasis on measurement and statistical analysis.

When should MASP be used in Engineering?

When there is a recurring or relevant problem, a non-obvious cause, a need for structured investigation, multiple areas involved, or a need to verify effectiveness and standardize the solution.

Complementary technical materials

Related solutions

• Management of Open Items, RFIs, and Nonconformities
• Process, Workflow, and Technical Approval Management

Related services

• Engineering Process Diagnosis and Optimization
• Technical Consulting

Main content on the topic

• Quality Tools in Engineering
• PDCA: What It Is, Stages, and How to Apply It
• DMAIC in Engineering

Related technical content

• Root Cause Analysis — RCA
• 5 Whys in Engineering
• A3 Thinking in Engineering