Get control of the project before it controls you

I wouldn't automatically blame the schedule.

The delay may have started much earlier. Maybe the project began without enough planning. Maybe dependencies weren't identified. Maybe resources were assigned to too many things. Maybe decisions took longer than expected. Maybe scope changed without adjusting the schedule.

I start by looking at where the project actually lost time. Once we understand that, we can fix the cause instead of simply moving the deadline again.

I don't determine that just by asking whether tasks are marked complete.

I want to know whether the work that needs to be complete at this point actually is. Are critical milestones on track? Are dependencies progressing? Are risks increasing? Are decisions outstanding? Has the scope changed? Are resources still available?

A project can show a lot of completed tasks and still be heading toward a missed deadline.

Because discussing a problem isn't the same as managing it.

When an issue comes up, I want to know: What needs to happen? Who owns it? When will it happen? Does it affect anything else? When will we follow up?

If those questions aren't answered, the same issue can appear on meeting agendas for weeks. A good meeting should move work forward.

As often as the project actually needs them.

I don't believe every project automatically needs the same weekly meeting. A fast-moving project may need frequent coordination. Another project may function perfectly well with less.

The better question is what decisions, coordination, and information need to happen — and how frequently they need to happen. The meeting should serve the project. The project shouldn't exist to serve the meeting schedule.

If everything is urgent, the team doesn't really have priorities.

When a new priority is introduced, I want management to understand what existing commitment will be affected. The same people can't continuously absorb additional high-priority work without something changing somewhere else.

Good project management makes those tradeoffs visible.

This is where looking at projects individually isn't enough.

One project manager may have a perfectly reasonable plan, while another project has assigned the same employee to something else at exactly the same time.

I want visibility across projects. What resources are shared? Which deadlines compete? Which projects are most important? Where are the conflicts? Sometimes the problem isn't managing individual projects better — it's managing the portfolio of work better.

Every important action needs ownership. Not "the operations team." Not "management." A person.

Then we need a due date, visibility, and a way to follow up.

If tasks repeatedly disappear between departments, I would also look at the handoff process. That's often where responsibility becomes unclear.

A risk is something that could happen. An issue is something that is happening.

If a critical supplier might be late, that's a risk. If the supplier just told us the delivery will be two weeks late, we now have an issue.

The advantage of identifying risks early is that we still have time to decide what we're going to do if they happen.

Start by making the original scope clear.

Then, when someone requests something additional, don't automatically add it to the project. Understand what the change requires. Does it add work? Does it affect the deadline? Does it require additional resources? Does it change cost? Does something else need to be removed?

Changes can absolutely be made. They just shouldn't be treated as if they have no impact.

I don't like starting with a desired completion date and working backward while pretending every activity will fit.

Sometimes there is a fixed deadline, and that's fine. But then we need to determine what would actually be required to meet it — the work, dependencies, available resources, risks, and constraints.

Then management can understand whether the date is realistic and, if it isn't, what would need to change.

Detailed enough to manage the project. Not so detailed that maintaining the schedule becomes a project of its own.

The right level depends on the complexity, risk, duration, and number of people involved.

I want enough detail to understand dependencies, responsibilities, milestones, and progress without creating administrative work that doesn't improve control.

Some administration is necessary. But if the project manager spends so much time maintaining project information that they don't have enough time to actually manage the project, I would look at the process.

Are we entering the same information several times? Are reports being created manually? Are stakeholders requesting different versions of the same information? Can anything be simplified or automated?

Project managers should spend their time managing risks, decisions, people, dependencies, and outcomes — not copying information between spreadsheets.

It depends on the work.

I have experience with Agile, Scrum, and more traditional project-management approaches, but I don't believe in forcing every project into one methodology. Some projects need a highly structured sequence. Others need more flexibility and iteration. Some organizations benefit from combining elements of different approaches.

The question isn't which methodology sounds best. It's which approach helps this team successfully deliver this project.

Start by reducing reporting to the information management actually uses.

What decisions does leadership need to make? What problems need early visibility? Which milestones matter? Which risks deserve attention? Then build reporting around those questions.

Management shouldn't have to read thirty pages to discover that one important decision is holding up the entire project.

First, stop managing against a plan everyone knows is no longer realistic.

I want to understand where the project actually stands today. What's complete? What's incomplete? What's blocking progress? Which commitments still matter? What resources are available? What decisions are outstanding?

Then we can determine what can realistically be recovered, what needs to change, and what the new priorities should be. The objective isn't to make the old schedule look better — it's to regain control of the project.

Before adding another position, I would look at why the existing team is overwhelmed.

Is there actually too much project work? Or are project managers spending large amounts of time on administrative tasks? Are priorities constantly changing? Are processes inefficient? Are responsibilities unclear? Are too many projects being launched at once?

Another project manager may absolutely be necessary. But first I want to make sure we're solving a capacity problem rather than adding another person to an inefficient system.

Yes, particularly with some administrative and information-heavy work.

AI and automation may be useful for organizing information, summarizing updates, supporting reporting, working with documentation, or reducing other repetitive tasks.

But I wouldn't use AI to replace project judgment. A project manager still needs to understand people, risks, priorities, tradeoffs, and decisions. I see AI as a way to potentially give project managers more time to do that work.

Because good people can't compensate indefinitely for a bad system.

You can have experienced employees working extremely hard and still have projects struggle because priorities aren't clear, resources are overallocated, decisions are slow, processes are inconsistent, or management doesn't have enough visibility.

When the same problems happen across multiple projects with different people, I start looking at how the organization manages projects.

That depends on what the business needs.

Some organizations need direct project-management support for a specific initiative. Others already have capable project managers but need better planning, processes, controls, reporting, or project-management structure. And sometimes a project is already in trouble and management needs someone to help determine what is happening and build a recovery plan.

The engagement should address the actual problem rather than forcing every client into the same service.

I start by understanding what you're trying to accomplish and where the project stands today.

If the project hasn't started, we can focus on establishing the right structure from the beginning. If it's already underway, I want to understand what's working, what's slipping, and what's creating problems. And if it's already in trouble, we start with reality rather than the original plan.

From there, we establish the appropriate scope, schedule, responsibilities, risks, resources, reporting, and controls — then use those tools to manage the project. The objective isn't to create project-management paperwork. It's to give the team and management enough structure and visibility to make decisions, solve problems, and get the project delivered.