"We need to redo the org chart" is almost never the real request, it’s the expected outcome. Underneath it is one of five very different problems: a restructure, a growing team that's outgrowing its shape, a management layer that's stretched too thin, a succession or what-if question nobody's answered yet, or two or more companies trying to become one. Each of these needs something different from your planning process, and the wrong tool almost always gets picked because nobody stopped to name the type of change first.
Here's a breakdown of each, the mistakes that trip up HR, HRBPs, and Finance teams the most, and what to actually demand from a planning tool before you commit to one.
1. Restructuring
This is the big one: consolidating departments, changing reporting lines, flattening or adding layers, moving teams under new leaders. It's rarely one clean move. A restructure usually touches multiple departments at once, and the version that gets presented to the board looks nothing like the six drafts that came before it.
Where it goes wrong: Teams build the new structure in slides or a spreadsheet, and by the time it's approved, the underlying headcount data has already changed. Someone left. A new hire started in the old structure. Nobody updated the source of truth, so the "final" org chart is already out of date on launch day.
What to demand from your software: A sandbox that lets you model the new structure against live headcount data, not a snapshot from three weeks ago. You want to drag people between boxes, see the reporting lines update automatically, and compare the before-and-after side by side without exporting to five different files. If Finance can't see how the new structure changes cost by department in the same view, you'll be reconciling numbers by hand after the fact.
2. New and growing team mapping
This is the happier problem: a team is scaling, and you need to map out what it looks like at 10 people, then 25, then 50. It's less about fixing something broken and more about giving a growing team room to actually grow into.
Where it goes wrong: Growth planning gets treated like a one-time exercise instead of an ongoing one. A leader maps the team for the next two quarters, hiring happens faster or slower than expected, and the plan is stale within a month. Or worse, the plan lives in one person's head and a whiteboard photo, so nobody else can see it or build on it.
What to demand from your software: Position-based planning, not just employee-based planning. You need to be able to build out roles that don't have a name attached yet, plan multiple growth scenarios at once, and let a hiring manager and an HRBP work from the same live plan instead of trading screenshots. Bonus points if it connects to your HRIS so the approved headcount actually shows up as open reqs without a separate manual step.
3. Span-of-control adjustments
Span of control is how many people report to one manager, and it quietly breaks more often than people notice. A team grows, nobody adjusts the management layer, and suddenly one manager has 18 direct reports while another has 3.
Where it goes wrong: Most HRIS platforms are built to record who reports to whom today. They're not built to flag that a manager's span has crept past what's sustainable, or to model what happens if you split that team into two. Span-of-control problems tend to get caught only after they've already caused burnout, missed 1:1s, or a manager who quietly stops trying to manage everyone well.
What to demand from your software: Reporting and visualization that surfaces span of control automatically, across the whole org, not just the team someone happens to be looking at. You want to spot the outliers before they become retention problems, and you want to be able to model a split or a new manager layer and see the ripple effects immediately, including on the budget Finance is tracking.
4. Succession and what-if planning
This covers both ends of the same question: what happens if a key leader leaves, and what happens if we make a change we haven't committed to yet. Succession planning and what-if scenario planning get treated as separate exercises, but they lean on the same muscle: knowing who could step into a role, and what the org looks like if they do.
Where it goes wrong: Succession plans get built once a year for a board deck and then never touched again. Nobody updates them when someone gets promoted, moves teams, or leaves. Meanwhile, "what-if" planning happens in a panic, days before a leadership change is announced, because there was no living model to pull from. Static slides can't answer "what if" questions. They can only describe one already-decided outcome.
What to demand from your software: A living model you can duplicate and adjust without touching the current org chart, so you can test "what if this leader leaves" or "what if we promote from within" without any risk to the plan everyone's actually working from. You also want bench strength visibility built in, so you're not starting succession conversations from a blank page every time.
5. Mergers and acquisitions
M&A brings two org structures, two sets of titles, two headcount plans, and often two entirely different HR systems together at once. It's the highest-stakes org change on this list, and also the one most likely to be run out of a shared spreadsheet under serious time pressure.
Where it goes wrong: Teams try to merge two org charts manually, title by title, and lose track of duplicate roles, conflicting reporting lines, or entire teams that got missed in the first pass. Because the pressure is high and the timeline is short, mistakes here get baked into the new organization instead of caught in planning.
What to demand from your software: The ability to import and overlay two separate org structures, reconcile titles and reporting lines side by side, and model the combined structure before day one instead of after. You also want version control and audit history here more than anywhere else on this list, since M&A decisions get revisited and questioned long after the ink is dry.
Name the change before you name the tool
Every type of change above touches the same org chart, but they ask completely different questions of your software. Restructuring needs live headcount modeling. Growth needs position-based planning. Span of control needs org-wide visibility. Succession needs a living model that doesn't put the current plan at risk. M&A needs to reconcile two structures at once without losing data along the way.
Here at Sift, this is the exact gap we hear about most from HR, HRBPs, and Finance teams: the software they have was built to record the org, not to plan it. If you're evaluating a new tool, start by naming which of these five changes you're actually solving for. The right feature list follows from there.
Frequently asked questions
What's the difference between org restructuring and headcount planning? Restructuring changes reporting lines, departments, or management layers for an existing team. Headcount planning maps out new roles and hires for a team that's growing, without necessarily changing what already exists. They often happen together, but they need different views in your planning software.
How do you know if a manager's span of control is too wide? There's no single number that works for every team, but most organizations see problems once a manager has more than 8 to 10 direct reports, especially if the role is high-touch. The bigger flag is usually a manager who has grown into a wide span gradually, without anyone deciding it on purpose.
What should HR ask for when evaluating org planning software for M&A? Ask specifically whether the tool can import two separate org structures and reconcile them side by side, rather than requiring a manual merge. Also ask about audit history, since M&A org decisions tend to get revisited months after the initial integration.
Can succession planning and what-if scenario planning use the same tool? Yes, and they should. Both rely on being able to model a change to the org without touching the live structure everyone else is working from. If your tool can only edit the current org chart directly, it can't safely support either one.