Wiki V1.0
Powered by

# Technology Before Process

"We need a planning tool" is often the first sentence in an IBP journey. It's also the most expensive way to start.

# The Pattern

An organization decides to implement IBP. Within weeks, the conversation shifts from process design to software evaluation. A project team is formed, RFPs are issued, vendor demos are scheduled. Six months and significant investment later, a planning tool goes live — but nobody can articulate the process it's supposed to support.

The tool gets configured around assumptions about how the process should work, not how it does work. Users resist the system because they weren't involved in designing the workflow it enforces. Planning meetings happen in the tool's interface, not around business decisions. Within a year, the "IBP system" is used by a handful of analysts while the rest of the organization plans in spreadsheets alongside it.

# Why It's Tempting

  • Technology feels actionable. Buying software is a concrete step with a timeline, a budget, and a project plan. Defining a process feels abstract by comparison.
  • Vendors sell a compelling vision. Demo environments show a polished, integrated planning process. It's easy to believe the tool creates the process rather than supporting it.
  • Leadership equates investment with progress. "We bought an IBP tool" sounds more decisive than "We ran three manual planning cycles to figure out our process."
  • IT wants to consolidate. There's a legitimate desire to replace fragmented spreadsheets with an integrated platform. The mistake is doing it before the process is understood.

# Why It Fails

Software automates whatever you give it — including chaos. If the planning process is undefined, the tool will codify confusion. Workflows will be configured based on best guesses, and reconfiguring later is expensive.

Configuration decisions require process design. Every planning tool asks questions during setup: What's your planning hierarchy? What's your review cadence? Who approves the plan? If you don't have answers grounded in experience, you'll guess — and you'll guess wrong.

Users resist systems they didn't help design. When the tool arrives pre-configured and users are told to "follow the system," adoption stalls. People comply minimally while maintaining their real planning process on the side.

The tool becomes the scapegoat. When IBP doesn't deliver results, the organization blames the software instead of the missing process. This leads to re-implementation cycles — new tool, same problem.

# What To Do Instead

# Run manual cycles first

Before evaluating any technology, run 3-6 manual IBP cycles using spreadsheets, existing reports, and face-to-face meetings. This accomplishes several things:

  1. Reveals the real process. You'll discover what data you actually need, what decisions get made (and don't), and where the friction points are.
  2. Builds cross-functional muscle. IBP is a behavioral change, not a technology change. Manual cycles force people to collaborate before a tool mediates the interaction.
  3. Creates informed requirements. After 3-6 cycles, you can write technology requirements based on actual pain points rather than hypothetical needs.

# Then define process before tool

Step Action Timing
1 Define the IBP cadence, meetings, and participants Before any vendor contact
2 Run 3-6 manual cycles Months 1-6
3 Document what works, what doesn't, and where technology would help After cycle 3
4 Write technology requirements based on real experience After cycle 6
5 Evaluate tools against your defined process Months 7-9
6 Implement with users who understand the process it supports Months 9-15

# Warning Signs

You might be in this anti-pattern if:

  • More time has been spent in vendor demos than in actual IBP meetings
  • The planning tool is live but unused for real decisions
  • The "IBP project" is managed by IT, not a business process owner
  • Users maintain parallel spreadsheets alongside the system
  • The tool's workflow doesn't match how decisions actually get made
  • Nobody can describe the IBP process without referencing the software

# The Opposite Extreme

The opposite mistake — refusing to adopt technology even when the process has matured — is the Spreadsheet Trap. The goal is to get the sequencing right: process first, then technology to support and scale it.

# Further Reading