Why Projects Need Different Management Approaches

Introduction

A common mistake in project management is assuming that every project should be managed in the same way.

Create a plan. Set milestones. Track actions. Report progress.

That works when the destination is clear and the route is already understood.

It works far less well when the team knows what it wants to achieve but does not yet know how to get there, or when the final result needs to develop through testing, feedback and discussion.

The problem is not always poor project management.

Sometimes the project is being managed as the wrong type of project.

The danger of false certainty

Organisations like certainty.

They want a defined scope, a firm budget, a delivery date and a clear plan before committing money and people.

That is understandable, but it can create pressure to make uncertain work look more predictable than it really is.

A detailed schedule may be produced before the team understands the problem properly.

Costs may be presented as firm when they are still based on assumptions.

Milestones may be agreed even though the delivery route has not yet been tested.

The project then appears to be under control, but the certainty exists only in the documentation.

When reality catches up, the team is blamed for failing to deliver the plan.

In many cases, the deeper problem is that the plan was built around the wrong view of the project from the start.

When the route is known

Some projects are genuinely predictable.

The outcome is clear, the delivery method is established and the team has done similar work before.

A standard equipment replacement, a routine system rollout or a well-understood compliance change may fall into this category.

These projects benefit from traditional project controls.

The scope should be clear. The sequence of work should be understood. Responsibilities, milestones, risks and dependencies should be visible.

The main challenge is disciplined execution.

The team does not need endless workshops or repeated redesign. It needs people to make decisions, complete actions and manage issues before they affect delivery.

In this type of project, too much flexibility can be as damaging as too little control.

When the destination is clear but the route is not

Other projects have a clear objective but no proven route.

The organisation may know that it wants to improve a service, introduce a new technology or reduce the time taken to complete a process.

What it does not yet know is which solution will work.

Trying to create a detailed end-to-end plan at this stage is usually misleading.

The project needs experiments, pilots and short learning cycles.

Progress comes from testing assumptions and eliminating weak options, not simply from completing tasks against a fixed schedule.

This does not mean the work should be unmanaged.

The project still needs clear objectives, spending limits, decision points and accountability.

The difference is that the plan should reflect uncertainty rather than hiding it.

When the outcome needs to develop

Some teams understand the work they need to do, but the final result cannot be defined fully at the beginning.

This is common in website development, training design, communications, events and creative projects.

The team may understand the delivery process, but the final product develops through review and feedback.

The mistake is to demand a finished specification before stakeholders have seen anything.

That often leads to long delays, followed by major changes once the first complete version appears.

A better approach is to make the work visible early.

Show an outline, a prototype or an initial version. Get feedback while changes are still affordable. Agree what is included and what is not.

The project still needs control, particularly around repeated changes.

Stakeholders should be free to shape the outcome, but they should also understand the effect their decisions have on cost, time and quality.

When neither the problem nor the solution is clear

The most uncertain projects start with only a broad concern.

Performance may be poor. Customers may be dissatisfied. Costs may be rising. A senior leader may believe that transformation is needed.

But people may disagree about the real cause of the problem, the desired result and the best way forward.

This is not the point to promise a full solution and a fixed completion date.

The first phase should be discovery.

The team needs to gather evidence, test assumptions, align stakeholders and define the problem properly.

That work can feel slower than immediately launching into delivery, but it often prevents far more expensive mistakes later.

A project cannot be planned properly until there is enough clarity to know what is being planned.

Projects can change type

A project does not necessarily stay in one category.

Work may begin with major uncertainty and gradually become more predictable.

An early discovery phase may clarify the problem.

A pilot may prove the delivery method.

A developing design may eventually be approved and placed under tighter control.

The management approach should change as the project becomes clearer.

That is why project leaders should continue asking whether the current controls still fit the work.

A project that needed experimentation six months ago may now need firmer delivery discipline.

A project that once appeared predictable may need to step back if a key assumption proves wrong.

The method should serve the project, not the other way around.

The No Fluff takeaway

Projects need enough control to protect the investment, but the right control depends on how much is genuinely known.

Use detailed planning when both the outcome and the route are clear.

Use testing and decision points when the route is uncertain.

Use iteration and feedback when the outcome needs to develop.

Use discovery when the problem itself is still unclear.

The mistake is not uncertainty.

The mistake is pretending uncertainty does not exist.