Bottom-Up Planning Without the Wishlist: A Benefit Dependency Network Method

The annual planning process begins, and the proposals arrive.

Replace the CRM platform. Introduce an AI assistant. Modernize the data environment. Redesign customer onboarding. Automate invoice processing. Improve regulatory reporting.

Every proposal addresses a real concern. Every sponsor can explain why the work matters. Nearly every submission claims to support the strategy.

A few weeks later, the organization has a spreadsheet containing 137 individually reasonable ideas and no coherent way to decide how they fit together.

This is the central problem with bottom-up planning. The organization needs the knowledge held by people close to its customers, operations and systems. But collecting that knowledge in the form of project proposals turns planning into a contest among preselected solutions.

The answer is not to suppress bottom-up ideas. It is to interrogate them.

A Benefit Dependency Network provides a practical way to do that. It makes the reasoning behind each proposal visible: what must change, what benefit the change should produce, which objective requires that benefit and what strategy the objective serves.

The result is not simply a ranked wishlist. It is a defensible set of connected investments.

What a Benefit Dependency Network does

A Benefit Dependency Network, or BDN, is a cause-and-effect model connecting intended outcomes with the organizational changes and enablers expected to produce them.

Different organizations use different terminology, but a traditional chain includes:

Investment objective → benefit → business change → enabling change → enabler

The enabler may be a project, system, technology, policy or other investment. The business change describes what people or the organization must do differently. The benefit is the measurable improvement expected from that change. The objective explains why the improvement matters.

The Northern Ireland Department of Finance describes a benefit model as a one-page route map showing how project outputs and new capabilities lead to business benefits. Its benefit-modelling guidance emphasizes cause-and-effect relationships, measurable intermediate benefits and assigned responsibility for benefit delivery.

The Association for Project Management similarly describes a BDN as a model relating enablers, business changes, benefits and strategic objectives. Importantly, APM recommends developing benefits maps as a group activity rather than having one person quietly create the answer after a few interviews. Benefits mapping is a communication and reasoning process, not merely a diagramming exercise.

John Ward and Elizabeth Daniel’s benefits-management approach also emphasizes the continuing relationship between business change and benefit, with business stakeholders involved from the beginning and throughout the investment lifecycle. Their work is summarized in Benefits Management: How to Increase the Business Value of Your IT Projects.

For bottom-up planning, the BDN gives us two directions of reasoning:

• Work backward from a proposed solution to discover its claimed strategic purpose.
• Work forward from strategy to determine whether the proposed work is sufficient, necessary and coherent.

Both directions matter.

Step 1: Establish the planning frame

Bottom-up participation does not mean planning without boundaries.

Before asking for ideas, define the decision being made:

• What business area or enterprise scope is included?
• What planning period are we addressing?
• What strategies or objectives has leadership actually committed to?
• What financial, regulatory, capacity or timing constraints apply?
• What kinds of decisions will be made at the end of the process?

Keep the strategic anchors few enough to be meaningful. If every aspiration, principle and executive talking point is treated as a strategy, almost any proposal can claim alignment.

At this stage, do not define the projects. Define the outcomes and constraints within which people are being invited to contribute.

Step 2: Collect ideas without demanding premature business cases

Invite ideas from business leaders, operational teams, architects, product groups and technology specialists.

The intake should be lightweight. Ask contributors to describe:

• The problem or opportunity they see
• Who experiences it
• The consequence of leaving it unresolved
• The improvement they expect
• Their proposed response, if they have one
• Known dependencies or affected stakeholders
• A sponsor or knowledgeable contact

Do not demand a polished financial case before the idea has been tested. Doing so favors departments with experienced proposal writers and turns unverified estimates into apparently precise facts.

Treat every submission as evidence, not as a commitment.

The people closest to the work often see risks, customer needs and operational constraints that central planning misses. Bottom-up intake is how the organization captures that knowledge. The remaining steps determine what the knowledge means.

Step 3: Normalize the proposals

Before constructing the network, clean the intake.

Some submissions will describe problems. Others will describe desired outcomes, products, systems, regulatory obligations or projects already given informal approval. Many will bundle several changes together.

Normalize them by:

• Combining genuine duplicates
• Splitting proposals that contain unrelated changes
• Separating the problem from the proposed solution
• Replacing promotional language with neutral descriptions
• Recording alternate solutions without choosing among them
• Identifying proposals that are already underway or mandatory
• Clarifying vague claims such as “improve efficiency” or “enable AI”

Normalization is not prioritization. No proposal wins or loses here. The goal is to make the items comparable enough to reason about.

Step 4: Trace every proposal back to an outcome

Now begin with each proposed project, system or technology and work backward.

Ask:

1. What must people or the organization do differently for this proposal to matter?
2. What measurable improvement should that business change produce?
3. What objective depends on that improvement?
4. Which committed strategy requires the objective?

Suppose someone proposes an AI customer-service assistant.

The tool itself is not the benefit. The reasoning might be:

• An AI assistant and improved knowledge base enable more consistent access to support information.
• Agents adopt a new triage and escalation process.
• More inquiries are resolved during the first interaction.
• Resolution time and customer effort decline.
• Customer retention improves.
• The change supports a committed strategy to increase recurring revenue.

That is an argument the organization can examine.

