Ask a CIO in 2010 which project management tool the company used and you would get a confident answer. Ask the same question of eight department heads and you would get eight different answers, several of which the CIO had never heard of. Engineering ran an issue tracker. Marketing ran a web-based task board. The project management office maintained Gantt charts in a desktop planning package. Operations ran a shared spreadsheet with conditional formatting that one person understood. Finance tracked initiatives in a slide deck updated monthly. HR used a checklist in the intranet. Each of those choices was sensible for the team that made it. Collectively they meant the organization had no reliable way to answer a simple question: what are we actually working on, and is any of it late?
Why Fragmentation Happens
The standard explanation is that departments are undisciplined. That is mostly wrong, and treating it as the cause produces the wrong remedy. Different work genuinely needs different tools. A software team's sprint board and a construction schedule's dependency chain are not the same problem. Forcing both into one system produces a tool that serves neither, which is precisely why the mandated corporate standard gets abandoned. The centrally chosen tool is optimised for reporting, not for doing. Enterprise project portfolio management systems in this period were designed around the needs of the PMO — governance, stage gates, resource allocation, roll-up reporting. They were heavy to use for the people doing the work, who therefore maintained a shadow tool that reflected reality and updated the official system before status meetings. Procurement friction favoured small tools. A departmental manager could sign up for a web-based tool on a credit card in ten minutes. Getting a corporate system extended took a business case and two quarters. Nobody owned the question of coherence. IT owned the tools. The PMO owned the process. No single function owned whether the organization could see its own work.
The Costs That Accumulate
Fragmentation has a reputation as a tidiness problem. It is not; the costs are concrete and compound. Cross-functional work has no home. The projects that matter most — a product launch, a system implementation, a market entry — involve four departments using four tools. The coordination happens in email, which means it is invisible, unsearchable and dependent on whoever is copied. Portfolio status becomes a manual assembly exercise. Someone spends two days a month collecting updates into a deck. By the time it is presented it is stale, and the effort is repeated every cycle indefinitely. Dependencies are discovered late. Team A cannot see that Team B's slippage affects them, because the two schedules live in different systems that nobody reconciles. Late discovery of dependencies is one of the most reliable causes of project failure. Resource conflicts are invisible. The same three specialists are committed to five projects across four tools. Nobody can see the over-allocation until the person misses a deadline. History disappears. When a departmental tool is abandoned or its champion leaves, the record of decisions, estimates and outcomes goes with it. The organization loses the ability to learn from its own projects.
What Consolidation Gets Wrong
The standard response is a consolidation programme: choose one tool, migrate everything, mandate usage. It fails with impressive consistency, and the failure mode is worth understanding because it repeats in every tooling category. The mandated tool is selected for governance requirements, so it is worse for daily work than what teams were using. Adoption is enforced through reporting requirements rather than usefulness. Teams comply minimally — updating the corporate system before reviews — and keep their real tool alongside it. The organization now has the original fragmentation plus a central system that contains stale data, which is worse than before because people believe the central data. The insight that fixes this is separating two different needs that consolidation programmes conflate. Teams need execution tools suited to their work. The organization needs a consistent view of commitments, dates, owners and status. Those are not the same requirement and they do not need to be the same system.
| Decision | Mandated consolidation | Shared-data integration |
|---|---|---|
| Daily execution | Teams enter work in a central tool | Teams keep tools suited to their work |
| Portfolio facts | Updates may be retyped before reporting | Define one owner and source for each fact |
| Dependencies | Separate schedules need reconciliation | Expose cross-team commitments in a common view |
| Adoption | Reporting compliance drives maintenance | Make the record useful to the people doing the work |
Qualitative summary of this article's source text, not a measured outcome or performance estimate.
A Workable Approach
- Standardise the data, not the tool. Agree a minimal common set of attributes every initiative must have: name, owner, target date, current status, dependencies, and a short narrative. Teams can maintain those in whatever system they use.
- Define one source of truth per fact. The most damaging form of fragmentation is the same date existing in three systems with three values. Decide which system owns each fact and make the others read from it.
- Integrate rather than migrate where possible. Pulling status from existing tools into a portfolio view preserves team autonomy and eliminates duplicate entry, which is the main reason central systems go stale.
- Make the portfolio view genuinely useful to teams. If the only beneficiary of the roll-up is management, maintenance will always be a compliance chore. Cross-team dependency visibility is the feature that makes teams want it.
- Eliminate duplicate entry ruthlessly. Any process requiring a person to type the same status into two systems will produce one accurate system and one fiction. There is no discipline solution to this; only a design one.
- Limit the mandatory fields. Every additional required field reduces the proportion of records that are current. Six well-maintained attributes beat twenty-five mostly empty ones.
- Audit for shadow tools periodically and without punishment. They indicate an unmet need. Treating them as violations drives them further out of sight; treating them as requirements documentation improves the central offering.
- Own the question explicitly. Someone — a portfolio lead, a chief of staff, an operations director — must be accountable for whether the organization can see its own work. Unowned, this problem regenerates within eighteen months of any cleanup.
Fifteen Years On
The tools changed completely and the problem did not. Modern work management platforms are far better than their 2010 predecessors — more flexible, easier to adopt, better integrated. And the average organization now runs more of them, not fewer, because adoption friction fell to nearly zero and every team can start its own workspace in an afternoon. What has genuinely improved is the integration layer. Connecting systems so that status flows between them, rather than being retyped, is now realistic in a way it was not in 2010. Organizations that invested there have solved most of the visible symptoms while leaving team autonomy intact. The next iteration is already visible. AI assistants promise to read across tools and synthesise a portfolio view without anyone maintaining one — which is genuinely useful and quietly dangerous. A generated summary is only as good as the underlying records, and the fragmentation problem was never that the data was scattered. It was that a large proportion of it was out of date. An assistant that confidently reports status from a board nobody has touched in six weeks has not solved fragmentation; it has automated the stale status deck. The requirement that survives every tooling generation is simple and unfashionable: the people doing the work have to keep the record current, and the only reliable way to make that happen is to make the record useful to them.
Common Questions
Why do organizations end up with multiple project management tools?
Because different types of work genuinely need different tools, centrally mandated systems are usually optimised for reporting rather than execution, and low procurement friction lets departments adopt their own tooling faster than central IT can respond.
What are the real costs of project tool fragmentation?
Cross-functional work coordinated invisibly through email, manual portfolio reporting that is stale on delivery, late discovery of dependencies, invisible resource conflicts, and loss of project history when departmental tools are abandoned.
Why do tool consolidation programmes usually fail?
Because the mandated system is chosen for governance rather than daily usability, so teams comply minimally while continuing to use their real tool — leaving the organization with the original fragmentation plus a central system containing data people wrongly trust.
What works better than consolidation?
Standardising a minimal common data set rather than the tool, defining a single owner for each fact, integrating existing systems to avoid duplicate entry, and making the portfolio view useful to teams through dependency visibility.
Portfolio Tooling Review — Outpace finds every place your work is actually tracked, builds a portfolio view that does not depend on anyone retyping status, and leaves teams the tools they need to get things done.