Initiative planning needs clarity about the problem, evidence, outcomes, ownership and dependencies before a team commits to delivery. These five gaps explain how a promising initiative can become difficult to execute before work even begins.
When a major initiative goes wrong, the explanation usually starts with execution. The delivery team underestimated the effort, requirements changed halfway through the programme, an integration turned out to be more complex than expected, stakeholders were not aligned, the vendor could not deliver on time, or the final solution did not achieve the adoption that leadership expected.
Those are real problems, but they are often not where the failure began.
In many organisations, an initiative starts accumulating risk much earlier, when an initial business concern is converted into a project before the organisation has properly understood the problem, tested the assumptions behind it, defined the outcome, explored credible alternatives, or identified the dependencies that could materially change the plan.
By the time those weaknesses become visible, the initiative already has a name, a budget, a sponsor, a delivery team and a target date. At that point, changing direction becomes politically and financially harder. What could have been resolved through a few difficult questions at the beginning becomes a six-month delivery problem.
That is why the quality of execution is only part of the story.
A more useful question is:
How much did we actually understand before we committed to execution?
That question matters whether the initiative is a new product, an AI program, a process transformation, a customer experience improvement, a platform replacement, a policy change or a major internal operational project.
The problem is not that organisations fail to plan
Most organisations already plan extensively. They create business cases, project plans, requirements, architecture diagrams, timelines, steering committees, status reports, risk registers and delivery boards.
The weakness is often in the sequence of thinking.
A business leader may start with a statement such as:
“Vendor onboarding is taking too long. We need to automate it.”
Within a few weeks, that sentence can become a programme containing workflow automation, integrations, new approval rules, vendor portals, dashboards and reporting requirements.
The organisation may already be discussing vendors and implementation estimates before anybody has established exactly why onboarding is slow.
Perhaps Procurement spends several days chasing incomplete information. Perhaps Finance manually re-enters data that already exists elsewhere. Perhaps Legal and Information Security are reviewing every vendor when only a small percentage genuinely need enhanced review. Perhaps approval requests sit unnoticed in email. Perhaps the process is not actually slow at every stage; it only becomes slow when exceptions occur.
Those are very different problems.
Automating all of them may be expensive and unnecessary. In some cases, automation may not even be the most valuable first intervention.
The mistake was not poor execution. The mistake was allowing a solution statement to become the initiative before the underlying problem had been properly decomposed.
An idea is not yet an initiative
One of the most common planning errors is treating an initial statement as though it already contains a well-defined problem.
Consider several typical examples:
- “We should use AI in customer support.”
- “We need a better customer portal.”
- “Our onboarding process needs automation.”
- “We need a single view of the customer.”
- “We should modernise the platform.”
- “We need better reporting.”
Every one of these statements may point toward a legitimate business opportunity, but none of them is ready to become a detailed execution plan.
“We need better reporting,” for example, could mean executives do not trust current data, managers cannot access information quickly enough, operational teams cannot identify exceptions, analysts spend too much time combining spreadsheets, or the organisation has the information but lacks clear decision rights.
A reporting project designed around the wrong interpretation may produce a beautiful dashboard that nobody uses.
Before detailed planning begins, the organisation should be able to describe the problem without hiding the preferred solution inside the description.
A practical problem statement should answer four questions:
- What is happening today?
- Who is affected?
- Why does it matter?
- What evidence tells us this is worth solving?
That sounds simple, but many initiatives cannot answer those four questions consistently across their leadership team.
Assumptions become dangerous when they become invisible
Every initiative contains assumptions. There is nothing wrong with that. Decisions have to be made with incomplete information.
The problem is that assumptions rarely stay labelled as assumptions.
A leader may say in a meeting:
“Customers are abandoning because our pricing is confusing.”
Someone includes that statement in a presentation. The presentation becomes an input into a requirements document. The requirements document becomes the basis of a design brief. Soon a delivery team is redesigning pricing and checkout.
Nobody intentionally misrepresented the information, but the language changed from:
“We believe customers may be confused by pricing”
to:
“Customers are abandoning because pricing is confusing.”
That small change can redirect months of work.
The real cause might be late fees, product availability, slow page performance, unclear eligibility, competitor comparison, purchase timing, or something entirely different.
This is why strong initiative planning should deliberately distinguish four types of information.
What we know
Information supported by credible evidence.
Examples might include actual cycle time, conversion data, support volume, error rates, customer feedback, audit findings or confirmed process data.
What we believe
Reasonable assumptions that have not yet been proven.
For example, that customers would prefer self-service, that automation will reduce handling time, or that a new workflow will reduce operational cost.
What we do not know
Information gaps that could materially affect the initiative.
For example, which step causes the longest delay, what percentage of cases can safely be automated, or whether a required integration can support the proposed design.
What we have decided
Choices that the organisation has deliberately made, even though alternatives may exist.
For example, keeping the existing ERP as the financial system of record or requiring human approval for high-risk transactions.
This distinction sounds basic, but it has enormous practical value because it stops uncertain information from quietly becoming permanent scope.
Broad goals create false alignment
Another reason initiatives enter execution too early is that organisations confuse agreement on a broad goal with agreement on the actual outcome.
“Improve customer experience” sounds like alignment.
So does “increase efficiency,” “reduce cost,” “modernise operations,” or “improve visibility.”
The problem becomes obvious when you ask five stakeholders what success would look like.
One person may define improved customer experience as fewer support contacts. Another may care about faster task completion. A third may focus on customer satisfaction. A fourth may care about conversion. A fifth may simply want fewer complaints reaching senior management.
Everyone agreed with the original sentence, but they were never actually aligned.
A useful outcome should describe a meaningful change in the business without prematurely locking the team into one solution.
For example, instead of:
“Automate vendor onboarding.”
A stronger outcome would be:
“Reduce standard vendor onboarding time while maintaining required compliance controls and giving business requestors clear visibility into progress.”
The second statement gives the initiative room to discover the right combination of process improvement, automation, workflow changes, policy changes and technology.
That flexibility matters because the organisation is still solving the problem rather than defending a solution.
The first credible solution should not automatically become the strategy
Business teams naturally move toward solutions because solutions create momentum. They are easier to discuss, estimate and present than uncertainty.
“We need an AI assistant” feels more actionable than “we need to understand why support handling time has increased.”
“We need a dashboard” feels more concrete than “managers are struggling to make timely decisions.”
“We need a new platform” feels more decisive than “our current operating model is creating friction.”
The danger is that once a solution becomes associated with senior sponsorship, questioning it becomes difficult. The organisation moves from evaluating the idea to defending it.
Good initiative planning should create a deliberate point at which credible alternatives are compared.
That does not mean conducting months of analysis or producing twenty options. In many cases, three paths are enough:
- the preferred approach,
- a credible alternative,
- a lower-cost or lower-risk alternative.
For each option, the team should understand the expected benefit, major trade-offs, assumptions, dependencies, risks and conditions under which that option would become stronger or weaker.
For example, if a support organisation wants to reduce handling time, the answer may not be “deploy AI” versus “do nothing.” Real alternatives may include improving internal knowledge, simplifying product workflows, changing routing rules, improving customer self-service, deploying agent-assist AI, or combining several interventions.
The purpose of comparing options is not to slow the decision. It is to prevent the first attractive idea from becoming the only idea that receives serious consideration.
Risk registers are often documentation rather than intelligence
Most mature organisations already maintain risk registers. The issue is not whether risks are documented; it is whether those risks actually influence the design of the initiative.
A common risk entry might say:
Risk: Integration complexity may delay implementation.
Probability: Medium.
Impact: High.
Mitigation: Engage technical teams early.
That looks responsible, but it tells us very little about how the initiative should change.
If integration complexity is genuinely a major threat, it should affect sequencing. The team might validate the API before committing to the full architecture, run a technical proof of concept, confirm authentication constraints, identify the external system owner, test realistic data flows and define a fallback approach.
Now the risk has changed the plan.
That is the difference between recording risk and using risk to improve a decision.
A serious risk should answer five practical questions:
- What could happen?
- Why could it happen?
- What would tell us it is beginning to happen?
- What can we do before it happens?
- What decision would we make if it does happen?
When a risk cannot answer those questions, it is often little more than a sentence in a governance document.
Dependencies exist whether or not the project plan has discovered them
One of the most expensive phrases during execution is:
“We didn’t realise we needed them.”
“We didn’t realise Security had to approve this.”
“We didn’t realise Legal needed to review the data model.”
“We didn’t realise Finance had to change the accounting process.”
“We didn’t realise the vendor API could not support that function.”
“We didn’t realise the European workflow was different.”
“We didn’t realise another team owned that customer data.”
These are regularly described as execution surprises, but many of them are really pre-execution discovery failures.
A team cannot identify every dependency in advance, and attempting to do so would create endless analysis. However, major initiatives should deliberately examine the dependencies that could change scope, feasibility, cost or sequence.
A useful dependency review looks across several dimensions:
- People: Which teams, specialists or decision-makers must participate?
- Systems: Which applications, platforms, APIs or infrastructure components are required?
- Data: What information is required, who owns it and what constraints apply?
- Policy: Which internal rules affect the solution?
- Regulation: Which legal or compliance requirements could change the design?
- Vendors: Which external organisations control critical capability?
- Budget: Which procurement or funding decisions must happen first?
- Sequence: What must be completed before another activity can begin?
The point is not to predict the future perfectly. It is to avoid discovering obvious structural dependencies only after a delivery team is already blocked.
A large requirements document can still be built on weak reasoning
One of the most dangerous illusions in initiative planning is that detailed documentation means the initiative is well understood.
A fifty-page requirements document may contain user journeys, workflows, technical requirements, architecture diagrams, acceptance criteria, risk registers, priorities and delivery milestones.
It may still describe the wrong solution.
The more detailed the document becomes, the harder it is psychologically to question the reasoning underneath it. Teams become attached to the work already completed.
A better test is not simply:
“Is the requirement documented?”
It is:
“Can we explain why this requirement exists?”
An important requirement should ideally have a traceable reasoning chain:
Business or user problem
↓
Evidence or assumption
↓
Decision
↓
Requirement
↓
Expected outcome
This changes the nature of scope discussions.
Instead of asking:
“Who requested this feature?”
The team can ask:
“Which problem does this feature solve, and what evidence supports that need?”
Instead of saying:
“It was included in the original scope.”
The team can ask:
“Is the assumption that created this requirement still valid?”
That is a much more intelligent way to control scope.
We should measure initiative readiness, not document completion
Traditional governance often measures whether planning outputs exist.
Business case: complete.
Requirements: complete.
Architecture: complete.
Budget: approved.
Project plan: complete.
Kick-off: complete.
Those are useful controls, but they mostly prove that activities occurred.
They do not prove that the initiative is ready.
A more valuable readiness conversation would ask whether the organisation has enough clarity in several areas.
1. Problem clarity
Can different stakeholders explain the problem consistently without immediately describing the solution?
2. Outcome clarity
Is there agreement on what meaningful improvement should occur?
3. Evidence
What information supports the initiative, and how strong is that evidence?
4. Assumptions
Which beliefs could materially affect the initiative if they prove wrong?
5. Unknowns
Which unanswered questions could change the decision, scope or design?
6. Options
Were credible alternatives considered before committing to the preferred path?
7. Risks
Have major risks actually changed sequencing, validation or scope where appropriate?
8. Dependencies
Are the dependencies most likely to affect feasibility or timing understood?
9. Decisions
Can the team explain what has been decided and why?
10. Traceability
Can major requirements be connected back to the problem, evidence, decisions and expected outcomes?
No initiative will score perfectly across all ten areas, nor should that be the objective.
The value is knowing where the initiative is strong and where it is still relying on uncertainty.
Uncertainty is not a weakness in a plan
One reason organisations rush through the early stages of an initiative is that uncertainty feels uncomfortable.
A business case that says:
“We do not yet know what percentage of these requests can be safely automated”
may appear less impressive than one that states:
“The programme will automate 70% of requests.”
But unless the 70% figure is supported, the first statement represents better management.
Visible uncertainty creates an opportunity to validate.
The organisation can run a pilot, analyse historical cases, conduct research, test the workflow, validate the integration or create a decision checkpoint before committing to the next stage.
Hidden uncertainty simply waits until execution to reveal itself.
The goal of initiative planning is therefore not to eliminate uncertainty. That is impossible in any meaningful business change.
The goal is to make uncertainty visible enough to manage.
The cost of discovering the truth rises sharply over time
At the beginning of an initiative, changing direction is comparatively inexpensive.
A team can challenge an assumption during a workshop. It can change the proposed scope. It can research an alternative. It can reject an idea. It can decide that the initiative is not yet justified.
After execution begins, the same change may affect contracts, architecture, integrations, committed teams, customer promises, training, communication plans and leadership expectations.
The organisation is no longer changing an idea.
It is changing an investment.
That is why early intelligence has disproportionate value.
Better pre-execution thinking does not mean months of analysis
There is an important warning here.
The answer is not to replace premature execution with endless discovery.
Organisations can just as easily create another problem by spending months producing presentations, research reports, governance packs and workshops without making a decision.
The goal should be decision-quality information, not maximum documentation.
A small operational improvement may require only a short structured review. A major platform replacement may require technical validation, stakeholder analysis, scenario planning and external research. A global business transformation may require substantially more evidence.
The level of analysis should match the potential cost of being wrong.
A useful rule is:
Spend the most time on uncertainties that could materially change the decision.
That keeps the process focused.
A practical pre-execution intelligence review
Before approving significant execution, a leadership or product team can run the initiative through a simple ten-part review.
1. Define the problem
Describe what is happening today without embedding the preferred solution in the description.
2. Define the outcome
State what should improve and how the organisation will recognise meaningful progress.
3. Map the stakeholders
Identify users, operators, buyers, approvers, affected teams, regulators and decision-makers.
4. Separate facts from assumptions
Document known, assumed, unknown and decided information explicitly.
5. Identify the evidence gaps that matter
Do not research everything. Research information that could change the decision.
6. Compare credible approaches
Understand why the preferred path is stronger than realistic alternatives.
7. Explore major failure scenarios
Consider what happens if adoption is weaker, delivery takes longer, costs increase, a dependency fails or a key assumption proves wrong.
8. Identify critical dependencies
Surface the people, systems, data, approvals and external factors that could materially affect execution.
9. Record important decisions
Capture what was decided, why it was decided and what would cause the decision to be revisited.
10. Only then build the detailed execution blueprint
Requirements, workflows, architecture direction, workstreams, milestones and delivery plans should follow the reasoning rather than replace it.
This is the gap between strategy and project management
Most organisations already have strong systems of record for execution.
Project management platforms know which task is open, who owns it, when it is due and what is blocked.
CRM systems know the customer, opportunity, pipeline and commercial history.
Financial systems know budgets, transactions and invoices.
HR platforms know employees, teams, roles and organisational structure.
What is often missing is a system of record for the reasoning behind an initiative.
Where can someone reliably answer:
- Why are we doing this?
- What problem were we originally trying to solve?
- What evidence supported the initiative?
- Which assumptions were we relying on?
- What did we still not know?
- Which alternatives were considered?
- Why was this direction selected?
- What risks influenced the plan?
- Which decisions were made?
- Which requirements came from those decisions?
- Does the work being delivered still connect to the original outcome?
In many organisations, those answers are scattered across presentation decks, meeting notes, spreadsheets, email threads, project documents and individual memories.
The execution record survives.
The reasoning that created it slowly disappears.
That is a significant gap.
Why we are building BuildFlowIQ
This gap is one of the reasons we are building BuildFlowIQ.
We do not believe the answer is another AI tool that accepts a two-paragraph idea and immediately generates a fifty-page requirements document. Generating documents faster can be useful, but it does not solve the deeper problem if the reasoning behind those documents is weak.
The more important opportunity is to preserve the intelligence chain from the original idea through the eventual execution plan.
In BuildFlowIQ, that thinking develops progressively through stages such as Discovery, validation of assumptions and risks, ResearchIQ, SimulationIQ, Strategic Recommendation, Blueprint, supporting Artifacts and ProjectIQ execution planning.
The purpose is not to create process for the sake of process.
Each stage should answer a different question.
Discovery: Do we understand the problem?
Validation: What are we assuming, contradicting or overlooking?
Research: What evidence should influence the decision?
Simulation: What could happen under different conditions?
Strategic Recommendation: Which direction appears strongest, and why?
Blueprint: What actually needs to be delivered or changed?
Artifacts: What supporting operational, governance, rollout, commercial or technical work is required?
ProjectIQ: How does all of that become structured execution?
The objective is not more documentation.
The objective is better decisions, stronger continuity and fewer expensive surprises after execution has already begun.
Before your next initiative begins, ask a different question
The next time someone says, “We need to start the project plan,” the most useful response may not be to immediately create the plan.
Ask:
What could we discover now that would materially change what we are about to commit to?
Perhaps the team will uncover an unsupported assumption.
Perhaps the problem is different from what leadership originally believed.
Perhaps a dependency changes the sequence.
Perhaps a cheaper alternative solves most of the problem.
Perhaps an important stakeholder has been excluded.
Perhaps the initiative needs a small pilot before a large investment.
Perhaps the organisation discovers that the initiative should not proceed at all.
None of those outcomes represent wasted planning effort.
They represent avoided execution waste.
Strong execution still matters enormously, but execution works best when it receives a problem that has been understood, a direction that has been deliberately chosen and a plan whose assumptions are visible.
The best time to discover a bad assumption is before it becomes a requirement.
The best time to discover a missing dependency is before it becomes a blocker.
The best time to challenge a strategy is before it becomes a committed budget.
And the best time to understand an initiative is before execution begins.
Further reading and next steps
For a broader view of success that includes stakeholder value and intended outcomes, explore PMI research on project success. Review AI-generated drafts with the people accountable for the initiative and record unresolved assumptions before committing to delivery.
Explore BuildFlowIQ’s initiative intelligence and planning intelligence, see how the workflow works, or request a focused demo.