01 / Simply explained
What is decision management in a project?
Almost every project involves decisions. Some are routine and can be made within the project team. Others concern budgets, resources, technical solutions, organisational changes or approval to move into an important project phase.
Decision management is the structured process of identifying, preparing, documenting and following up on decisions.
The aim is not to record as many decisions as possible. It is to make sure important questions reach the right decision-makers in time.
Four questions matter in particular:
- What needs to be decided?
- Who has the authority or responsibility to decide?
- By when is the decision needed?
- What happens if the decision is delayed?
Effective decision management creates transparency, clear responsibilities and a reliable basis for project planning.
02 / Why does it matter?
When technology isn't what holds the project back
IT projects spend considerable time solving technical problems, aligning requirements and coordinating tasks.
But technology is not always the biggest challenge.
Sometimes a solution has already been developed and tested. The team has completed its work, resources are available and the next milestone is ready.
Yet the project cannot move forward.
The reason? A decision is still pending.
Perhaps management must approve a budget. Perhaps the project needs organisational sign-off. Or several departments have yet to agree on a way forward.
Until that decision is made, dependent activities may be unable to start.
A pending decision can quickly turn into a schedule risk.
It becomes especially difficult when decision-making responsibility is unclear, or when the topic has only been raised verbally in a meeting.
Without transparent documentation and follow-up, important decisions can easily get lost in day-to-day project work.
03 / A practical example
The solution is ready. The rollout still has to wait.
Consider this scenario:
A company plans to introduce a new application for its employees.
The project team has completed the technical preparations. The application has been tested, the infrastructure is ready and the training materials have been prepared.
From a technical perspective, the rollout could begin.
However, organisational approval is still outstanding. Several stakeholders need to agree on the proposed approach.
While those discussions continue, the team cannot carry out the next steps as planned.
Crucially, the need for a decision has not gone unnoticed.
The project manager and PMO identified the required decisions early on, clarified who had decision-making authority and established when each approval was needed.
They also documented and regularly communicated the potential impact on the project schedule, resources and dependent activities.
Even so, the decision remains pending.
Planned rollout dates may need to change, and resources may have to be rescheduled.
The project team cannot make the decision itself because the authority rests with other responsible parties or committees.
What does this example tell us?
Decision management does not guarantee that every decision will be made on time.
Even when the decision is clearly defined, responsibilities are established and the consequences of delay are transparent, the necessary discussions and approvals can take time.
The role of project governance is therefore not to force decisions at any cost, but to prepare them as effectively as possible and manage their impact on the project.
Structured decision management helps ensure that:
- Decision needs are identified early and documented clearly.
- Responsibilities, target dates and dependencies are known.
- Risks and potential consequences are communicated transparently.
- Plans and resources can be adjusted in good time when needed.
This gives the team a sound basis for decision-making and allows it to keep working within its own area of responsibility, even while approvals remain outstanding.
This is a generalised project scenario and contains no confidential client information.
04 / How to put decision management into practice
Step 1: Identify the need for a decision early
Not every open topic is a decision.
Sometimes information is missing, a task remains unfinished or a technical question needs answering.
A genuine decision is required when someone must choose between options or grant binding approval—especially where the project team does not have the authority to resolve the matter itself.
Examples include approving additional project funding, choosing between two solution approaches or signing off on a revised rollout strategy.
Step 2: State the decision clearly
Describe exactly what needs to be decided.
A vague entry such as:
“Alignment with the business department required.”
is less useful than:
“The business department must decide whether to launch at two pilot sites first or at all sites immediately.”
A well-written decision request makes the question and available options clear.
Where possible, the team should also provide a reasoned recommendation.
Step 3: Assign decision-makers and deadlines
Each important decision needs a named decision-maker or an authorised committee.
It also needs a date by which the decision is required.
That date should be based on actual project dependencies, not chosen arbitrarily.
If an approval is needed two weeks before a rollout, that relationship should be visible in the schedule.
It helps to distinguish between the target decision date and the latest date at which the decision can be made without affecting the project plan.
Step 4: Make the impact visible
A pending decision is a fact; its potential consequences may be significant.
Record what will happen if it is not made in time.
Possible effects include schedule changes, additional costs, resource shortages or delays to dependent work packages.
Keep the description factual.
Instead of:
“Urgent decision required!”
write something more specific:
“Without approval by 15 November, the pilot phase scheduled for 1 December cannot begin as planned.”
That turns a general warning into a concrete basis for decision-making.
Step 5: Follow up actively
Decision management does not end when an item is added to a spreadsheet.
Open decisions need regular review—for example, during a weekly project status meeting or a dedicated coordination meeting.
The project manager or PMO should identify possible missed deadlines early.
If a decision is not forthcoming, it should be escalated through the agreed route to the responsible committee or higher decision-making level in good time.
Escalation is not about assigning blame. It is about getting an issue addressed where the necessary authority exists.
Step 6: Document and communicate the outcome
Once a decision has been made, record the outcome.
At a minimum, capture what was decided, the date, the responsible person or committee, and any consequences for the project.
Then inform the relevant stakeholders and incorporate the resulting actions into the project plan.
After all, a decision only creates value when it is put into practice.
05 / From the project toolkit
A decision log doesn't have to be complicated
Most projects do not need an elaborate system.
A simple, centrally maintained register is often enough.
| ID | Decision required | Decision-maker | Required by | Status |
|---|---|---|---|---|
| DEC-001 | Approve the pilot phase | Steering committee | 15 Nov | Open |
| DEC-002 | Select the software solution | Project manager | 8 Nov | Decided |
| DEC-003 | Approve additional testing resources | Department head | 20 Nov | Under review |
A more detailed register can include the options, consequences of a delay, recommendations and the actual decision.
What matters is not the number of columns but keeping the information up to date.
A simple register that is actively maintained is usually more useful than extensive documentation nobody uses.
Decision log or risk register?
These tools complement each other, but they serve different purposes.
A decision log records which decisions are needed, who owns them and their current status.
A risk register records uncertain future events that could affect project objectives.
A pending decision may also create a project risk.
For example, a required approval may appear in the decision log, while the possibility of a delayed rollout is recorded as a risk.
If that delay has already occurred, it is no longer just a risk—it is an actual issue.
Link the related entries so that the same situation is not managed independently in several places.
06 / Common pitfalls
A few problems appear repeatedly in decision management.
Unclear questions: If it is not obvious what needs to be decided, discussions and clarification take longer.
Unclear decision ownership: If several people are involved but nobody has explicit authority, an issue can remain open unnecessarily.
Unrealistic deadlines: A decision made on the day a project phase is due to begin may be too late.
Unclear consequences: Without a visible impact, a decision may not receive the attention it needs.
No follow-up: Even a sound decision achieves little if the resulting actions are not implemented.
Good decision management covers not only the decision itself but also its preparation, follow-up and implementation.
07 / Take-away
Decisions are a core part of project governance.
Not every delay is caused by a lack of resources, technical problems or poor planning.
Sometimes a decision is simply still outstanding.
Structured decision management makes those dependencies visible early.
We can't control every decision. But we can control how we prepare for it, follow it up and manage its impact.
A clear decision question, explicit ownership, realistic deadlines and transparent consequences can make a significant difference.
08 / Practical template
Decision Log
Use a decision log to document pending and completed project decisions in a structured way.
The matching Excel template covers the decision required, available options, ownership, deadlines, status, outcome and follow-up actions.
Template: Decision Log (.xlsx)
Related topics: Risk Management · Stakeholder Management · Project Status Reporting