Is Project Management Is All About Status Reporting and Minutes of Meeting ??

Somewhere along the way, we may have confused the visible outputs of project management with the work of project management itself.

There is a joke I have heard in different forms over the years.

“What does a project manager actually do?”

“They attend meetings, prepare status reports and write minutes.”

It gets a laugh because there is some truth behind it.

A surprising amount of a project manager’s working week can be spent preparing status reports, updating project plans, chasing people for information, maintaining RAID logs, organising governance meetings and documenting what was discussed.

And then there are the dashboards. Green, amber, red.

Milestones. Actions. Dependencies. Issues. Risks. Percent complete.

Sometimes it feels as though a project manager’s primary responsibility is to make sure that everyone knows what is happening on a project.

There is nothing wrong with any of this.

Status reporting matters. Meetings matter. Minutes matter. Project plans matter. Governance packs matter. They are all useful tools.

But somewhere along the way, I think we may have confused the outputs of project management with project management itself.

A project manager can produce an excellent status report and still fail to manage the project.

A project can have beautifully documented meetings and still be drifting.

A dashboard can be completely green while some of the assumptions underneath the project have already changed.

And a project manager can spend an entire week being extremely busy without actually moving the project forward.

That raises a more interesting question – If project management is not primarily about producing reports and running meetings, what is it actually about?

The more I look at projects, particularly complex programmes involving multiple functions, teams, vendors and stakeholders, the more I think the real power of project management is much simpler, and rather completely misunderstood and underutilized.

Project management creates movement. It takes an objective that exists at one level of an organisation and creates the conditions for people, decisions, resources and activities to move together towards it.

The reports and meetings are part of that system. They are not the system itself.

When the report becomes the work

Let’s take the weekly status report.

It is probably one of the most recognisable artefacts of project management. Every week, someone asks:

“Can you send me the latest status?”

The project manager collects updates from different workstreams, checks milestones, updates risks and issues, refreshes the dashboard, chases people for missing information and eventually produces a document that tells everyone whether the project is green, amber or red.

There is value in that.

Without a common view of progress, projects quickly become fragmented. But the purpose of the status report is not to produce a document. Its purpose is to create visibility that enables management action.

If a report tells us that a milestone is two weeks late, but nobody knows why, the report has described the problem without managing it.

If it tells us that a critical dependency is at risk, but there is no decision on how to address it, the information has been captured but nothing has moved.

If every workstream reports green because its individual activities are progressing, while the combined outcome is becoming less likely, the dashboard may be technically accurate and still give a misleading picture of reality.

The status report is useful when it helps people understand:

What has changed?
What matters?
What is becoming a problem?
What decision is required?
Who needs to act?

The same applies to minutes of meeting. A good set of minutes is not a transcript. It is not a record of who said what for the sake of keeping everyone busy.

The value of meeting minutes is that they capture the decisions, commitments, actions and unresolved questions that allow the project to move forward.

The document is not the outcome. Movement is the outcome.

Project management begins where individual responsibility ends

Imagine a project involving Technology, Finance, Operations, Sales, Marketing and an external vendor.

Everyone has their own job.
Everyone has their own manager.
Everyone has their own targets.
Everyone is probably busy.

And yet the project needs all of them to work together.

The Technology team cannot complete something because it is waiting for Finance.
Finance cannot make the decision because Operations has not provided the numbers.
Operations is waiting for the vendor.
The vendor is waiting for a specification.
The specification is dependent on a business decision that nobody has formally made.

Now ask yourself: Who manages that system?

This is where project management comes in. The project manager starts connecting the pieces. Not because the project manager necessarily has authority over these people.

Often they don’t !

The project manager may not manage the technology lead. They may not manage the finance lead. They may not manage the vendor. They may not control the budget. They may not even have the authority to make the decisions that are holding the project up.

And yet they are expected to make the project move. To ensure everyone on the boat is rowing in same direction.

Project management often operates through influence rather than hierarchy.

The project manager creates visibility around commitments.
They make dependencies explicit.
They surface conflicts.
They bring unresolved issues into the right forum.
They connect people who otherwise have little reason to coordinate.
They make decisions visible.
They escalate when necessary.
They create a rhythm in which people know what has been agreed, what is expected and what happens next.

That is much more than administration. It is a form of organisational coordination.

The project manager creates a shared reality

One of the biggest challenges in any project is that different people can be looking at the same project and seeing completely different things.

