Leading across teams
Most of my projects mix internal engineers, several suppliers and the client's own staff. Nobody reports to everyone. I lead through clear goals, short feedback loops and credit given in public.
PRINCE2
Controlled projects, from mandate to handover
I use PRINCE2 (Projects in Controlled Environments) to run infrastructure projects where several teams and suppliers must land one change safely, such as a data centre build, a network refresh or a set of site migrations. This page explains the method: its principles, roles, processes and stages, and how tolerances and exceptions keep a project under control. It also shows how I tailor it, and how I find what is wrong when a project drifts.
PRINCE2
A method for projects with clear decisions
PRINCE2 (Projects in Controlled Environments) is a project method now owned by PeopleCert. It sets out who decides what, when they decide it, and what they need in front of them to decide well. This page follows the 7th edition, published in 2023. I use the method on infrastructure projects where several teams and suppliers must land one change safely. Choose an element to see what it holds.
Swipe sideways to see the whole diagram.
The seven principles are what make a project a PRINCE2 project. If one is missing, the method is not being used, however many templates are filled in. They cannot be tailored away.
The 7th edition puts people at the centre: leadership, culture, communication, teams and the change the business has to make to use what the project delivers. A project can follow every process and still fail if nobody leads it or nobody adopts the result.
The seven practices, called themes before the 7th edition, are the aspects of project management that run the whole way through. Each one answers a question the project board keeps asking.
The seven processes say who does what, and when, from the first idea to the last handover. Each process is a set of activities, with clear inputs, outputs and decisions.
Everything else is shaped to the project context. A two month site migration and a three year data centre programme use the same principles, but very different amounts of paperwork, stages and reporting.
Where it came from
| Year | What happened |
|---|---|
| 1989 | The CCTA (Central Computer and Telecommunications Agency) adopted PRINCE as the UK government standard for IT projects. |
| 1996 | PRINCE2 was released as a generic method for any kind of project, not only IT. |
| 2009 | A major refresh, known as PRINCE2:2009. |
| 2013 | Ownership moved from the Cabinet Office to AXELOS, a joint venture with Capita. |
| 2017 | The PRINCE2 2017 update, later renamed the 6th edition, with more on tailoring. |
| 2021 | PeopleCert bought AXELOS, and with it PRINCE2, ITIL (IT Infrastructure Library) and MSP (Managing Successful Programmes). |
| 2023 | The 7th edition: themes renamed practices, people added at the centre, and sustainability added as a performance target. |
What it is not
- It is not a technical method. It does not tell me how to design a network or build a data hall. That stays with the specialists, the design authority and the standards they follow.
- It does not cover programme or portfolio management. MSP and the portfolio guidance sit above it.
- It does not replace agile delivery. It governs around it, and PRINCE2 Agile, launched in 2015, shows how the two fit together.
- It is not paperwork for its own sake. Every product should earn its place, and tailoring is a principle, not an option.
The seven practices
| Practice | The question it answers | What it produces |
|---|---|---|
| Business case | Why are we doing this, and is it still worth it? | Business case, benefits management approach |
| Organizing | Who decides, who does the work, and who checks? | Roles, the project management team, communication management approach |
| Plans | How, how much and when? | Project, stage, team and exception plans |
| Quality | What must the products be like to be accepted? | Product descriptions, quality management approach, quality register |
| Risk | What might happen, and what will we do about it? | Risk management approach, risk register |
| Issues | What has happened, and what is its impact? | Issue management approach, issue register, issue reports |
| Progress | Where are we, where are we heading, and should we carry on? | Tolerances, highlight, end stage and exception reports |
The 7th edition uses the American spelling for the Organizing practice, so I keep its official name. The questions follow the wording used in PRINCE2 training.
Architecture work in the same programmes follows the ADM (Architecture Development Method) of TOGAF (The Open Group Architecture Framework), on my TOGAF page.
Principles
Seven principles that cannot be tailored away
The principles are the part of PRINCE2 that never changes. Processes, documents and meetings can all be scaled up or down, but a project without these seven is not being run with PRINCE2. Here is what each one means to me on infrastructure work.
- Ensure continued business justification. There must be a good reason to start, and it must still hold at every stage boundary. If a data centre move no longer pays back because the lease was extended, the board should stop or reshape it, not finish it out of habit.
- Learn from experience. I read the lessons from the last refresh before planning the next one, record new lessons as they happen, and pass them on at closure. Most painful surprises on site migrations have happened to someone before.
- Define roles, responsibilities and relationships. Everyone knows who decides, who does the work and who checks it, including the suppliers. The 7th edition added relationships, because a board that never talks to the delivery teams decides blind.
- Manage by stages. The project is split into management stages, and the board commits to one stage at a time. Long stages hide problems; short stages cost meetings. I set the boundaries where real decisions fall, such as design sign off or the first pilot site.
- Manage by exception. Each level gets targets with tolerances and is left to get on with it. Only a forecast breach goes up. This keeps senior people out of the detail without leaving them in the dark.
- Focus on products. Plans start from what must be delivered and what good looks like, such as a tested site network or an accepted handover pack, not from a list of activities. Quality criteria are agreed before the work starts.
- Tailor to suit the project. The method is shaped to the size, risk and context of the work. A small migration might combine several roles and use one combined report. A regulated bank refresh needs more formal control.
Checking the principles are alive
| Principle | How I can tell it is working | Warning sign |
|---|---|---|
| Business justification | The business case is updated and reviewed at every stage boundary | The business case was written once, for funding, and never opened again |
| Learn from experience | Lessons are logged during the work and read at the next start up | The lessons report is written at closure and filed |
| Roles and relationships | Each decision has one named owner, and suppliers know their reporting line | Decisions are made in corridors, or by whoever shouts loudest |
| Manage by stages | The board authorises one stage at a time against a stage plan | One approval at the start, then nothing until go live |
| Manage by exception | Forecast breaches reach the board early, with options | Overruns are discovered at the end, or the board reviews every detail weekly |
| Focus on products | Product descriptions with quality criteria exist before work packages go out | Work is tracked only as tasks and percentages complete |
| Tailor to suit | The tailoring is written down in the initiation documentation, with reasons | Every template is filled in, whatever the size of the project |
Organisation
Who decides, and who just needs to know
Most projects that drift have a decision problem, not a technical one. PRINCE2 fixes that by naming one owner for each kind of decision and a clear line for reports. Step through the structure to see what flows up and down.
Swipe sideways to see the whole diagram.
PRINCE2 separates four levels. The business layer sits outside the project and sets its objectives. The project board directs, the project manager manages day to day, and team managers deliver. Each level only needs to know enough to do its own job.
The business layer, which might be corporate leadership, a programme or a customer, writes the mandate that triggers the project. It appoints the executive and sets project tolerances: how far time, cost and the other targets may move before it must be asked.
The project board has three interests. The executive owns the business case and has the final say. The senior user speaks for the people who will use the result, and the senior supplier for those who build it. The board authorises one stage at a time.
The project manager turns the stage plan into work packages for each team, each with its own tolerances. On a site migration that might be the network team, a cabling supplier and the server team, each with a team manager.
Team managers report on a set rhythm in checkpoint reports: what was done, what is next, and any issues or risks. Problems inside a work package's tolerance stay with the team manager.
The project manager sends highlight reports to the board, usually every week or two, with help from project support, which keeps the project log and plans up to date. The board does not need to meet to read them.
When a forecast shows a stage tolerance will be breached, the project manager sends an exception report to the board with options. If the project tolerance would be breached as well, the board must go to the business layer.
Project assurance checks on the board's behalf that the project is being run well. It must be independent of the project manager. The board can delegate decisions on small changes to a change authority, often with a change budget.
Each role on a real project
| Role | Who it might be on a data centre move | What they decide or do |
|---|---|---|
| Executive | The IT director who owns the budget | Owns the business case. Final say on the board. |
| Senior user | Heads of the business teams whose services move | Specifies needs and acceptance criteria. Accountable for the benefits. |
| Senior supplier | The infrastructure lead, and the main supplier's delivery director | Commits resources. Accountable for the quality of what is built. |
| Project assurance | An architect from the design authority, a finance partner, a service owner | Checks independently for each board member that the project is being run well. |
| Change authority | A smaller group, such as the project manager and the lead architect | Decides on changes within a delegated limit and change budget. |
| Project manager | The person who runs the move day to day | Plans, delegates work packages, reports and escalates exceptions. |
| Team manager | The network lead, the cabling supplier's site lead | Delivers work packages and reports in checkpoint reports. |
| Project support | A PMO (project management office) analyst | Keeps the project log, plans and records. Runs configuration control. |
Combining roles
- One person can hold more than one role, and one role can be shared, except where independence matters.
- The executive is always one person, so there is one owner of the business case.
- The executive and project assurance must not also be the project manager, a team manager or project support.
- The senior user and the senior supplier can each be several people, but a big board decides slowly. I aim for one voice for each interest.
On infrastructure work the senior supplier is often split between an internal lead and a main contractor. I make sure the contract and the board role say the same thing, so the supplier's reporting line is clear from day one.
People
Projects are delivered by people, not documents
The 7th edition made people one of its five elements, alongside the principles, practices, processes and project context. It covers leadership, culture, communication, teams and the change the business must make to use what the project delivers. This is how I apply it.
Culture
A team that hides bad news makes management by exception useless. I reward early warnings, so an engineer who says a date will slip is thanked, not blamed.
Communication
The communication management approach sets who hears what, how and how often. On a site migration it covers users, the service desk, suppliers, site managers and the people who sign off outages.
Change for the business
A new network or data centre only pays back if people use it well. I plan the change for the receiving teams, such as training for the service desk and new runbooks for operations, as products in their own right.
Relationships with suppliers
I treat suppliers as part of the team, with team managers who report like everyone else. Their contracts match the work packages, so the commercial and project views agree.
Teams that keep learning
After each wave of a rollout the team reviews what slowed it down, and the next wave changes. Lessons recorded during the work beat lessons remembered at the end.
Who hears what
| Audience | What they need | How often | How |
|---|---|---|---|
| Project board | Progress against tolerances, risks, decisions needed | Every one or two weeks, and at each stage boundary | Highlight report, board meeting at stage end |
| Users and site staff | What changes, when, and what they must do | Before each wave, and on the day | Notices, site briefings, a contact for the day |
| Service desk and operations | What is moving, known issues, new runbooks | Before go live and through hypercare, the period of extra support after go live | Handover sessions, knowledge articles |
| Suppliers | Work packages, dates, access, acceptance criteria | Weekly, through their team managers | Work package, checkpoint calls |
| Change advisory board | What will change, the risk and the way back | For each change window | Change requests |
A typical communication plan for an infrastructure project. Each organisation sets its own rhythm.
Processes
Seven processes, from mandate to closure
The processes describe who does what, from the first idea to the last handover. Most of them are run by the project manager. The project board runs one, Directing a project, all the way through, and the teams run another. Step through a project to see how the work and the decisions flow.
Swipe sideways to see the whole diagram.
Before any real money is spent, the mandate is turned into a project brief and an outline business case, the executive and project manager are appointed, lessons from earlier projects are gathered, and the initiation stage is planned. The question is simple: is this worth initiating?
The project board runs this process from start to finish. It authorises initiation, then the project, then each stage or exception plan, gives direction when asked, and authorises closure. Most of its work is done by reading reports and deciding, not by meeting.
The initiation stage builds the foundations: the management approaches for risk, quality, issues, communication and the rest, the project plan, the detailed business case and the project controls. Together they form the project initiation documentation, the baseline the board approves.
Inside each stage the project manager authorises work packages, reviews progress, handles issues and risks, reports highlights to the board and takes corrective action within tolerance. Anything forecast beyond tolerance is escalated.
Team managers accept a work package, build the products, check them against their quality criteria and hand them back, reporting in checkpoint reports. Suppliers can run their own methods inside this process, including agile ones.
Near the end of every stage except the last, the project manager reports on the stage, updates the project plan and business case, and plans the next stage. The board then decides whether to carry on. An exception plan is produced here too.
In the final stage the products are handed over and accepted, the project is evaluated against its baseline, lessons and follow on actions are recorded, and closure is recommended to the board. The business layer then tracks the benefits that come later.
Each process on an infrastructure project
| Process | Who leads it | Main outputs | On a network refresh |
|---|---|---|---|
| Starting up a project | Executive and project manager | Project brief, outline business case, initiation stage plan | Is the refresh worth scoping? Which sites, which suppliers, which lessons from the last one? |
| Directing a project | Project board | Authorisations, direction, closure | Stage approvals, decisions on scope, budget and supplier changes |
| Initiating a project | Project manager | Project initiation documentation, project plan, detailed business case | Survey results, design approach, wave plan, test strategy, budget |
| Controlling a stage | Project manager | Work packages, highlight reports, issue and risk records | Each migration wave, with daily progress and issues on the night |
| Managing product delivery | Team managers | Products, checkpoint reports, quality records | Configured and tested switches, cabling certificates, as built drawings |
| Managing a stage boundary | Project manager | End stage report, next stage plan, updated business case | After the pilot site: what we learned, and the plan for the next ten sites |
| Closing a project | Project manager | End project report, lessons report, follow on actions | Handover to operations, support acceptance, decommissioning list |
Stages
Commit one stage at a time, decide at every gate
Manage by stages is the principle I lean on most. It lets a board approve a large investment without signing a blank cheque, because each stage is approved only when the one before it has shown what it set out to show.
Swipe sideways to see the whole diagram.
Management stages are the chunks the board commits to, one at a time. There are at least two: an initiation stage, and one or more stages to deliver. Each ends with a decision about whether to carry on.
The technical work does not stop politely at a stage boundary. Design work can finish early in stage 3, and surveys for later sites can run while the first are designed. PRINCE2 keeps the two views apart: stages are for control, steps are for doing.
At the end of each stage the project manager sends an end stage report, the plan for the next stage and an updated business case and project plan. The board decides to carry on, change course or stop. Stopping early is a valid, and sometimes the best, outcome.
I set stage boundaries where real decisions fall. On a large rollout I put a gate straight after the pilot site, so the board approves the full rollout only once the pilot has proved the design, the runbook and the supplier.
There is no separate closing stage. The last delivery stage also hands over the products, gets them accepted, evaluates the project and recommends closure. Benefits that come later are tracked by the business layer.
How long should a stage be?
| Question | Shorter stages | Longer stages |
|---|---|---|
| Control | More decision points, problems surface sooner | Fewer decisions, the board can lose sight of the work |
| Overhead | More end stage reports and board time | Less reporting overhead |
| Planning | Each stage plan can be detailed and reliable | Detailed plans go stale before the stage ends |
| Good fit | New technology, a new supplier, regulated or high risk work | Repeat work with a proven design, such as wave 20 of 30 |
Tolerances
Manage by exception, with numbers agreed in advance
Tolerances are how PRINCE2 keeps senior people out of the detail without leaving them in the dark. Each level is given targets with room to move. Inside that room, problems are dealt with and reported. Outside it, they go up one level, early and with options.
Swipe sideways to see the whole diagram.
Every plan has targets, and every target has a tolerance: how far it may move before the level above must be told. The business layer sets project tolerances, the board sets stage tolerances, and the project manager sets tolerances for each work package.
While actuals and the forecast stay inside the band, the project manager deals with problems and reports them in the next highlight report. The board does not need to meet, and nobody is surprised.
The trigger is a forecast, not an actual. As soon as I can see the stage will end outside its tolerance, I send an exception report to the board, with the cause, the options and my recommendation. Waiting until it happens removes the options.
If the board agrees, I produce an exception plan to replace the rest of the stage, with new tolerances. The board can also cut scope, add money or time within the project tolerance, or ask for a premature close.
If the forecast would breach the project tolerance too, the board cannot approve it alone. It refers the exception to the business layer, which decides whether the project still makes sense and on what terms.
Seven performance targets
| Performance target | Example tolerance on an infrastructure project | Where it is set |
|---|---|---|
| Time | ± 2 weeks on a stage, ± 4 weeks on the project | Project plan and stage plans |
| Cost | ± 10% of the stage budget | Project plan and stage plans |
| Scope | Must have sites fixed; could have sites may move to a later phase | Project product description, plans |
| Quality | No priority 1 defects open at handover; other defects within an agreed number | Project product description, product descriptions |
| Benefits | Yearly savings within 10% of the business case figure | Business case |
| Risk | No single risk above an agreed exposure without the board's approval | Risk management approach |
| Sustainability | At least 90% of removed equipment reused or recycled, power per rack within the design limit | Sustainability management approach |
Tolerances are examples, labelled indicative. Each board sets its own. Sustainability became the seventh performance target in the 7th edition.
Try it: inside tolerance, or an exception?
Set a stage budget and length, the tolerances the board gave me, and my forecast for the end of the stage. The tool says who decides and what I send. The figures are indicative.
Cost
Time
Cost
Time
- Cost forecast
- £690k, £90k over plan, tolerance ± £60k
- Time forecast
- week 13, 1 week late, tolerance ± 2 weeks
- Who decides
- The project board
- What I send
- Exception report, then an exception plan if agreed
Forecast beyond stage tolerance. I send an exception report to the project board now, with options and a recommendation. If the board agrees, I write an exception plan for the rest of the stage.
Business case
Still worth it? Asked at every gate
Continued business justification is the first principle for a reason. A project that made sense in January can stop making sense by June. The business case is a living document that the board checks at every stage boundary, not a funding form.
Swipe sideways to see the whole diagram.
In Starting up a project the executive owns an outline business case: the reasons, the options considered, the expected benefits and costs, the timescale and the main risks. It only needs to be good enough to decide whether initiation is worth paying for.
In initiation the case is refined with real costs from the project plan and the risks from the risk register. The benefits management approach says how, when and by whom each benefit will be measured, often long after the project has closed.
At each stage boundary the business case is updated with actual costs and new forecasts, and the board asks whether the project is still desirable, viable and achievable. If it is not, the right answer is to close early, and that is a success for the method.
At closing the project confirms the benefits already achieved, and the benefits management approach passes to the business layer. The project manager is not left holding promises the project cannot keep.
Most infrastructure benefits come later: lower support costs, fewer outages, a data centre lease ended. Benefits reviews track them against the business case until payback and beyond. The senior user is accountable for them.
What goes in a business case
| Part | What I put in it on an infrastructure project |
|---|---|
| Reasons | Why now: end of life equipment, a lease ending, a merger, a regulatory finding, or an outage that must not happen again |
| Business options | Do nothing, do the minimum and do something, each costed honestly. Do nothing is often more expensive than it looks. |
| Expected benefits | Measurable and owned: lower support and power costs, fewer priority 1 incidents, faster site moves |
| Expected disbenefits | What gets worse: training time, a period of dual running, a temporary loss of a feature |
| Timescale | The project period, and when each benefit is expected to arrive |
| Costs | Capital and operating costs, including support, licences, power and decommissioning |
| Investment appraisal | Payback period and net present value over the life of the assets |
| Major risks | The few risks that could change the decision, taken from the risk register |
Products
Plan the products first, then the work
Focus on products is the principle that changes plans the most. Before anyone lists tasks, I agree what will be delivered and what good looks like. On a network refresh that means the HLD (high level design), the LLD (low level design), the tested network and the handover pack, each with its own description.
Swipe sideways to see the whole diagram.
Planning starts with the project product description: what the project will hand over, and the customer's quality expectations and acceptance criteria. Here the product is a refreshed site network, accepted when it passes the agreed tests and support has signed it off.
The product breakdown structure splits the end product into the products that make it up, grouped for clarity. It includes the dull products that projects forget, such as the as built pack, support acceptance and the list of kit to decommission.
Each important product gets a product description: its purpose, what it is made of, where it comes from, its quality criteria, how it will be checked and who approves it. Writing these first is how focus on products becomes real.
The product flow diagram shows the order in which products must be made, and which depend on which. The low level design needs the survey, the staged kit needs the design and the delivered kit, and so on.
Only now are activities, people, durations and dates added, and the critical path appears from the flow. Plans built this way are harder to fool: a task can be 90% done for weeks, but a product is either approved or it is not.
A product description I would write
- Title
- Low level design for one site
- Purpose
- Gives engineers everything needed to build and test the site without guessing
- Composition
- Device list and roles, port maps, addressing, VLANs, routing, security policy, configuration templates, test plan
- Derivation
- High level design, site survey, design standards, vendor guidance
- Quality criteria
- Traces to the high level design; every port and address allocated; tests have pass marks; no open design decisions
- Quality method
- Peer review by a second engineer, then a design authority review
- Approver
- Lead architect, with operations signing that it can be supported
Why I plan this way
- Scope arguments become concrete. If a product is not in the breakdown, it is not in the project.
- Suppliers know what done means before they start, because the quality criteria are in the work package.
- Progress is measured in approved products, which cannot be 90% finished.
- The handover products are planned from day one, so operations are not handed a surprise at the end.
This is the same habit as my test packs with pass marks: agree what good looks like before the work starts.
Quality
Agree what good looks like before anyone builds
The quality practice separates quality planning, which happens before the work, from quality control, which checks the products as they are made. Acceptance is the end of the chain: the people who will use and support the result say it is fit for purpose.
| Quality planning | What it holds | Example |
|---|---|---|
| Customer's quality expectations | What the customer expects of the end product, in their own words, then made measurable | Calls and trading screens unaffected during the move; no loss of resilience |
| Acceptance criteria | The measurable list the end product must meet to be accepted | All tests passed, monitoring in place, support signed off, as built pack complete |
| Product descriptions | Quality criteria and the quality method for each product | Low level design reviewed by a peer and the design authority |
| Quality management approach | Standards, methods, records and responsibilities for quality on this project | Which tests, which reviewers, which tools, where results are kept |
| Quality register | A record of every planned and completed quality activity | Each review and test, with its date, result and sign off |
The quality review technique
Chair
Runs the review and makes sure it reaches a decision: approved, approved with changes, or not approved.
Presenter
Introduces the product and answers questions. Usually its author or the team that made it.
Reviewer
Checks the product against its quality criteria before the meeting, and brings questions, not opinions.
Administrator
Records the actions and the result, and updates the quality register.
How the practice maps onto infrastructure testing
| Test on my projects | What it proves | Who accepts it |
|---|---|---|
| Design review | The design meets the requirements and the standards | Lead architect and design authority |
| FAT (factory acceptance test) | Kit is built and configured correctly before it leaves the bench or the factory | Team manager, with the supplier |
| SAT (site acceptance test) | The installed network works on site, against the test pack | Project manager, with site and service owners |
| Operational acceptance | Operations can monitor, support and recover it: runbooks, alerts, spares and access | The service owner and support teams |
| User acceptance | Users can work as before, or better | The senior user |
The test pack and its pass marks are written with the design, as on my design authority page. PRINCE2 adds the record: every check is planned in the quality register and signed off by a named person.
Risk and issues
Risks are what might happen, issues are what has
The Risk practice deals with uncertain events that would affect the objectives. The Issues practice, which replaced the Change theme in the 7th edition, deals with things that have already happened, including requests for change. Step through how an issue is handled, and who may decide it.
Swipe sideways to see the whole diagram.
An issue is anything that has happened and needs attention. PRINCE2 names three kinds: a request for change, an off specification where a product does not or will not meet its specification, and a problem or concern. Small ones go in the daily log; formal ones go in the issue register with an issue report.
I assess the impact on every performance target and on the business case, and check whether it creates or changes any risks. A small change to a cabling route can still move a migration date.
I set out the options, each with its cost, its effect on the plan and its risks, and recommend one. Doing nothing is often an option worth costing.
If the fix fits inside tolerance, I decide as project manager. The board can also delegate decisions on requests for change to a change authority with a change budget, which stops small changes queuing for a board meeting.
If it would breach stage tolerance, it goes to the board as an exception. If it would breach project tolerance, the board refers it to the business layer. Each level decides only what it has the authority to decide.
The decision is carried out, plans and baselines are updated under configuration control, the registers record the outcome, and the person who raised the issue hears what happened to it.
The risk procedure
- Identify. Find threats and opportunities, and describe each with a cause, an event and an effect, so it can be managed.
- Assess. Estimate likelihood, impact and proximity, then look at the overall exposure against the risk tolerance.
- Plan. Choose a response, and name a risk owner and an actionee for it.
- Implement. Carry out the response, check it works and keep the risk register current.
- Communicate. Report risks in highlight and end stage reports throughout, not only at the end.
A few lines from a risk register
| Risk | Owner | Response |
|---|---|---|
| Network kit arrives late because of lead times | Senior supplier | Order long lead items in the design stage; agree substitute models |
| Legacy applications fail after the move because of hard coded addresses | Senior user | Discovery of dependencies; test moves in a pilot; address translation as a fallback |
| Key engineer unavailable on the cutover weekend | Project manager | Two trained engineers per role; runbooks anyone can follow |
| Power or cooling in the new hall below design limit at full load | Senior supplier | Load test before migration; stage the moves by power draw |
Indicative risks from infrastructure moves, with owners and responses.
Responses to threats and opportunities
| Response | For | Example on a data centre move |
|---|---|---|
| Avoid | Threat | Move the change window away from the quarter end, so a failure cannot hit trading |
| Reduce | Threat | Stage and test all kit on the bench first, so fewer faults reach site |
| Fallback | Threat | A tested rollback plan if the cutover fails, with a go or no go point |
| Transfer | Threat | Fixed price installation, so a supplier carries the cost of its own rework |
| Share | Both | A gain share deal with a supplier for finishing early |
| Accept | Threat | A small risk with a cheap fix if it happens, recorded and watched |
| Exploit or enhance | Opportunity | Bring a lease end forward once the new hall is proven early |
The response names follow PRINCE2 training material, and vary a little between editions. A risk budget, held by the executive, pays for planned responses and is not a reserve for overruns.
Progress
Reports on a rhythm, escalations when they matter
The progress practice answers three questions: where are we, where are we heading, and should we carry on? It uses tolerances, a steady rhythm of reports and records, and event driven reports for anything that cannot wait.
Swipe sideways to see the whole diagram.
- Checkpoint: team manager to project manager
- Highlight: project manager to board
- Exception: when a forecast breaches tolerance
- End stage: at the gate
Time driven and event driven controls
| Control | Time driven or event driven | Example |
|---|---|---|
| Highlight report | Time driven | Every week or two during a stage |
| Checkpoint report | Time driven | Weekly, or daily during a migration weekend |
| Authorisation of a stage | Event driven | At each stage boundary |
| Exception report | Event driven | As soon as a forecast breach is clear |
| Issue report | Event driven | When a formal issue needs a decision |
| End stage and end project reports | Event driven | At each gate, and at closure |
Forecasts, not just actuals
- Every highlight report forecasts the end of the stage against its tolerances, not only what was spent.
- I show progress as products approved against plan, which is harder to round up than tasks.
- A good report fits on one page and ends with the decision the board is being asked for, if there is one.
- Most of this now lives in a tool, such as a project system or ServiceNow, with the board reading a dashboard. The rhythm matters more than the format.
Management products
| Kind | Management product | What it is for |
|---|---|---|
| Baseline | Business case, project brief, project product description | Why, what and for whom. Approved and then changed only under control. |
| Baseline | Project initiation documentation, plans (project, stage, team, exception) | How the project will be run and delivered |
| Baseline | Management approaches: benefits, change, commercial, communication, digital and data, issue, quality, risk, sustainability | The rules for each practice on this project |
| Baseline | Product descriptions and work package descriptions | What each product must be, and the work handed to each team |
| Report | Checkpoint, highlight, end stage, end project, exception, issue and lessons reports | A snapshot at a point in time, for a decision or a record |
| Record | Project log: daily log, issue register, lessons log, product register, quality register, risk register | Living records, kept up to date by the project manager and project support |
Grouped as in PRINCE2 training material for the 7th edition. Tailoring decides which are separate documents, which are combined and which are a line in a tool.
Tailoring
Tailored to the project, never to the point of losing control
Tailoring is a principle, not an option. The 7th edition shapes everything to the project context: its size, its delivery approach, whether it is part of a programme, its suppliers and its risk. Delivery can be linear sequential, iterative incremental or a hybrid of the two.
Linear sequential
Requirements are fixed early and the work moves through design, build, test and deploy in order. It suits a data centre build or a cabling project, where rework is expensive.
Iterative incremental
Requirements evolve and products are delivered in small increments. It suits automation, portals and tooling, where users learn what they want by using it.
Hybrid
Most of my infrastructure projects are hybrid: the hardware follows a plan, while automation and the operational tooling around it are built iteratively.
Try it: tailor PRINCE2 to a project
Answer five questions about a project. The suggestions are how I would usually start, before talking to the board. The example shown is a medium sized refresh with several suppliers.
How big is it?
Delivery approach
Context
Suppliers
Risk
- Project board
- An executive, a senior user and a senior supplier, meeting at each gate and deciding by exception in between.
- Stages
- Initiation, then two or three delivery stages, each ending at a real decision.
- Reporting
- A weekly or fortnightly highlight report, with checkpoint calls each week.
- Documents
- Initiation documentation with short approaches for risk, quality, issues and communication.
- Delivery approach
- Design and build follow a plan, while automation and tooling are built in iterations. Each part gets the tolerance that suits it.
- Business layer
- Senior leadership sets the project tolerances and receives the benefits.
- Suppliers
- A commercial management approach, a team manager for each supplier, and one voice for the senior supplier role.
- Control
- Normal tolerances and a change authority with a small change budget.
- Always
- The seven principles apply in full, whatever the size.
How PRINCE2 sits beside other methods
| PRINCE2 | Body of knowledge | Scrum | MSP | |
|---|---|---|---|---|
| What it is | A method for running a project | The PMBOK (Project Management Body of Knowledge) Guide, from PMI (Project Management Institute) | A framework for a team delivering in short sprints | A method for a programme of related projects |
| Main focus | Governance, roles, stages and products | Principles and practices for project performance | Delivering working increments, with fast feedback | Outcomes and benefits across several projects |
| Who decides | Project board, by exception | Depends on the organisation | Product owner for priorities | Sponsoring group and senior responsible owner |
| How I combine them | The control frame around the project | A reference for techniques, such as estimating | Inside Managing product delivery, for software and automation | Above PRINCE2, as the business layer |
Once a project hands over, the service is run with ITIL practices, and the design rules stay with the design authority.
When it goes wrong
Finding what is wrong with a project
Projects fail in a few familiar ways, and the cause is rarely where the symptom appears. A late stage is often a reporting problem, and a failed handover is often a requirements problem. Choose a symptom to see where I look and what I change.
Swipe sideways to see the whole diagram.
Scope keeps growing. Requests for change are being accepted in conversation, so the plan and the business case no longer match the work. I route every change through the issue procedure, set up a change authority with a small change budget for minor ones, and treat the product breakdown structure as the scope.
An overrun is found at the end of a stage. Reports showed actuals but no forecast, so the breach was visible only once it had happened. Every highlight report I write forecasts the end of the stage against its tolerances, and I raise an exception as soon as the forecast leaves the band.
Decisions take weeks. The board is too big, or its members cannot commit their side. I aim for one voice for each of the three interests, written delegated limits, decisions by exception between meetings with a deadline, and a change authority for small changes.
Nobody can say if it paid off. Benefits were promised but never owned or measured. The senior user is accountable for them, baselines are measured during initiation, and the business layer runs benefits reviews after closure. If a benefit cannot be measured, I say so in the business case.
A supplier keeps missing dates. The work package was vague, or it did not match the contract. I write work packages with products, quality criteria, tolerances and a reporting rhythm, align them with the contract, and hold the senior supplier to account for the supplier's resources.
Defects are found at handover. Products were accepted without being checked against quality criteria, often because there were none. I write product descriptions with quality criteria first, plan every review and test in the quality register, and accept nothing without a record.
The same risks every week. The register has become a list of worries. Each risk needs an owner, a response and an actionee with a date, and the expensive responses need a risk budget the executive has agreed.
Operations refuse the handover. Operational acceptance was never part of the acceptance criteria, so support teams were not involved. I put runbooks, monitoring, spares and training into the project product description from the start, and plan a hypercare period before closure.
The records I read first
| Question | Where I look | What it tells me |
|---|---|---|
| Is the business case still true? | Business case, last end stage report | Whether the reasons, costs and benefits still hold |
| Are we inside tolerance? | Latest highlight report, stage plan | The forecast against each target, not just the spend |
| Who has decided what? | Board minutes and the daily log | Whether decisions are being made, and by the right level |
| What has changed? | Issue register, product register | Changes accepted, and whether baselines were updated |
| What could hurt us next? | Risk register | Owners, responses and dates for the top risks |
| Is it good enough? | Quality register | Reviews and tests planned against those done and passed |
| Have we learned? | Lessons log | Whether lessons are being acted on during the project, not just recorded |
When I join a project that is in trouble, I read these seven records before I talk to anyone. The gaps between them usually show where the problem is. My general fault finding method is on the troubleshooting page.
Engagement
How I run a project, from mandate to benefits
Most of my projects are infrastructure changes with several suppliers: a refresh, a migration or a build. These stages are how I take one from the first conversation to the benefits, and each maps onto a PRINCE2 process.
Swipe sideways to see the whole diagram.
I start by finding the person who owns the money and the reason, and making them the executive. Together we turn the mandate into a short brief, propose the board and read the lessons from the last similar project. This is Starting up a project, and it should take days, not months.
I write the project product description with the senior user: what will be handed over, and the measurable acceptance criteria, including what operations need to support it. Targets and tolerances for time, cost, scope, quality, benefits, risk and sustainability are agreed here, so later exceptions are judged against numbers.
Before the plan I find out what is really there: sites, equipment, dependencies, contracts, change freezes and who can work when. The findings feed the outline business case and the first risk register. On migrations, application dependencies are usually the biggest unknown, so I start on them early.
Initiation turns the brief into the project initiation documentation: the management approaches, a project plan built from products, the detailed business case and the tailoring. The technical design runs alongside under the design authority. The board approves the whole package before the first delivery stage starts.
Each delivery stage runs through Controlling a stage and Managing product delivery. Work packages go out with tolerances, checkpoint and highlight reports come back, and issues and risks are handled at the right level. Every change to live services still goes through change control, and each stage ends at a gate.
In the final stage the products are handed over and accepted, including operational acceptance by the teams who will support them. Hypercare covers the first weeks. I write the end project report against the original baseline, record lessons and follow on actions, and recommend closure to the board.
Most benefits arrive after the project closes, so the benefits management approach passes to the business layer, with named owners and dates for each review. Lessons go into the next start up, follow on actions get owners, and the asset and contract records are left accurate for the next refresh.
Functional requirements
What the project must deliver and control.
- Deliver every product in the project product description, accepted against measurable criteria.
- Give the board a decision point at the end of every stage, with an updated business case.
- Escalate any forecast breach of tolerance to the right level quickly, with options.
- Handle every request for change through one issue procedure, with clear limits of authority.
- Hand over to operations with runbooks, monitoring, spares and trained support teams.
- Record lessons during the project and pass them on to the next one.
Non functional requirements
How well the project must be run, with a number wherever one can be agreed.
- Reporting
- A highlight report every one or two weeks, with a forecast against each tolerance (typical).
- Escalation
- An exception report within five working days of a forecast breach becoming clear (typical).
- Decisions
- Board decisions on an exception within ten working days (typical).
- Tolerances
- Stage cost tolerance of about ± 10% and time tolerance of about ± 2 weeks, set by the board (typical).
- Quality
- No priority 1 defects open at handover, and a quality record for every product.
- Changes
- Every change to live services approved through change control, with a tested rollback.
- Benefits
- Each benefit with an owner, a baseline measure and a review date.
- Sustainability
- A target for reuse or recycling of removed equipment, agreed with the board (typical).
Numbers are typical starting points. Each board agrees its own.
Who I talk to
- The executive, and whoever controls the budget
- Senior users, including operations and the service desk
- Suppliers and their delivery leads
- Finance, procurement and legal, for contracts and costs
- Site, facilities and security teams, for access and change windows
How I find out
- Reading the mandate, any earlier business case and the lessons from similar projects
- Workshops with board members to agree roles, tolerances and reporting
- Site surveys and dependency discovery for anything that moves
- Contract reviews, so work packages match what suppliers have agreed to do
- A risk workshop with team managers and suppliers
Discovery tools
| Tool or source | What it tells me |
|---|---|
| Lessons logs from earlier projects | What went wrong last time, and what to plan for |
| Asset register or CMDB (configuration management database) | What is in the estate, how old it is and whether it is supported |
| Contracts and statements of work | What each supplier has agreed to deliver, and how changes are priced |
| Change calendar and freeze dates | When work on live services is allowed |
| Finance system and purchase orders | Actual costs to compare with the plan |
| A project tool, such as Microsoft Project, Jira or ServiceNow | Plans, logs and registers in one place for the board and the teams |
When a project goes wrong I look for the level where the cause sits, which is often not where the symptom appears.
My approach
- Symptom. What exactly is late, over budget or failing, and since when? Which target does it affect?
- Records. Read the highlight reports, the registers and the plans before talking to anyone.
- Level. Find the level that owns the cause: the business layer, the board, the project manager, a team or a supplier.
- Tolerance. Is it inside tolerance and being handled, or a breach that should already have been escalated?
- Options. Set out the options with their cost and effect, and recommend one, in an exception report if needed.
- Learn. Record the cause in the lessons log, and change the control that let it happen.
Problems I see most
- Requests for change accepted in conversation
- Highlight reports with no forecast
- A board too large to decide
- Benefits with no owner or baseline
- Work packages that do not match the contract
- Operations brought in at the end
Layer by layer
| Layer | What I check |
|---|---|
| Business layer | Whether the mandate, the project tolerances and the ownership of benefits are clear, and still match the strategy. |
| Directing | Whether the board meets its decision deadlines, and whether each interest has one clear voice. |
| Managing | Whether the plans, forecasts, registers and project log are current and honest. |
| Delivering | Whether work packages have clear products, quality criteria, tolerances and a reporting rhythm. |
| Suppliers | Whether the contracts, the commercial terms and the work packages say the same thing. |
The fault finder under When it goes wrong covers each problem in detail, and my general method is on the troubleshooting page.
Closing a project does not end the need for support. Before closure I agree who carries each open item.
Service model
Who owns the service after closure: the service desk, operations, suppliers and the service owner, with escalation paths written into contracts.
Hypercare
A period of extra support after go live, with exit criteria agreed in advance, such as two weeks with no priority 1 incidents.
Follow on actions
Every open issue, risk and defect at closure gets an owner outside the project, recorded in the end project report.
Knowledge
Runbooks, as built drawings and known errors are handed to operations as products, and reviewed like any other.
Contracts
Support contracts and warranties start on the right dates and cover what was actually installed.
Lessons
The lessons report goes to the business layer and the project office, so the next project starts better.
Projects end, but the assets and benefits they create go on. I plan for that before closure.
- Benefits reviews. Planned reviews after closure measure each benefit against its baseline. The senior user owns them and reports to the business layer.
- Refresh planning. The asset records a project leaves behind show when each item reaches end of support, which starts the next business case.
- Method updates. PRINCE2 itself changes. The 7th edition renamed themes as practices and added people and sustainability, so I update my templates when the method moves.
- Certification. PeopleCert runs the exams. PRINCE2 7 Foundation is 60 questions in 60 minutes, closed book. Practitioner is 70 questions in 150 minutes, open book. Both need 60% to pass.
- Programmes. When several projects serve one outcome, the benefits and the business layer role move up to a programme, often run with MSP.
- Improvement. Lessons feed the organisation's own tailored version of PRINCE2, so it fits better each time it is used.
Projects
Where I have used it
PRINCE2 delivery is part of my governance work. As technical design authority and lead architect I have planned phased rollouts, led blended teams of engineers and vendors, delivered a data centre build from an empty shell, and worked under formal change governance in banking.
A phased rollout to every site worldwide
Planned the network and security transformation as a phased, site by site roadmap, and upgraded every global site remotely during the COVID lockdowns through local enablement, with no delay. Led 7 engineers and architects, coordinated 5 vendors, and safeguarded over £200M of transactional services at 99.99% uptime.
The £25M Network Rail data centre build
Delivered the Network Rail data centre build from an empty shell, covering structured cabling, building management systems and mechanical and electrical integration, while leading 3 engineers on finance, transport and government projects.
A refresh under strict change governance
Delivered the EMEA (Europe, the Middle East and Africa) network refresh: audit, design and implementation of LAN (local area network), WAN (wide area network), SD-WAN (software defined WAN) and data centre infrastructure. It replaced end of life equipment with minimal impact on global operations. Worked with a blended team of 5 engineers and 4 vendors, and advised on change governance.
Benefits that were measured
Post merger infrastructure integration across a multi site estate, including distribution centres. Rationalising infrastructure, support and technology overheads delivered £700k a month in operational savings.
Remote site migrations, no critical incidents
Planned and ran remote site migrations across regulated environments with no critical incidents, as lead architect on modernisation programmes from discovery to operational handover.
A phased roadmap for Dyson
Assessed OT (operational technology) maturity across Dyson manufacturing sites, identified capability gaps and shaped a phased IT and OT transformation roadmap covering zoning, OT security and a unified namespace for plant data.
Backed by PRINCE2 Practitioner, with ITIL v3 and v4 for the service side. See all credentials
Explore
More areas I design and deliver
Every page follows the same idea: how it works, the choices that matter, and where I have used it. The foundations pages explain the basics the others build on.