When politeness becomes a project risk: the hidden cost of mitigated speech

lorenaflorian0
Jul 1
6 min read

Projects rarely fail because nobody saw the warning signs, more often the warning signs were present but were not expressed clearly enough, heard seriously enough, or acted on early enough.

A team member says, “There may be a slight issue with the timeline.”

What they may really mean is: “The critical path has slipped, the recovery plan is not credible, and we will miss the milestone unless a decision is made this week.”

Someone says, “We may need to revisit the scope.”

What they may really mean is: “The scope is expanding without approved funding, capacity or time, and the project is no longer deliverable within its baseline.”

Sound familiar? This is mitigated speech, which is language that softens, qualifies or downplays the real meaning of a concern.

It is often well intentioned. People may be trying to be polite, avoid conflict, respect hierarchy or protect relationships. But in projects, programs and transformations, excessive mitigation can obscure the truth at precisely the point leaders need clarity.

The danger is not polite language. It is unclear language.

Professionalism does not require bluntness for its own sake. Good leaders should not create an environment where people communicate aggressively, dismissively or without regard for others.

However, there is a meaningful difference between respectful communication and ambiguous communication.

Respectful communication says:

“The current schedule is no longer achievable without reducing scope, increasing capacity or moving the go-live date. We need a sponsor decision by Friday.”

Ambiguous communication says:

“There may be some pressure on the timeline.”

The first statement creates a clear understanding of the issue, its consequence and the required action. The second may leave the listener believing that the team simply needs to work harder.

In complex environments, ambiguity creates risk. It delays escalation, weakens governance and allows optimism to replace evidence.

Why mitigated speech appears in project environments

Mitigated speech is particularly common where there is a steep authority gradient.

A project manager may hesitate to challenge a senior sponsor. A delivery lead may soften bad news when speaking to an executive. A vendor may avoid being explicit about a dependency failure for fear of damaging the commercial relationship. A junior analyst may see a flaw in the data but remain quiet because everyone else in the room appears confident.

The issue is not hierarchy itself. Projects need clear accountability, delegated authority and timely decisions. The problem arises when hierarchy makes people feel that raising concerns is personally risky i.e. the psychological safety is missing.

This is particularly dangerous when a project has already invested significant money, effort and reputation. As pressure grows, people may become more cautious about delivering unwelcome news. Status reports become carefully worded. Risks are described as “being monitored”. Milestones remain green despite unresolved dependencies. The language becomes softer while the problem becomes harder.

This contributes to the watermelon effect described in a previous blog and to reinforce the principle – bad news does not get better over time!

The project consequences of unclear escalation

When leaders are not clear, teams may mistake reassurance for direction. When teams are not clear, leaders may mistake silence for confidence. The consequences can be significant.

Risks remain visible but unmanaged

A risk register can show that a risk exists without making clear whether it requires intervention. Phrases such as “ongoing engagement”, “continued monitoring” or “work is underway” may sound positive, but they do not demonstrate that the risk has an owner, treatment plan, due date, contingency or escalation threshold.

A meaningful risk discussion should answer:

What could happen?
How likely is it?
What would the impact be?
What action is required?
Who owns that action?
By when must the decision or treatment occur?
What happens if the action does not work?

Decision-making is delayed

Mitigated speech often hides the decision that is actually required.

For example, “We may need some support with resources” does not tell the sponsor whether the project needs one additional specialist, a budget increase, a reprioritisation of work or approval to reduce scope.

Leaders cannot make good decisions from vague requests. They need a clear recommendation, credible options and an explicit consequence of doing nothing.

RAG reporting loses its integrity

The most damaging status reports are not necessarily inaccurate. They are often technically true but materially misleading.

A project can report green because most work packages are progressing, while a single unresolved dependency threatens the whole critical path. It can report amber without explaining the recovery strategy, decision deadline or likelihood of returning to green.

A useful status report does not simply describe activity. It provides control.

It should make clear:

What has changed since the last report
Whether the baseline remains achievable
The forecast position for time, cost, scope, quality, benefits, sustainability and risk
The critical issues requiring escalation
The decisions needed from governance forums
The actions that will move the project back to a controlled position

Teams normalise workarounds

When concerns are not raised clearly, people compensate quietly by working longer hours, deferring quality checks, relying on informal agreements and absorbing additional scope. They may also accept incomplete requirements and create manual processes to bridge technical gaps. These workarounds can make a project appear stable in the short term. In reality, they often transfer risk into transition, operational readiness, benefits realisation and/or business-as-usual support. The apparent success of delivery can become the failure of implementation.

What clear leadership sounds like

Leaders set the communication standard. The sponsor, program director or project manager does not need to have every answer. But they do need to make it safe and expected for people to state what they know, what they do not know and what requires action.

Clear leadership includes language such as:

“What are we not saying clearly enough?”
“What would need to be true for this milestone to remain achievable?”
“What is the evidence behind the green status?”
“What is the earliest point at which this risk needs to be escalated?”
“What decision do you need from me today?”
“What are the consequences if we do not act?”
“Who has a different view or concern that has not yet been heard?”
“Is this a delivery issue, a governance issue, a capacity issue or a decision issue?”

These questions do more than encourage discussion. They signal that evidence, dissent and early escalation are valued.

Five practical actions for project leaders

1. Separate the message from the messenger

Play the ball not the person by treating an issue as information to be understood, not a challenge to authority or competence. When someone raises a concern, focus first on the evidence, impact and options. Avoid the instinct to explain it away, defend the current plan or question why the issue was not raised earlier.

How leaders respond to the first difficult message determines whether they receive the next one.

2. Make escalation thresholds explicit

Do not rely on people to judge when a concern has become serious enough to raise. Define practical thresholds for escalation, such as:

Any forecast milestone slip greater than an agreed number of days
Any cost or quality variance beyond tolerance
A critical dependency without a confirmed owner or delivery date
A material change to scope, sustainability, benefits or operating model
A risk whose residual exposure exceeds agreed appetite
A decision that has not been made by its latest responsible date

This turns escalation from a personal judgement into a normal part of project control.

3. Require a clear call to action

Every significant issue should identify the action required. Not: “There are concerns regarding vendor onboarding.”

Instead: “Vendor onboarding is six weeks behind plan because security clearances are incomplete. Approval is required today to establish an interim onboarding pathway, or the planned build commencement date will move by four weeks.”

Clarity is not negativity. It is leadership.

4. Test the status beneath the status

Do not accept a watermelon report, where a green status is being reported without asking what evidence supports it.

Review schedule logic, critical path, risk trends, issue ageing, decision ageing, forecast cost, dependency status and readiness measures. A slick presentation that is not referencing sources of truth such as a B-RADICAL register is not evidence of control.

The purpose of governance is not to receive reassurance. It is to make timely, informed decisions.

5. Reward early truth, not late heroics

Unfortunately, corporate culture in many organisations is celebrate people who rescue a project at the last minute but few reward the person who identified the problem before it became a crisis. This cultural norm needs to change!

A mature delivery culture values early warning, transparent forecasting and disciplined corrective action. It recognises that the person who raises an uncomfortable truth may be protecting the project, the organisation and the sponsor.

The leadership test

The real test of leadership is not whether people agree with you when the project is going well. It is whether people can tell you the truth when the project is not.

Projects need optimism, commitment and momentum. But optimism without candour becomes wishful thinking or just hope. Commitment without challenge becomes groupthink. Momentum without control becomes activity rather than progress.

The strongest project environments are not those without bad news. They are those where bad news travels quickly, is understood clearly and leads to decisive action because the most dangerous words in a project are often not, “We have a problem.” they are, “Everything is fine.”