The sponsor might be thinking about the strategic outcome.
The CFO might be thinking about investment and financial return.
The technology team might be thinking about architecture.
Operations might be thinking about disruption.
The vendor might be thinking about contractual deliverables.
The business team might be thinking about adoption.

All of them can be correct from their own perspective.

The problem is that the project has to operate as one system. Someone has to create a shared understanding of where things actually stand. This is one reason project reporting matters.

But again, the real work is not preparing the report. The real work is understanding what is happening across the project and helping people see the connections.

A strong project manager can look at five apparently unrelated updates and recognise that they are actually connected.

A delay in one workstream may create a resource problem somewhere else.
A change in scope may create a testing dependency.
A vendor issue may threaten a business milestone.
A decision that appears tactical may have consequences for the overall timeline.

The project manager becomes the person who sees the whole system, rather than only one part of it.

Project management turns ambiguity into action

Most projects do not begin with perfect clarity. Even projects with well-written business cases contain ambiguity.

“We want to improve customer experience.”

“We want to launch in a new market.”

“We want to transform the operating model.”

“We want to implement a new technology platform.”

“We want to reduce cost.”

These are intentions. They are not yet projects.

Someone has to translate that intention into something that people can act upon.

What exactly are we trying to achieve?
What needs to happen?
What does success look like?
What has to happen first?
What can happen in parallel?
Who needs to be involved?
What decisions are required?
What assumptions are we making?
What constraints exist?
What could prevent us from achieving the objective?

This is where project management starts converting intent into action.

Dependencies are where much of the real work happens

One of the things I have increasingly appreciated about project management is how much of the profession is really about managing dependencies.

A task in isolation is rarely complicated.

Task A needs to happen. Then Task B happens. Then Task C.

The difficulty appears when A depends on B, B depends on C, C depends on an external vendor and the vendor depends on a decision from someone who is not even part of the project team.

Now the project has become a system. And systems behave differently from individual tasks. A project manager spends a great deal of time asking questions that can sound deceptively simple:

“What are you waiting for?”

“Who are you waiting for?”

“What does that person need from you?”

“What happens if we don’t get it this week?”

“What decision is preventing this from moving?”

“Who can make that decision?”

These questions may never appear in the final project report. But, the project manager is continuously trying to reduce the friction between interconnected pieces of work. That is why a project can have highly capable people and still struggle.

The problem may not be capability. It may be coordination.

Project management creates accountability

There is another force that is easy to underestimate.

Accountability.

Not the uncomfortable version where the project manager chases people for overdue actions every Friday afternoon.

Something more useful. Projects create commitments.

Someone agrees to deliver something by a particular date. Someone agrees to make a decision. Someone agrees to provide information. Someone agrees to resolve an issue.

Those commitments become part of a shared system. And once they are visible, they become easier to manage. This is one reason minutes of meeting can be powerful when used properly.

A good meeting ends with clarity:

What did we decide?
What happens next?
Who owns it?
By when?
What happens if that doesn’t happen?

That is accountability.

When project management degenerates into administration, the project manager becomes the person who sends reminders. When project management works well, the project manager creates an environment where commitments naturally become part of how the project operates.

Project management forces decisions

Perhaps one of the most important things project management does is make it increasingly difficult for unresolved decisions to remain invisible. Projects generate decisions constantly.

Should we change scope?
Should we accept the additional cost?
Should we proceed with the current design?
Should we delay the launch?
Should we take the risk?
Should we add resources?
Should we stop an activity that is no longer producing the expected result?

These decisions often sit outside the formal authority of the project manager. But the project manager can make the need for the decision visible.

This is why simply reporting: “Decision pending” is not enough. The project manager’s real contribution may be helping the organisation understand:

what decision is required
why it matters
what happens if we delay it
what options exist
what information is available
what recommendation the team is making
who has the authority to decide

A project can absorb a surprising amount of operational difficulty. What it struggles with is prolonged ambiguity.

An unresolved decision creates uncertainty downstream.
That uncertainty creates waiting.
Waiting creates delay.
Delay creates pressure.
Pressure creates more decisions.

Good project management helps shorten that chain.

Project management creates rhythm

There is another less visible contribution. Projects need rhythm.

Without it, work becomes episodic. People make progress when they have time. Issues are discussed when someone remembers them. Decisions happen when the right people happen to be available. Dependencies are discovered when they become urgent.

