Project Management Case Study Example

Public sector information technology (IT) programmes have a long and well-documented record of cost overrun, schedule slippage and diluted benefits. Because they are funded from the public purse and frequently touch citizen-facing statutory services, the governance and control expected of them is unusually stringent. This case study examines how PRINCE2 (PRojects IN Controlled Environments), the structured method originated within UK central government and now maintained commercially, was applied to a mid-sized IT rollout at a local authority. The organisation, its figures and its timeline are illustrative and anonymised, but the delivery pattern is representative of the sector and is used here to demonstrate the method rather than to report on any specific real project. The study moves from context to a critical analysis of the method in use, and closes with recommendations that a practising project manager could act upon.

Background and Context

Harwell Borough Council (an illustrative composite used throughout this study) is a mid-sized English unitary authority serving a population of approximately 240,000 residents and employing around 3,200 staff across adult social care, children’s services, revenues and benefits, planning and corporate functions. Like many authorities, it had accumulated a fragmented estate of legacy line-of-business systems, several of which were approaching end-of-life and could no longer be supported by their vendors. The initiative examined here is the rollout of a single cloud-hosted case management platform intended to replace four ageing systems in adult and children’s social care, consolidate client records, and allow statutory returns to central government to be generated automatically rather than compiled by hand.

The business drivers were threefold. First, there was a compliance imperative: the unsupported legacy systems presented an information security risk and could not reliably meet obligations under the UK General Data Protection Regulation (UK GDPR). Second, there was an efficiency objective, since duplicate data entry across disconnected systems was estimated to consume significant practitioner time that could otherwise be devoted to front-line casework. Third, there was a service-quality ambition: a unified record would give practitioners a single, reliable view of a service user, reducing the risk of information being lost between teams at points of handover. The project carried a notional capital budget of £2.4 million over an eighteen-month delivery window, funded partly from a corporate transformation reserve and partly from an invest-to-save case predicated on licensing consolidation and recovered staff time.

The authority elected to deliver the programme using PRINCE2 rather than a purely agile approach. The rationale, recorded in the project mandate, reflected three features of the public sector operating environment. The procurement was governed by public contract regulations and a fixed-price supplier contract, which made a controlled, document-based method attractive to internal auditors and elected members. The project required clear accountability to a politically accountable body, namely the council’s cabinet and corporate management team, which PRINCE2’s defined governance structure is designed to support. Finally, the organisation had limited appetite for the ambiguity of a wholly emergent approach when citizen data and statutory duties were at stake. PRINCE2’s emphasis on a documented business case, stage-gated control and delegated tolerances suited this risk-averse, accountability-driven setting (AXELOS, 2017). The sections that follow outline the method briefly before analysing how its principles, themes and processes shaped delivery in practice.

The PRINCE2 Methodology: An Overview

PRINCE2 is a process-based project management method that originated in the UK public sector and is now maintained commercially by PeopleCert under the AXELOS brand (AXELOS, 2017). Its enduring appeal lies in a clear separation between the work of managing a project and the technical work of creating products, and in a structure that scales from small initiatives to major programmes. The method rests on three integrated elements: principles, themes (reframed as “practices” in the 2023 edition) and processes (AXELOS, 2023).

Seven principles provide the method’s guiding ethos. A project must demonstrate continued business justification; teams should learn from experience; roles and responsibilities must be defined; work is managed by stages; the project board manages by exception against delegated tolerances; delivery focuses on products; and the method is tailored to suit the project’s environment (AXELOS, 2017). The tailoring principle is frequently overlooked, yet it is the mechanism by which a generic method is made proportionate to a specific context, a point of particular relevance to a resource-constrained local authority. The seven themes describe aspects of management that must be addressed continually: Business Case, Organization, Quality, Plans, Risk, Change and Progress. Each theme answers a recurring management question; the Business Case theme addresses why the project is worthwhile, while the Organization theme addresses who is accountable (Office of Government Commerce, 2009). The seven processes then describe the chronological flow of activity and decision-making, from Starting Up a Project and Directing a Project through Initiating a Project, Controlling a Stage, Managing Product Delivery and Managing a Stage Boundary, to Closing a Project.

