Keeping Quality on Course: Protecting the Baseline with PRINCE2 Agile

Professor Sagar Zilpe, Founder of WorKnoW, Director of Technology at WinFully and Global Ambassador for DevOps, ITIL and PRINCE2

Prof. Sagar Zilpe has extensive experience in product management, strategic innovation, and digital transformation programmes. He is well-versed in Agile, ITSM, Lean/Lean Six Sigma and the PRINCE2 Agile method.

In this article, he explores why the project baseline is more than a static document; it represents a shared commitment among stakeholders concerning quality, scope and value. Drawing on his hands-on experience in AI-driven automation, compliance-sensitive workflows and agile environments, he explains how disciplined issue and change control enables teams to balance flexibility and control while ensuring quality and building stakeholder trust.

In many modern delivery environments, the baseline is often viewed as a one-off artifact created at the start of a project. This, however, misses the point. The baseline is best understood as a common reference guide – a “shared promise” that aligns all stakeholders. This baseline not only outlines scope, cost and time, but also the quality standards that give meaning to those commitments.

As technology, customer needs and regulatory conditions change, this shared promise becomes even more important. In AI-driven automation, for example, accuracy tends to mature over time rather than being achieved at first deployment. Teams may set thresholds for optical character recognition (OCR), document extraction, or transcription accuracy, but the agreed baseline determines when the solution is considered “good enough” to proceed. When everyone understands that baseline, discussions about trade-offs have a clear direction rather than relying on individual opinions.

Differentiating detail changes from baseline changes

A recurring challenge in project management is determining what qualifies as a minor adjustment and what constitutes a change to the baseline. Treating every variation as a formal change request can slow down progress and increase frustration. Conversely, viewing everything as a minor refinement can lead to scope creep and compromise the quality of the work.

PRINCE2 Agile addresses this by establishing clear tolerances. Changes that fall within those agreed tolerances, such as clarifying requirements, refining user interface elements or reordering tasks, can be handled at the detail level without formal approval. These day-to-day adjustments are expected and help maintain workflow.

However, if a proposed change challenges the baseline, such as altering the business case, affecting customer commitments or changing agreed-upon quality levels, it should be regarded as a baseline change. This triggers a structured review of value, effort and impact. By making this distinction, teams can remain flexible regarding minor details while maintaining control over the original product definition established at the beginning of the project.

Where agile teams struggle with issue and change control

Many agile teams operate in “let’s accept everything” mode. Issues and changes are discussed during daily stand-ups or informal conversations and then added directly to the backlog. The team feels aligned because everyone “knows” what is happening. The subtle risk is that, although the changes are discussed, they are not properly assessed.

From a PRINCE2 Agile perspective, this is where lightweight artifacts make a difference. Issue and risk registers, even in simple form, help teams distinguish between ideas that were merely talked about and those evaluated for impact. Agile encourages collaboration while PRINCE2 Agile adds the discipline of capturing key decisions so they can be revisited, tracked and learned from without adding unnecessary bureaucracy.

Handling issues in traditional and agile contexts

In a traditional project environment, issues follow a clear lifecycle from identification through assessment, escalation, decision and implementation or closure. Documentation supports each step, helping teams understand the reasons behind decisions and what they aim to achieve.

Agile environments often condense this lifecycle into a single sprint. Issues can be quickly identified, fixed and deployed, providing significant benefits. However, this speed only works if information is shared effectively and critical decisions remain visible. Without proper logging and assessment, the same problem can recur in later sprints or lead to unexpected side effects. The most effective teams therefore combine agile responsiveness with PRINCE2’s emphasis on traceability.

The most effective teams therefore combine agile responsiveness with PRINCE2’s emphasis on traceability - ensuring that speed is supported by clarity rather than achieved at its expense.

Using practical decision filters to protect quality

The difference between routine adjustments and baseline changes becomes much clearer when teams apply a small set of practical decision-making filters. Instead of escalating every adjustment, teams can pause to consider whether a proposed change affects the agreed-upon acceptance criteria or impacts the product's quality. They should then determine whether the change remains within the defined tolerances or if it exceeds the limits originally agreed with stakeholders.

Value and risk also play crucial roles in this decision-making process. A change may be worth pursuing if the benefits clearly outweigh the effort and associated risk. However, this decision must not be made in isolation from broader obligations. When a change impacts compliance requirements, legal constraints or user expectations, it carries implications beyond the team and should be assessed explicitly.

When these conditions are met, the change warrants a structured assessment rather than being treated as a routine tweak. By applying this approach consistently, teams can remain responsive and agile in their day-to-day work while ensuring that product integrity, quality commitments and stakeholder trust are upheld over time.

Treating quality issues as risk triggers

Quality issues should not be viewed as isolated defects. When a problem threatens established quality standards, it should be recognized as a risk trigger that may indicate wider weaknesses in the design, process or controls.

In regulated environments, such as healthcare or finance, minor deviations might seem acceptable, but they can also highlight greater risks to patient data or compliance. Instead of quickly addressing each issue as it arises, teams should consider what these problems reveal about their frameworks, blueprints and quality controls.

PRINCE2 Agile offers specific tools to help with this. The Agilometer aids teams in assessing how much flexibility an organization can safely tolerate, while tools such as quality canvas keep acceptance conditions visible as teams experiment with MVPs and new features. Together, these tools ensure that the principle of “fail fast, learn fast” is implemented within a controlled quality environment.

Learning from early escalation and missed signals

Real projects I have observed highlight these principles: in an AI solution designed to track carbon emissions, the team identified, escalated and logged early inconsistencies in formulas. Business analysts evaluated the impact on credibility and the team prioritised a fix during the early sprints. By treating this issue as a quality risk, the roadmap remained clear and this preserved trust in the product.

In a financial operations transformation, a rule change requested verbally and implemented informally resulted in discrepancies during user acceptance testing. The client compared dashboards against their own spreadsheets and discovered multiple mismatches. The conclusion was clear: if it is not logged, it does not exist. Since then, the teams have adopted practices that combine psychological safety with simple tools, such as AI-assisted meeting summaries, to ensure that all changes are captured and understood.

A practical first step for teams

For teams wanting to improve quickly, the most effective first step is to establish clear tolerances and make escalation rules visible to everyone. When team members understand what they can decide, when to involve leadership and what quality criteria must never be compromised, their confidence and clarity increase significantly.

Clear tolerances provide teams with space to experiment and adapt while indicating when a change has crossed into baseline territory and needs formal control. This approach transforms the baseline from a static document into a living guide that maintains quality, value and trust throughout the project’s lifespan.

In fast-moving environments, organizations are often challenged to balance flexibility with control. PRINCE2 Agile demonstrates that this is not a trade-off, but a capability.

By combining disciplined issue and change control with agile ways of working, teams can respond to change while preserving the integrity of the baseline.

In doing so, the baseline remains what it was always intended to be: a shared commitment that safeguards quality, enables informed decision-making and sustains stakeholder trust over time.