Role
Project manager
How many times a week do you assemble the project status afresh, asking the same people? If it is several, a good part of the week goes on describing the work rather than running it.
Intro call
Four questions we would start with
How many times a week do you assemble the status?
For the team, for the client, for the board, for a steering committee. Each in a different layout, each from the same data.
Who notices first that a project is starting to slip?
If it is the project manager two weeks after the fact, the risk surfaces as a problem rather than as a risk.
When is the decision to change scope made?
If it is informally, in a conversation, with no record of the effect on the date, then the scope grows and the date stays the same.
What is left after a project once the team disperses?
If it is only the product documentation, the next project will repeat the same mistakes.
We take over assembling the status, you keep running the project
Collecting progress, preparing reports, watching risks and the change register can be taken off the desk. Reading the project's situation and the decisions stay with the manager.
- The status is assembled from the work, not from a survey. - Progress comes from what the team is doing in its tools anyway, and the manager supplies the interpretation.
- Reports for different audiences have one source. - The same state in three layouts, instead of three manual versions that drift apart within a week.
- A change of scope has its effect calculated. - Adding a task shows the effect on the date before the decision is made.
Scope
What can be taken off running a project
Twenty example tasks. Each one has a human approval point. Below is a selection, and the scope we fit to your methodology.
Plan and scope
- The scope set out by stage
- Linking tasks to people and dates
- A signal when a task has no owner
- The dependencies between tasks and what follows from them (assessment: the manager)
Status and reporting
- Progress collected from the tools the team uses
- A draft report in the board's layout (content: the manager)
- A draft report in the client's layout
- A summary of the changes since the previous report
- A signal when a task has shown no progress for longer than agreed
Risks and issues
- A register of project risks with an owner and an action
- A signal when a date is threatened by a dependency
- Pointing out the tasks on the critical path
- Escalating an issue at the agreed thresholds (decision: the manager)
Scope changes
- A register of change requests
- The calculated effect of a change on the date and the effort
- The decision to accept a change, recorded (decision: the sponsor)
- The original scope against the current one
Closing the project
- A comparison of plan with delivery
- A summary of the issues and their causes
- Lessons carried into the next projects (approval: the manager)
A day's work
Today
- You collect the status by asking the team at a meeting and on chat
- You assemble the board report by hand, in a different layout from the client's
- You learn about a delay when somebody reports it
- Scope changes are agreed in conversation, with no calculated effect
- The risks live in a register nobody looks at
- After the project the lessons stay in a few people's memories
With AI assistance
- Progress comes from the tools, not from asking the team
- Reports in different layouts have one source
- A task with no progress reports itself
- A scope change shows the effect on the date before the decision
- A risk with a threatened date is flagged earlier
- The lessons after a project are recorded and available to the next team
- A status you can rely on
the report describes the state rather than Friday's impression
progress comes from the team's work
- Time spent reporting
the manager runs the project instead of describing it
the reports have one source and a drafted text
- Spotting risk early
a delay can be visible before it becomes a problem
no progress and threatened dependencies are flagged
- Knowledge after a project
the next project does not repeat the same mistakes
the lessons are recorded, not remembered
We start with the source of the status, because it decides how much time reporting takes.
- Step 1
Progress from the team's tools
The status assembled from what already exists, instead of from a survey.
- Step 2
Reports in several layouts
One source, different views for the board, the client and the team.
- Step 3
Risks and threat signals
No progress, threatened dependencies, the critical path.
- Step 4
Scope changes and lessons
The calculated effect of a change and the lessons after closing. Last, because it needs a plan you can rely on.
Common questions
Questions that come up at the first meeting
How is this different from a scrum master?
A project manager is accountable to the sponsor for scope, date and budget - and has the authority for it. A scrum master is accountable for the team being able to work, and has no authority over it. Hence the different tools: here a report and a decision on scope, there removing obstacles and conversation. In companies where one person does both, reporting usually wins, because it has a deadline.
What about projects run outside IT?
The mechanics are the same: scope, dependencies, status, changes, closing. What differs is the source of progress - in a construction or a rollout project it comes from somewhere other than a code repository. That is a design question, not an obstacle.
Will running projects need fewer people?
A project is run by decisions, not by reports - and that is work nobody takes away. We take over assembling the status, which is half a week spent describing other people's work. A manager who is not doing that runs the project instead of documenting it. How many projects that covers depends on your portfolio.
Does this fall under the AI Act?
Running projects is not a high-risk use. The line runs at progress data attributed to people: we keep the summaries at the level of tasks and stages, because data on the pace of individual team members' work is already the territory of assessing employees.
Still have a question that is not here? Book a call
Next step
How many hours a week do you spend assembling statuses?
We will show you what running a project looks like when the status comes from the team's work and a scope change has its effect calculated.