A project management system creates a recurring rhythm: Commit, Act, Review, Decide, Adjust, Act again.

The weekly meeting is part of that rhythm. The status report is part of that rhythm. The plan is part of that rhythm. The governance meeting is part of that rhythm. The RAID log is part of that rhythm.

None of them is the project management system by itself. Together, when used properly, they create a heartbeat for the project. That heartbeat matters because projects exist alongside the normal organisation.

The business has its own priorities.

People have their own functional responsibilities.

Customers have their own demands.

Unexpected events keep appearing.

The project needs a mechanism that keeps bringing attention back to the work that has to happen.

That is one of the quiet powers of project management.

And then there is focus

Projects have a strange tendency to grow.

A stakeholder wants one more feature. Another team wants another requirement. Someone sees an opportunity. Someone else says, “While we’re doing this, could we also…”

Before long, the project has become something considerably larger than what anyone originally intended.

Project management provides a mechanism for asking a simple question: Is this still part of what we are trying to achieve?

This question is not always comfortable.

Sometimes the answer is yes. Sometimes it is no. Sometimes the answer is “not now.”

But someone has to protect the relationship between the work being done and the reason the work exists. This is why scope management is not simply about preventing scope creep.

It is about protecting focus.

What happens when the machinery becomes more important than the outcome?

The profession needs to be honest with itself. We have become very good at creating project machinery.

There are methodologies, Templates, Dashboards, PMO standards, Governance structures, Stage gates, RAG reports, RAID logs, Project plans, Steering committees, Lessons-learned registers.

All of these have value.

But there is a danger when the machinery starts becoming an end in itself.

A project can become very mature administratively while becoming increasingly ineffective operationally. We can spend hours discussing whether something is amber or red without discussing what needs to change.

We can spend half an hour reviewing an action tracker without asking whether the actions themselves are still the right actions.

We can produce increasingly detailed plans for a future that has already changed.

We can hold governance meetings where everyone receives the same information they already had before the meeting. And, we can become very efficient at reporting that the project is not moving.

That is when project management loses its purpose. The question should always come back to: What is this activity helping us do?

If the answer is “because that’s what the process requires”, perhaps we should look again.

Good project management is often invisible

When project management works really well, much of it is invisible.

A dependency gets resolved before it becomes a problem.
A decision is escalated before it starts affecting the schedule.
Two teams align before their priorities conflict.
A stakeholder concern is addressed before it becomes resistance.
A risk is identified early enough for the team to respond.
A plan is changed before reality forces the change upon us.
A meeting ends with the right decision. People know what they are expected to do. The project keeps moving.

Nobody necessarily says: “Excellent project management happened here.”

And perhaps that’s the point.

The project manager is not supposed to be the hero of the project. The projeb ct manager’s job is to create the conditions in which the project can succeed.

The best project management must be almost invisible.

Perhaps we need to change how we think about the profession

Project management is sometimes described as a discipline of planning, organising and controlling work. Those words are technically correct.

But after years of working around projects, I think there is another way to look at it. Project management is a discipline of collective movement.

It brings together people who have different responsibilities.
It connects activities that depend on each other.
It makes commitments visible.
It creates a rhythm of action.
It brings unresolved issues into the open.
It creates pressure for decisions.
It manages change.
It protects focus.
And, it keeps asking whether the work being done is still taking the project where it needs to go.

That is quite a powerful role. And, much of it happens without formal authority.

The project manager is often the person sitting in the middle of a complex system, trying to make sure that all the pieces continue moving in the same direction.

The project manager is not the person who just reports what happened

That is the distinction I would leave with. A project manager is not primarily the person who tells everyone what happened.

A project manager helps create the conditions for what needs to happen next.

There is a subtle but important difference.

One looks backwards. The other looks forward.

One records. The other manages.

One describes movement. The other creates movement.

And perhaps this is why I have become increasingly uncomfortable with the casual description of project management as “status reporting and meeting management.”

It undersells the profession. It makes project management look administrative when much of its real value is organisational. It reduces a discipline built around coordination, decision-making, accountability, prioritisation and controlled movement to the artefacts it produces.

The project has to move.

And that, ultimately, is what project management is there to do.

Status reporting tells us what is happening.
Governance tells us what needs to be decided.
Project management connects the two. Turning information into decisions, decisions into action, and action into progress.

Nishant Pathak