A defining characteristic of PRINCE2 is its management-by-stages model. Rather than committing resources to an entire project at the outset, the project board authorises one management stage at a time, reviewing the business case and risk exposure at each boundary. This staged, plan-driven logic is closer to a traditional project life cycle than to an incremental one (Maylor, 2010), but it does not preclude iterative product development; contemporary guidance actively encourages PRINCE2 to be combined with agile delivery inside stages (AXELOS, 2023; Wysocki, 2019). Comparison with the broader bodies of knowledge is instructive. Where the APM Body of Knowledge and the PMBOK Guide describe a wide profession and a menu of practices (Association for Project Management, 2019; Project Management Institute, 2021), PRINCE2 prescribes a specific, auditable control framework. That prescription is also the method’s most common criticism: applied mechanically it can generate documentation for its own sake and a false sense of control (Kerzner, 2017). It was precisely the auditability, however, that made the method attractive to Harwell, and the analysis below considers whether the authority avoided the bureaucratic trap.

Issues and Challenges in the Rollout

Despite a disciplined start, the rollout encountered several challenges that are characteristic of public sector IT delivery. The first and most consequential concerned data. The four legacy systems held overlapping but inconsistent records accumulated over more than a decade, with varying data standards, duplicate client identities and free-text fields where structured data was required. Initial profiling revealed that data quality was materially worse than the supplier’s fixed-price assumptions had allowed for, threatening both the migration timeline and the integrity of the consolidated record. Data migration is a recurring source of difficulty in software projects because the effort it demands is systematically underestimated at the bidding stage (Hughes and Cotterell, 2009).

The second challenge was organisational and cultural. Front-line social work practitioners were understandably protective of established workflows and sceptical of a system perceived as imposed from the centre. Early engagement had been thinner than planned because practitioner time was scarce, and there was a real risk that low adoption would undermine the benefits case even if the technology performed to specification. This is a well-recognised pattern: the barrier to realising benefit from public sector IT is rarely the software itself but the surrounding behavioural and organisational change (Bradley, 2010).

Third, the project operated within a politically and financially volatile envelope. During delivery the authority was required to identify in-year savings, which placed the transformation reserve under scrutiny and created pressure to curtail activities perceived as non-essential, such as training and a period of parallel running. Fourth, a critical integration with a national statutory-reporting gateway proved more complex than specified, with incomplete interface documentation and a slow vendor escalation path. Fifth, scope pressure emerged as individual directorates requested bespoke configuration, each request reasonable in isolation but collectively threatening the baseline and the schedule.

These issues were not, in themselves, failures of the method; they were the conditions the method existed to manage. The analysis that follows considers how far PRINCE2’s themes and processes helped the project team anticipate, contain and respond to them, and where tailoring decisions, or the absence of them, made a material difference. The wider literature on large projects suggests that optimism bias and weak front-end definition are dominant causes of overrun (Flyvbjerg, 2014); a central question is therefore whether PRINCE2’s front-loaded governance offset these tendencies in practice.

Analysis: Applying PRINCE2 to the Project

The remainder of this study analyses how specific PRINCE2 themes and processes shaped the project, drawing on the method’s own guidance and the wider project-management literature. Six areas illustrate the method most clearly: organisation and governance, the business case, management by stages, risk, quality and change control, and a concluding critical appraisal of the method in use.

Organisation: Roles and Governance

PRINCE2’s Organization theme requires a defined project management team structure that separates direction, management and delivery, and that represents three distinct interests on the project board, namely the business, the user and the supplier (AXELOS, 2017). At Harwell this was implemented through a Project Board chaired by the Executive, the Director of Adult Social Care, who owned the business case, supported by a Senior User representing practitioner and service interests and a Senior Supplier drawn from the IT supplier. A dedicated Project Manager handled day-to-day control, while Team Managers within the supplier and the council’s IT function directed product delivery. This structure mattered because it gave elected members and the corporate leadership a single accountable owner and a clear escalation route. In practice the Senior User role proved pivotal: because adoption risk was high, embedding a credible practitioner voice at board level improved the legitimacy of design decisions and gave front-line concerns a direct channel to the Executive, rather than leaving them to surface only at go-live.

Business Case: Continued Justification

The principle of continued business justification was operationalised through a business case that was revisited at every stage boundary rather than written once and shelved. When data-quality problems emerged in Stage 1, the case was deliberately re-examined: the additional cleansing effort increased cost and threatened one element of the efficiency saving, but the board judged that the compliance and service-quality benefits still justified continuation. This is the principle working as intended, namely a conscious, documented decision to proceed on revised evidence rather than momentum-driven continuation of a project that had quietly ceased to be worthwhile. Benefits were defined as measurable outcomes, including reduced duplicate data entry, faster statutory returns and fewer records lost between teams, and were assigned to a Benefits Review Plan for measurement after closure, consistent with established benefits-management practice (Bradley, 2010). Defining benefits in measurable terms at the outset is what later makes it possible to test whether the investment was warranted.

