Base Management Case

Base Management Case

[This section demonstrates that the project is being set up for success. It details the practical arrangements for project management, governance, risk management, and benefits realisation. It provides assurance that the project is deliverable and that its outcomes will be actively managed and evaluated.]

1. Project management and delivery arrangements

[Describe the team structure and key roles. Past projects consistently highlighted that having a dedicated project manager and a multi-disciplinary team was a critical success factor for these types of innovative projects.

Project team: Outline the core team. This should be multi-disciplinary. Past projects show that the most successful projects involved a blend of skills from Planning, Communications, IT/Digital, and Procurement from the outset. Include an organogram if possible.

Key roles and responsibilities:

• Senior Responsible Owner (SRO): [Name and Title] – Accountable for the project delivering its objectives and benefits. Champions the project and unblocks senior-level issues.
• Project Manager: [Name and Title] – Responsible for the day-to-day management of the project, ensuring it is delivered on time, within budget, and to the required quality.
• Project Board: [List members/roles] – Provides overall direction and oversight, approves key deliverables, and makes key strategic decisions.
• External Suppliers / Partners: [List key partners] – Clearly define their roles in the delivery.

2. Project governance and assurance

[Explain the decision-making and reporting framework. How will progress be monitored and decisions made? This section also outlines the specific controls for managing the project’s budget.

• Reporting: Describe the reporting cycle (e.g. Monthly highlight reports to the Project Board, regular check-ins with the SRO).
• Budget Management: Who holds the overall project budget (the SRO)? Who is responsible for day-to-day budget tracking (the Project Manager)? State the cost centre and any specific financial system requirements.
• Governance: Which board or group has ultimate authority to approve key decisions, changes, and expenditure? (e.g. Corporate Transformation Board, Service Leadership Team).
• Escalation Path: What is the defined path for escalating risks and issues that cannot be resolved by the Project Manager or Project Board?
• Assurance: How will the project be independently assured? (e.g. Internal Audit review, peer review from another service area or local authority).]
• Financial change control: How will changes that impact the budget be managed? e.g., “Any proposed changes to scope that result in a forecast overspend of more than 5% must be submitted via a formal change request to the Project Board for approval.”
• Data Protection Impact Assessment (DPIA) and security: Confirm DPIA completion and cybersecurity compliance.
• AI and automation: If applicable, include governance around AI use.
  
  Your AI governance should cover: 
• ethics and bias: making sure that the risk that AI could produce unfair or biased outputs has been accounted for/addressed.
• accountability and human oversight: making sure there is a clear “human in the loop” at the point of decision, and points for redress should residents wish to appeal an automated decision.

• transparency and explainability: addressing how the local authority will explain the logic behind an automated decision. Understanding whether the system is a “black box”, or if its reasoning can be clearly articulated.

3. Programme plan and key milestones

[Provide a high-level project plan showing the key phases, major activities, and target completion dates. A Gantt chart is the clearest way to present this. 

4. Risk, constraint, and dependency management

[Summarise the key risks to the project’s successful delivery. This should link to a more detailed Risk Register which is managed and updated throughout the project lifecycle. 
 
Past projects identified several common risks:

• Resource constraints: Lack of dedicated officer time to manage the project and supplier relationship.
• Procurement delays: The procurement and contracting process takes longer than anticipated.
• Technical integration issues: The new solution does not integrate smoothly with existing council IT systems (a major challenge for several councils).
• Low public adoption: The target audience does not engage with the new platform, undermining the project’s objectives.

Constraints: List any major constraints, e.g. fixed budget, immovable deadline, limited availability of specialist skills.

Dependencies: List any key dependencies, e.g. reliant on the Corporate IT team to approve security requirements; dependent on another project delivering a new CRM.

Contingency planning: This section provides assurance that the project has a credible fallback plan (“Plan B”) in the event a major risk materialises. This demonstrates that the project has a planned response to critical issues. Outline a response to 1-2 of your highest-impact risks:

• Contingency for supplier failure: For example, “If the chosen supplier fails to deliver the core platform to an acceptable standard by the Go-Live milestone, or ceases trading, the Project Board will trigger this contingency. The immediate plan would be to use the existing corporate survey tools to run a ‘Do Minimum’ version of the planned consultation, ensuring statutory deadlines are met.”
• Contingency for critical technical failure: “If the new platform suffers a critical technical failure post-launch that cannot be resolved by the supplier within 5 working days, the SRO will invoke the contingency plan. The public-facing site will be disabled and replaced with a message directing users to a simplified feedback form (using existing corporate technology), ensuring public engagement can continue in a limited capacity.”]

5. Change management and communications 

[This section is critical for ensuring the project achieves internal buy-in and is successfully adopted by staff and stakeholders. It outlines the plan for managing the “people side” of the transition from the old way of working to the new. 

• Stakeholder engagement & communications plan: Describe your plan for engaging key stakeholders throughout the project. How will you ensure people feel involved?
  
  Consider: 
• Internal stakeholders: Planners, DM officers, business support, IT, senior management, and councillors. How will they be kept informed and given opportunities to shape the solution (e.g. through show-and-tells, workshops, regular newsletters)? 
• External stakeholders: Statutory consultees, key community groups, residents, and applicants. How will they be prepared for the change? (e.g. early briefings, public-facing web content, user guides).  
  
• Training and support: Outline how staff will be equipped with the skills and confidence to use the new system effectively.
  
  A good strategy includes: 
• Formal training: Role-based training sessions for different user groups. 
• Ongoing support: What happens after the initial training? (e.g. “A dedicated ‘champions network’ will be established to provide peer support, supplemented by digital user guides and weekly drop-in sessions for the first month after go-live.”) 
  
• Culture and adoption: Address how the project will manage potential resistance to change and build a positive culture around the new way of working.
  
  Your strategy should include elements like: 
• Phased rollout: Using a pilot with a small, enthusiastic team to prove the concept, build success stories, and iron out issues before a full corporate rollout.
• Identifying champions: Recruiting influential and respected members of staff to act as advocates for the new system, helping to build momentum and support their peers.
• Feedback loops: Creating clear channels for users to provide feedback, report issues, and suggest improvements. This makes staff feel heard and part of the solution, rather than having change “done to them.”] 

6. Monitoring and evaluation (benefits realisation)

[This section is critical for accountability and ensuring the project delivers its intended benefits. 

Benefits realisation plan: Explain how you will track the benefits identified in the Economic Case. 

Who is responsible for collecting the data, and when will success be measured (e.g. at project closure, and then 6- and 12-months post-project). 

Monitoring and evaluation data table: Complete a table for your key project objectives. This turns your objectives into a practical monitoring framework.