Project Management System

Most project status is assembled by asking people. A manager sends a request, everyone replies with a version of events, and by the time the answers are collated the picture describes a moment that has already passed. The delay is not the problem; the fact that it is only ever a snapshot is.

Project Management System keeps the work, the people and the dates in one record as the work happens. Progress is recorded when something is done or changes, so the state of a project can be read from the system rather than collected from everyone who owns a piece of it.

It is deliberately unglamorous software. Its value shows up in the questions it makes unnecessary — what is overdue, what is waiting on an approval, what has changed since last week, and what this project cost in effort compared with what it was estimated at.

One record per projectProgress recorded as it happensApprovals with a trailEstimates against actuals

What it is

• One record per project. Scope, tasks, owners, dates, dependencies and decisions are held together, so the project can be read without assembling anything.

• Progress recorded when it happens. Updates are entered as work is done or a change is agreed, not collected at reporting time.

• Tasks with owners and dates. Each task has one accountable owner, and the system shows what is overdue rather than relying on someone to notice.

• Milestones that mean something. A milestone is a point that has to be reached and can be checked, with the evidence attached, rather than a date on a slide.

• Approvals with a trail. An approval request carries what it is for, who it is going to, what was decided and when — so a decision can be found later.

• Estimates against actuals. Planned effort and planned dates are kept next to what actually happened, which is the only way the next estimate improves.

What gets in the way today

Progress is asked for, not recorded. The status meeting is the reporting system.

• Nobody updates anything between meetings. So the record is out of date the moment it is collected.

• The people closest to the work spend time writing about it instead of doing it. Which is the part they are least willing to keep doing.

• Late notice is the normal case. Because the signal arrives after the date it could have helped with.

Approvals live in inboxes. A decision exists, but not where anyone can find it.

• An approval is a message, a mail thread or a form that went somewhere. Which means the decision is found by asking whoever was there.

• Nobody can say what was approved, in what version, on what date. Which is exactly what an audit or a dispute asks for.

• Approval blocks work, and the block is invisible. So the delay is discovered when someone chases it.

Scope changes quietly. The project is never the one that was agreed.

• Small additions are agreed in conversation. So the cost and the date never move, and the shortfall appears at the end.

• Nobody keeps the decisions. So two people remember the scope differently, and both are confident.

• The original plan is overwritten. So there is no record of what was originally agreed.

Nothing carries over. Every project starts from zero.

• Lessons from a finished project stay with whoever learned them. So the next project repeats what the last one solved.

• Actual effort is never compared with the estimate. Which is why estimates stay optimistic for years.

What the platform covers

The map below is the platform's functional coverage in one view: the boards and dashboards on top, portfolio, project and team work in the middle, product and requirement work alongside commercial work, templates, knowledge and metrics beneath that, and system management with the platform engines at the base. Each area is a set of applications rather than a single screen, and one organisation and permission model runs across all of them.

What counts as done is defined for the project rather than assumed. A task is closed against the evidence attached to it, and a milestone against what was agreed to be true at that point. Where a change alters the scope, it is recorded as a change with its reason, leaving the original agreement intact and visible rather than overwritten.

What you get

Where it is used

What changes between these settings is how many projects run at once, and how much of the work depends on people outside the team.

Capabilities

Grouped by what they do.

How it works

1. Agree the scope. What is in, what is out, and what will count as done — recorded before the work starts.

2. Plan it. Tasks with owners and dates, milestones with the evidence each will need, and the dependencies between them.

3. Work and record. Progress is entered as it happens, and changes are recorded as decisions rather than edits.

4. Check at the milestones. Evidence attached and the point either passed or recorded as not met, with the reason.

5. Route the approvals. Decisions requested with their purpose, tracked while waiting, and stored with the date.

6. Close and carry over. Outcome recorded against actual effort, and what was learned goes into the next project.

Boundaries and what it does not decide

• It records, it does not manage people. Effort and ownership are recorded so the state of the work can be read. Who is assigned to what remains a decision for the organisation.

• Plans are plans. Keeping a task list does not make a date achievable. What the system does is make the slip visible while something can still be done about it.

• It does not replace the engineering or the work. It carries the plan, the evidence and the decisions around the work, and stays out of the work itself.

• Where it runs. In the cloud or on your own servers, decided by where project and customer data may be processed and stored.

• What is local. Retention, access to commercial information and any sector duties depend on the jurisdiction and the site's own policy.