Managing by Stages: The Stage Plan

Management by stages was the project’s principal control. The board authorised resources one stage at a time, with a go/no-go decision at each boundary informed by an End Stage Report and the next detailed Stage Plan (Lock, 2013). Table 1 sets out the stage structure the project adopted.

The staged structure delivered two practical benefits. First, it concentrated decision-making at defined points, which suited a board of busy senior officers and members who could not engage continuously. Second, the Stage 3 pilot functioned as a genuine gate: by deploying to a single directorate first, the project generated real adoption and performance evidence before committing to full rollout, reducing the exposure recorded in the risk register. Tailoring was evident in the decision to run Stages 1 and 2 with iterative, agile-style product delivery inside each management stage, combining PRINCE2 governance with incremental build (AXELOS, 2023). This hybrid arrangement preserved board-level control while allowing the design to respond to what emerged during configuration.

Risk Management: The Risk Register

The Risk theme requires a defined risk-management approach and a maintained risk register recording probability, impact, ownership and response (Office of Government Commerce, 2009). PRINCE2 classifies responses to threats as avoid, reduce, transfer, accept or share, and the register below applies these categories explicitly. Table 2 presents an extract of the project’s risk register as it stood at the end of the initiation stage.

Two features of the register merit comment. First, ownership is pushed to the role best placed to act: data-migration and integration risk sit with the Senior Supplier, adoption risk with the Senior User, and financial and information-governance risk with the Executive, reflecting the Organization structure described above. Second, the responses are proportionate. The information-governance risk (R06), though low in probability, is treated with an avoidance-leaning posture because its impact on a public body would be severe, including potential regulatory action and loss of public trust. The register was a living document reviewed at each stage boundary, and it informed the board’s exception management: when the integration risk (R05) materialised, it was escalated as an issue and a fallback manual return was authorised, illustrating the direct link between the Risk and Change themes and the manage-by-exception principle. It should be acknowledged, however, that the qualitative high/medium/low scoring used here is a simplification; quantified techniques such as expected monetary value or Monte Carlo analysis would give a sharper picture of aggregate exposure on a larger programme (Kerzner, 2017).

Quality and Change Control

The Quality theme was addressed through a Quality Management Approach defining acceptance criteria and a quality register, with user acceptance testing in Stage 3 providing the formal quality gate before rollout. The Change theme addressed the scope pressure identified earlier. A change authority was established with a delegated budget tolerance, so that minor directorate requests could be decided quickly while anything exceeding the tolerance was escalated to the board. Baselining the requirements at the end of Stage 1 and routing subsequent requests through formal change control was decisive in protecting the schedule: several desirable but non-essential configurations were deferred to a post-project backlog rather than absorbed into the live baseline. Issues and changes were logged, assessed for impact and dispositioned transparently, which gave the board confidence that the baseline was being actively defended rather than silently eroded. The Progress theme tied these controls together through tolerances and regular highlight reports, allowing the board to manage by exception rather than through continuous oversight.

Critical Appraisal of the Method in This Context

Set against the project’s outcomes, the evidence suggests that PRINCE2 added value chiefly as a decision-making discipline rather than as a technical toolkit. Its strengths in this setting were the clear accountability of a single owner, the forced re-justification of the business case at each boundary, and the incremental release of resources that limited the authority’s financial exposure when problems emerged. These features are well matched to a politically accountable, audit-sensitive organisation. Equally, the case exposes the method’s limits. PRINCE2 is deliberately silent on technical practice, so it neither predicted nor solved the data-migration and integration problems; it only ensured that, once visible, they were surfaced to an accountable body and managed through issue and change control. There was also a standing risk of the method becoming an end in itself, generating documentation that satisfied auditors without improving delivery, a criticism frequently levelled at heavyweight methods (Kerzner, 2017; Wysocki, 2019). Harwell largely avoided this by tailoring, combining staged governance with iterative build and treating the business case as a live instrument, which is consistent with the view that method and professional judgement are complements rather than substitutes (Maylor, 2010).

Recommendations

Several recommendations follow from this case, relevant both to the authority and to comparable public sector IT rollouts.

