Two dates, two meanings
A milestone records the original commitment. An issue has its own resolution target. Moving the latter must not hide the former.
Project Control / Internal business system
PROJECT CONTROLKeep the whole project portfolio in view.
For project managers and project offices, the overview is only the start. Project Control lets you review programmes, portfolio leads and departments, then follow a project into its workstreams, finances, issues and supporting records.
PROJECT CONTROL / Home screen17.10.2026
Enlarge the screen The screens use an isolated example dataset. Northbank School, the people and the documents illustrate the real system’s behaviour.
- Purpose
- Project monitoring, approvals and reporting within a project office.
- Working environment
- A multi-project environment: programmes, portfolio leads and departments, with project, workstream and asset detail.
- Scope of the work
- Needs and requirements, architecture, data model, business rules, implementation oversight, integration and verification.
The working need
An overview you can investigate.
The same portfolio can be reviewed by programme, by the person responsible for it or by department. Each view leads to the projects and their workstreams, assets, financial records and issues. Documents and reports make the basis of a status or a total available for review.
The question behind the overview
In a project review, the portfolio overview should lead to a useful decision: which project needs attention, who should act, and which records support the next step? Linked records make that path visible.
One workflow / An example in detail
Follow the facade approval at Northbank School.
The E1 example follows an outstanding facade sample approval from the project overview to its milestone, linked issue and review document. The issue remains open in this recorded state; a recovery date is not a completed approval.
A guided process walkthrough using actual English interface captures and an isolated example dataset recorded in October 2026. Switch steps and enlarge the screens to inspect the evidence; this is not a live application session.
- 01ProjectProject leadE1 / Northbank School
- 02CommitmentProject coordinator12.10.2026
- 03ResponsibilityIssue coordinator and responsible authorityEmma Reed
- 04Resolution planCoordinator and responsible authority22.10.2026
- 05JournalContributor and coordinator14.10.2026
- 06DocumentProject reviewer15.10.2026
Project lead
Start with the project, then investigate.
- The question
- Which work belongs to this project?
- In the system
- The workstreams view is open for Northbank School, code E1. Review the structure and limestone envelope workstream alongside the teaching fit-out and building services.
- What becomes clear
- The project code and workstream names keep the review anchored to E1. Budgets and payments provide financial context; they do not measure physical completion.
Who acts nextThe project lead follows the outstanding commitment with its coordinator.
Project coordinator
Keep the original commitment visible.
- The question
- What was due, and when?
- In the system
- Open the milestone “Facade sample approval”. Its original deadline is 12 October 2026. Follow the link to the related issue.
- What becomes clear
- The original obligation remains identifiable even when resolving the delay requires a new plan.
Who acts nextThe linked issue carries the discussion of how to resolve the outstanding approval.
Issue coordinator and responsible authority
Make responsibility explicit.
- The question
- Who coordinates the issue, and which organisation is responsible?
- In the system
- Read the linked issue in the E1 project context: Emma Reed is the coordinator and Engineering & Infrastructure is the responsible authority.
- What becomes clear
- People can identify whom to continue the work with. The record distinguishes coordination from organisational responsibility.
Who acts nextThe coordinator and responsible authority work from the same issue record.
Coordinator and responsible authority
Plan the resolution without rewriting the past.
- The question
- What is the resolution target now?
- In the system
- Review the issue’s planned closure date of 22 October 2026 alongside the milestone’s original 12 October deadline.
- What becomes clear
- The recovery plan and the original commitment answer different questions. In this recorded state the issue is still open and under control, not completed.
Who acts nextThe responsible party can record the next substantive update against this plan.
Enlarge the screen Commitment12.10.2026Resolution plan22.10.2026
Contributor and coordinator
Read what changed in its context.
- The question
- What has been recorded, and where is its supporting material?
- In the system
- Expand the journal entry dated 14 October 2026 and inspect the attached “E1 - Facade sample approval - review record.docx”.
- What becomes clear
- The update, its date and its attachment can be reviewed together instead of treating a status label as the whole explanation.
Who acts nextThe coordinator opens the document to examine what it actually supports.
Project reviewer
Check the document before drawing a conclusion.
- The question
- What does the attached record establish?
- In the system
- Open the review record for E1. Its review date is 15 October 2026; the journal entry is dated 14 October. These are separate dates.
- What becomes clear
- A reviewer can check the documentary basis without mistaking a planned closure date or an attachment for a completed approval.
Who acts nextThe next decision remains with the people responsible; the system keeps its context and evidence accessible.
Enlarge the screen Download the review record ↓ DOCX · 37 KB
Example DOCX from the prepared dataset. It supports the walkthrough; it is not an organisation’s working document.
The handover stays connected.
The rules that make the detail useful.
Choose a point in the process to see the related screen. People decide and take responsibility; the system connects the records needed to do so.
A shared topic, distinct responsibilities
An issue theme can span projects while each project keeps its own responsible parties, status and dates. A common discussion does not erase local accountability.
Evidence beside the update
Journal entries and documents remain in the context of the working record, so the next reviewer can inspect the basis of an update.
Numbers with a traceable basis
Project indicators and reports can be checked against their underlying records. Physical progress, annual results, commitments and financial execution retain their separate meanings.
A shared topic, distinct responsibilities
An issue theme can span projects while each project keeps its own responsible parties, status and dates. A common discussion does not erase local accountability.
Enlarge the screen Check a report against its source records
The same Northbank School example also shows how financial totals can be checked. The Structure and limestone envelope workstream has an allocated budget of 11,275 in EUR thousand. In the report, its two construction assets each show 5,637.5: together, the same allocation. Committed budget and cash expenditure are separate columns. Rounded report values are not exact source amounts.
Enlarge the screen 
Enlarge the screen From need to use
From a working need to a connected system.
Requirements, data structures and day-to-day workflows were developed together. The system was introduced into project-office work and refined as new requirements emerged.
- 01
Understand the work
Define the questions people need to answer, the responsibilities involved and the records required for project reviews.
- 02
Model the connections
Design requirements, architecture, the data model and business rules connecting projects, milestones, issues and documents.
- 03
Lead the implementation
Guide implementation, integrate the parts and review whether the resulting behaviour meets the working requirements.
- 04
Introduce and refine
Bring the system into internal use, verify results and continue making improvements as the work develops.
PROJECT CONTROL
What this case demonstrates.
A working internal system, with connected records that support project reviews.
- An internal project-office system taken from requirements into use.
- A commitment can be followed through responsibility, a separate resolution plan and supporting records.
- The original deadline remains visible while the issue’s resolution is managed separately.
Technical context
The implementation uses React and TypeScript, Django and Django REST Framework, PostgreSQL, and an integration boundary with Microsoft SQL Server. The isolated portfolio profile uses PostgreSQL and example data.
- One connected model
- Projects, workstreams, milestones, issues and documents are related records, rather than independent presentation screens.
- Decisions stay with the team
- The system brings records and responsibilities together to support review. The people responsible decide how to respond and which actions to take.
- A separate presentation boundary
- This walkthrough uses prepared captures and example documents. It does not connect the portfolio website to the organisation’s working data.
Example DOCX from the prepared dataset. It supports the walkthrough; it is not an organisation’s working document.
Download the review record ↓For your organisation
What should your next project review make clear?
Tell us where work becomes difficult to follow: monitoring, approvals, responsibility or reporting. Start with one recurring process and the decision people need to make.
Discuss a similar system