Better Projects Start with Better Decisions

How digital twins and AI strengthen decision quality in PRINCE2 environments


PRINCE2 Is About Decisions, Not Delivery

The world of PRINCE2 champions structured, informed decision-making, encouraging us to create and maintain a solid business case, shaping and refining it as the project progresses to ensure we are still delivering value at the right price with the right level of risk for our organization.

But, sometimes even with an Agile mindset we make decisions and define products based upon incomplete or even delayed information. Static information that should be dynamic puts our project at risk of not meeting its goals.

The question is whether we could improve those decisions and product definitions with non-human help. Could AI capabilities such as creation, curation, clarification and cognition (from the ITIL 6C model) improve decision quality and overall project outcomes?

The Limitations of Traditional Project Information

Though some projects will have perfect requirements defined and ready to go at the outset, that isn’t always the case in our VUCA worlds. We have many tools and techniques up our sleeves to help elicit and refine those requirements through workshops, and we make a good amount of usually safe assumptions in support of the goals of our projects as well.

We’re getting good at being reflective too, foreseeing the risks to and within our projects both as we set off and throughout delivery. We learn as we go, iterating our project approaches and evolving the teams supporting our goals. Information is also captured in logs, issue templates and stage documentation.

But do we really look back? Do we fully reflect? Do we truly learn all the lessons we should? Much of our work is still fragmented. Much of it is static when it should be evolving. As a result, we live in a hindsight world.

What if something were here to help, to be that critical friend whispering in our ear?

The Digital Twin: A Live Representation of our Context

This is where our Digital Twin, steps in to help, and it is designed to do so for both BAU and project or transformation activities. Be that a single feature request being added to a backlog, or at the outset of a whole new solution being created.

“A digital twin is a digital representation of a real-world entity, environment or process that allows the inclusion of a two-way communication flow into and out of the real world in a timeframe appropriate for decision-making.”

(UK Government 2025)

Our Digital Twin has access to a wealth of information that helps it identify what we might otherwise miss, challenge our assumptions and enhance our own thinking. We’ve given it access to our entire Service Catalogue, and the dependencies between services. To help refine requirements it can see our entire backlog (past and present) for every single system that we build or support. It can also peer into past incidents and performance data as well as user feedback.

Some of the greatest power comes from it understanding our users and their behaviours via its access to our Personas and Customer Journeys.

All of this is crowned by the tool having access to our governance artefacts (reviews, decisions, minutes) from past projects, service reviews and BAU ceremonies.

With live access to this wealth of information, we can rely on it to make evidence-based suggestions and support better decisions. It is more than a model or a report; it provides a live view of the reality of the organization and our needs.

AI Turns the Twin into a Decision System

Without AI interpreting and connecting the dots across all of the data within the twin we would be missing out!

Our twin is knowledgeable and able to help with a wide range of tasks such as refining user stories and suggesting non-functional requirements. It has also been a key tool in identifying risks based on patterns and surfacing past decisions and outcomes.

This has enabled a step-shift, with information that already exists that we may never have looked at being turned into insight, recommendations and actionable improvements.

How This Changes a Real Project Decision

In one of our own service improvement discussions, we were shaping a change to a student-facing digital journey. In a traditional setting, that would usually begin with a workshop, a few stakeholder views, and a draft set of user stories based on what people believed the problem to be.

That approach still has value and it’s how we started, but in this case, it would only have told part of the story. Once we ran the change through the Digital Twin, it pulled in a much wider view. It linked the proposed work to earlier backlog items, related incidents, service dependencies, and feedback that showed where users had already experienced friction.

We began with a simple request: sample user stories for a Student Portal feature that would let students see when their friends were free.

User Story Acceptance Criteria
As a student, I want to selectively share my timetable with friends so that I can plan study and social time effectively while maintaining control of my data. • Sharing is OFF by default
• Student must explicitly grant access (e.g. accept request)
• Student can choose what to share (free/busy or full timetable)
• Student can hide specific lessons
• Student can view a clear list of who has access
• Changes to sharing apply immediately
As a student, I want a quick and simple way to see when my friends are free so that I can meet them without effort. • Simple add/accept flow to connect students
• Minimal steps required to start using the feature
• Default sharing settings are applied automatically
• No requirement to read instructions to use the feature
• Core functionality works in a single, obvious interaction path
As a student, I want to clearly understand who can see my timetable so that I feel confident and in control of my information. • Clear display of "Shared with X people"
• Clear display of "They can see X" (e.g. free/busy vs full)
• Sharing status visible on the main screen, not hidden in settings
• Changes to sharing are immediately visible to the user
As a student, I want my timetable data to be protected unless I explicitly choose to share it so that my privacy is maintained by default. • No timetable data is visible without explicit consent
• Default visibility is limited
• Sensitive data (e.g. room details) is hidden by default
• Access is removed instantly when revoked
As a student, I want to remove or block access to my timetable so that I can control who can see my information at any time. • Student can remove a connection instantly
• Student can block another user
• Removed users lose access immediately
• Blocked users cannot re-request access for a defined period
As a service, we want to prevent misuse of timetable data so that students are protected from inappropriate monitoring or profiling. • Rate limiting on data access requests
• Anomaly detection for unusual access patterns
• Access logs available to platform administrators
• Automated alerts for repeated failed access attempts
Table 1 - Sample User Stories