1. Invest earlier in front-end definition, particularly data discovery. The single most disruptive issue, poor legacy data quality, was identifiable before contract award. Commissioning independent data profiling during the Starting Up and Initiation processes, and reflecting its findings in the supplier’s fixed-price assumptions, would have reduced optimism bias and strengthened the baseline, consistent with evidence that weak front-end definition drives overrun in large projects (Flyvbjerg, 2014).
2. Treat benefits realisation as a named post-project activity. PRINCE2 formally ends at closure, yet the transformation case depended on benefits that accrue only after the service has adopted the system. The Benefits Review Plan should be owned by a Senior Responsible Owner in the receiving service, with measurement scheduled at defined intervals (Bradley, 2010); otherwise the business case that justified the investment is never tested.
3. Resource change and adoption as a first-class product. Because the dominant risk to benefit was behavioural rather than technical, change-management effort, including champions, role-based training and hypercare, should be protected from in-year savings pressure and represented explicitly in the plan and the risk register.
4. Tailor deliberately and record the decision. PRINCE2’s tailoring principle is a strength only when used consciously. The project’s blend of staged governance with iterative build inside stages worked well and should be documented as a reusable pattern for the authority’s future digital programmes (AXELOS, 2023).
5. Strengthen governance of third-party integrations. The reporting-gateway problem reflected a dependency outside both the supplier’s and the council’s direct control. Early interface testing, contractually defined escalation timescales and a pre-agreed manual fallback should be standard for any statutory integration.

Taken together, these recommendations reinforce rather than replace the method: each is an application of a PRINCE2 principle made sharper by the lessons of delivery.

Conclusion

This case study has examined the application of PRINCE2 to a public sector IT rollout, using an illustrative local authority to represent a pattern common across the sector. The analysis suggests that PRINCE2’s value in this context lies less in any single technique than in the discipline it imposes: a named accountable owner, a business case that must be re-justified at each stage, resources released incrementally against delegated tolerances, and risks owned by those able to act on them. These features directly addressed the governance expectations of a politically accountable, audit-sensitive organisation.

The method was not, however, a guarantee of smooth delivery. The most damaging issues, namely data quality, adoption resistance and an external integration dependency, arose from the project’s environment, and PRINCE2 helped only to the extent that the team used its mechanisms actively: revisiting the business case rather than treating it as a formality, maintaining the risk register as a living document, and holding the line on change control. Where the method was applied mechanically it added documentation; where it was applied thoughtfully, and tailored, it improved decisions.

The wider lesson is that structured methods and sound judgement are complements, not substitutes. PRINCE2 provided the scaffolding for accountable decision-making, but the quality of those decisions still depended on honest front-end analysis, credible user representation and sustained attention to the human side of change. For project managers in the public sector, that combination of method and judgement offers the most reliable route to delivering IT change that is both controlled and genuinely beneficial. As a model case study, the example is intended to illustrate how the methodology can be reasoned about and applied, and to serve as reference material for learners developing their own analytical approach.

References

Association for Project Management (2019) APM Body of Knowledge. 7th edn. Princes Risborough: Association for Project Management.

AXELOS (2017) Managing Successful Projects with PRINCE2. 6th edn. Norwich: The Stationery Office.

AXELOS (2023) PRINCE2 7: Managing Successful Projects with PRINCE2. London: PeopleCert.

Bradley, G. (2010) Benefit Realisation Management: A Practical Guide to Achieving Benefits Through Change. 2nd edn. Farnham: Gower.

Flyvbjerg, B. (2014) ‘What you should know about megaprojects and why: an overview’, Project Management Journal, 45(2), pp. 6-19.

Hughes, B. and Cotterell, M. (2009) Software Project Management. 5th edn. Maidenhead: McGraw-Hill Education.

Kerzner, H. (2017) Project Management: A Systems Approach to Planning, Scheduling, and Controlling. 12th edn. Hoboken, NJ: John Wiley & Sons.

Lock, D. (2013) Project Management. 10th edn. Farnham: Gower.

Maylor, H. (2010) Project Management. 4th edn. Harlow: Pearson Education.

Office of Government Commerce (2009) Managing Successful Projects with PRINCE2. 5th edn. Norwich: The Stationery Office.

Project Management Institute (2021) A Guide to the Project Management Body of Knowledge (PMBOK Guide). 7th edn. Newtown Square, PA: Project Management Institute.

Wysocki, R.K. (2019) Effective Project Management: Traditional, Agile, Extreme, Hybrid. 8th edn. Indianapolis, IN: John Wiley & Sons.