Another AI proposal might produce no credible business change, have no owner willing to alter operating practices, or lead to a benefit unrelated to any current objective. The network makes that weakness visible before substantial money is committed.

An item without a strategic path is not automatically worthless. It may reveal an unrecognized risk, emerging opportunity or missing strategy. But its justification should not remain invisible.

Step 5: Read the network forward

After tracing proposals backward, reverse direction.

Begin with each committed strategy and follow the network toward delivery:

• Does every strategy have concrete objectives?
• Does every objective have measurable benefits?
• Have the necessary business changes been identified?
• Are there enablers capable of producing those changes?
• Are important dependencies missing?
• Are several proposals duplicating the same enabler?
• Does one shared platform support multiple intended benefits?
• Are there benefits with no accountable owner?
• Are projects present because of historic momentum rather than current need?

This forward reading exposes a different class of problem. A proposal may trace back to strategy but still be insufficient to deliver the claimed outcome.

For example, installing a system rarely produces a benefit by itself. Roles, processes, policies, data, incentives or customer behavior may also have to change. Ward and Daniel’s benefits-management work stresses this connection: the organization must understand and undertake the complementary business changes needed to realize value, not assume that technical functionality is itself a benefit. Their discussion of this problem is particularly clear in their treatment of organizational context.

Step 6: Challenge the benefit claims

Every important benefit should have:

• A clear description
• A baseline
• A target or observable success condition
• A proposed measurement
• A timeframe
• A business owner
• A credible relationship to the changes expected to produce it

Benefits such as “better decisions,” “improved experience” and “greater agility” are not useless, but they are incomplete. Ask what observable difference would demonstrate improvement.

The business owner matters as much as the measure. Project teams can deliver systems and other enablers. They cannot independently create benefits that depend on people elsewhere changing how the business operates.

The Victorian Government’s investment-management guidance uses a related sequence of problem definition, benefit definition, response definition and solution definition. That order is deliberate: define the need and intended result before settling on the investment response. Its workshop guidance and examples provide useful models for structured group discussion.

Step 7: Shape the proposals into coherent programs

The original submissions are not necessarily the right units of investment.

Use the completed network to find natural groupings:

• Proposals contributing to the same benefit
• Changes affecting the same operating area
• Shared systems, data or technology dependencies
• Work that must be sequenced together
• Duplicate or overlapping solutions
• Benefits that require coordinated ownership

Several proposals may become one program. One large proposal may need to be divided. Useful components of a rejected proposal may move into a different program.

Name the resulting programs for the business change or outcome they are intended to create—not merely for the product being purchased.

A program should have a business champion, a coherent objective, explicit benefits, defined changes and a credible set of enabling investments. At that point, it is ready to enter the formal planning cycle for cost, risk, capacity and portfolio evaluation.

Step 8: Record the decision and maintain the logic

The network should survive the planning meeting.

Record which proposals were approved, combined, deferred or rejected and why. Preserve the intended benefits, owners and dependencies as programs move into delivery.

When scope changes, follow the affected paths through the network. When a critical business change is removed, reassess the benefits that depended on it. When a strategy changes, identify the programs and investments whose original justification may no longer hold.

The BDN becomes most valuable when it remains a living explanation of why work exists—not a workshop diagram that disappears into a presentation archive.

How the Useful EA BDN tool supports the process

The method does not depend on a particular application. A team can construct a BDN using cards on a wall, a whiteboard, presentation software or a diagramming tool.

I built the Useful EA Benefit Dependency Network tool to reduce the administrative work around the method.

It supports the process in several specific ways:

Collecting ideas. A Suggestion Link allows people to submit ideas without needing an account. Submissions can be reviewed, edited and promoted onto the network rather than automatically becoming approved initiatives.

Using the organization’s language. Each model can use between two and six columns with configurable headings. A team can use classic BDN terms such as Investment Objective, Benefit, Business Change, Enabling Change and Enabler—or planning terms such as Strategy, Objective, Program, Project, System and Technology.

Importing existing demand. Proposals and their relationships can be imported from CSV instead of re-entering an existing planning spreadsheet.

Making the logic visible. Items are connected directly on the canvas. The network can be read from strategy toward delivery or traced backward from a technology, system or project.

Finding weak alignment. Alignment indicators identify items without a visible upstream connection. The relationship tracer highlights everything connected to one item in both directions.

Creating usable views. Auto Layout arranges the network, while named views can focus on a strategy, program, technology or other root item without duplicating the underlying model.

Collaborating and communicating. Colleagues can be invited with different access roles, and the result can be exported as CSV, PNG, JPEG or editable PowerPoint.

These features make it easier to collect, organize, test and communicate the planning logic. The quality of the outcome still comes from the conversations: asking what changes, who owns the benefit, what evidence supports the claim and how the proposal contributes to an objective the organization has actually chosen.

Bottom-up knowledge, disciplined planning

Bottom-up planning should not be a mechanism for counting votes or rewarding the most polished proposal.

Its purpose is to collect knowledge from across the enterprise and subject that knowledge to disciplined reasoning.

Invite the ideas. Separate needs from proposed solutions. Trace every investment toward a measurable benefit and committed objective. Read the network forward to find missing changes and dependencies. Challenge the claims. Reassemble the useful work into coherent programs.

Then make the investment decision.

The organization may still begin with 137 proposals. But it no longer has to choose among 137 disconnected stories.