What it surfaced was more than information, but a different level of understanding. The team could see that what looked like a straightforward improvement was also tied to patterns of avoidable contact, confusion could have affected reliability if left unaddressed.

We then asked the Twin how some of our personas might respond to the feature in practice.

Persona What they want How they feel What we need to watch for
Nina (high-achieving, organized) • Plan study/revision efficiently
• Coordinate with friends productively
• Control over what is shared
• Positive about useful tools
• Conscious of privacy
• Expects things to "just work"
• Loss of trust if visibility is unclear
• Needs precise control (not basic toggles)
• Will disengage if accuracy/reliability drops
Timmy (low engagement, low IT confidence) • Quick way to see when mates are free
• No effort or setup
• Impatient
• Sees systems as barriers
• Social-first mindset
• Will overshare without thinking
• Ignores warnings and guidance
• Will bypass or abandon feature if friction is too high
Lennie (low IT literacy, easily frustrated) • Simple, obvious functionality
• Clear outcomes ("who can see what")
• Easily confused
• Frustrated by unclear behaviour
• Feels out of control
• Misunderstanding of sharing/privacy
• Increased support tickets ("I didn't do that")
• Needs visibility built into UI, not hidden in settings
Immy (misuse mindset / Insider risk) • Access to other students' availability
• Ability to observe patterns over time
• Minimal barriers to viewing data
• Opportunistic
• Will actively look for loopholes
• May test limits of system controls
• Attempts to map routines, identify when students are free, or infer location and behaviour patterns
• Excessive friend requests
• Repeated access attempts, or attempts to bypass consent controls
Table 2 - Persona Mapping

That changed the conversation. Instead of treating the work as a narrow functional change, the team widened the discussion early. We added resilience and usability considerations sooner, challenged some of our original assumptions, and reshaped the requirement so it reflected the real service context rather than the first view expressed in the room.

The value came from improving the quality of the evidence around the decision, not from having the Digital Twin make the decision for us. It helped the team move from assumption to insight, and from a good workshop output to a stronger and more rounded product definition.

Without that wider view, we would probably have treated the work as a straightforward front-end improvement and moved ahead with a narrower scope. Instead, the team broadened the requirement early, adding resilience and usability considerations and addressing a service dependency that would otherwise have remained hidden until later delivery or live use.

The outcome was a better-informed decision-maker.

How This Changes PRINCE2 Practices

This does not change the principles of PRINCE2, but it does strengthen how they are applied in practice.

Continued business justification becomes more than a periodic review. With access to real usage data, past decisions and emerging risks, the business case can be shaped continuously, rather than revisited at fixed points in time.

Manage by exception also becomes more proactive. Instead of relying on thresholds being exceeded, earlier signals can be identified through patterns in data. This allows intervention before issues escalate into exceptions that require formal escalation.

Learning from experience moves from retrospective to real time. Lessons are no longer something we capture at the end of a stage or project. They are surfaced during decision-making, based on similar situations and outcomes seen before.

Focus on products becomes richer and more informed. Product definitions are shaped not just by workshops and assumptions, but by how services are actually used and experienced.

Manage by stages remains in place, but decision points are stronger. Stage boundaries become informed moments of decision, supported by broader and more current evidence.

The Role of the Project Manager and Board

The role of the project manager and board becomes even more important.AI supports decision-making, but it does not replace it. Its value comes from surfacing insight, identifying patterns and highlighting risk, but those outputs still require interpretation. The responsibility sits with people to understand the context, challenge what is presented and decide whether it holds true.

The focus of these roles shifts slightly. There is more emphasis on interpreting insight, questioning recommendations and ensuring alignment with strategy, risk appetite and organizational priorities.

Accountability remains firmly human. Governance remains essential. The difference is that decisions are made with stronger evidence and fewer blind spots, not with less control.

Risks and Boundaries

There are risks that come with this shift, and they need to be understood and managed.

There is a danger of over-reliance on AI outputs, particularly if they are accepted without challenge. The quality of what is produced is also dependent on the quality and completeness of the underlying data, which is not always consistent.

Explainability remains important. If recommendations cannot be understood or traced, trust will be limited. There is also the risk of bias, where historical data reinforces past decisions rather than improving them.

For these reasons, governance becomes more important, not less. Controls, challenge and accountability must remain firmly in place.

Conclusion: From Managing Delivery to Managing Decisions

PRINCE2 remains as relevant as ever. What is changing is the quality of the information behind the projects we lead.

Digital twins and AI do not replace structure, they strengthen it, reducing blind spots, surfacing risk earlier and bring learning into the moment, not after it.

The role of the project manager becomes more important. Because in the end, projects are not solely defined by what we deliver, but by the quality of the decisions we make along the way.

Take the next step from insight to action.
Download the free Executive Summary of the PRINCE2 Project Management AI Practice Guide (Version 7). For practical guidance on applying AI to improve forecasting, strengthen governance, and support better project decisions, access the full Guide with a PeopleCert Plus membership.

 Lead author

Alex Harding is a chartered IT Professional, neurodivergent, Digital & Technology Leader with over seventeen years of experience in Software Development, IT Infrastructure, Security (Cyber & Physical), Business Intelligence, Project Management, and more! He is also an ITIL Master and ITIL Ambassador, and has recently successfully led service transformation and a major information security project.