Setting the Stage with a Quality Perspective

Before proposing meaningful improvements related to quality engineering within an organisation, it is essential to clearly understand where things currently stand. This first step is about defining what quality means in your organisation, identifying key goals and constraints, and establishing a baseline for improvement. Without this foundation, any transformation efforts risk being misaligned with business needs and stakeholder expectations.

This is a really long and drawn-out way of saying that context is key and we should be making context-informed decisions.

Understanding the Organisation’s Definition of Quality

Quality is often seen through different lenses depending on the team, product, or business objective. For some, it is about functional correctness, while for others, it might be reliability, security, or customer satisfaction. The first step in this framework is to uncover how quality is currently defined and whether there is alignment across the organisation.

A few key questions to consider:

• Is there a shared understanding of what quality means across teams?
• How do different stakeholders measure success when it comes to quality?
• Are there existing quality goals, KPIs, or standards in place?

By answering these questions, you begin to form an initial picture of the current quality landscape.

Establishing a Baseline

Once you understand the existing perceptions of quality, the next step is to gather data and documentation that illustrate the current state. This might include:

• Customer journey maps to assess how quality impacts user experience
• Test plans, defect logs, and production incident reports
• Customer feedback and satisfaction surveys
• Competitor analysis and industry benchmarks

This information helps identify gaps, pain points, and areas of strength. It also provides a foundation for measuring improvement over time.

Identifying Initial Assumptions and Risks

At this stage, it is useful to document early hypotheses about the organisation’s quality culture, strategy, and risks. These assumptions will need to be validated with stakeholders, but forming an initial viewpoint allows for more structured discussions.

Examples of common assumptions include:

• Teams feel ownership of quality, or it is perceived as a separate function
• There is an over-reliance on manual testing or legacy tools
• Quality bottlenecks exist in specific areas, such as deployment or requirements gathering

These assumptions should not be treated as definitive but as working theories to test and refine through stakeholder engagement.

NB – if you find yourself asking where RiskStorming is in this framework, don’t worry that will come later.

Outputs of This Step

By the end of this stage, you should have:

• A Quality Context Overview summarising how quality is currently perceived and defined
• A repository of Baseline Quality Artefacts to reference throughout the transformation process
• An Initial Assumptions List highlighting key areas for further validation and discussion

Why This Matters

Setting the stage with a quality perspective ensures that later improvements are built on solid foundations. Understanding the current landscape prevents wasted effort on misaligned initiatives and enables a more strategic, targeted approach to enhancing quality within an organisation.

With this groundwork in place, the next step is to engage stakeholders and gather deeper insights into their goals, challenges, and expectations regarding quality. That will be the focus of the next article in this series.