Engagement Type
Enterprise Portfolio Software Redesign
Strategy
The portfolio mandate, operating scale, and visibility the software was expected to provide.
The Mandate
Portfolio Visibility at Global Scale
The organization managed a multi-billion-dollar portfolio of more than 120 projects within a $65B environment. Individual investments ranged from approximately $2M to $100M before graduating into a separate system for major-capital projects.
The portfolio software was intended to connect the people closest to project performance with the leaders responsible for understanding it. Practitioners documented findings and recommendations, managers reviewed the evidence, and executives across continents used regional dashboards to assess portfolio conditions.
For that model to work, the information moving upward had to be trustworthy. The software needed to preserve accurate inputs, practitioners needed to trust the records they retrieved, and the teams responsible for improving the system needed a reliable way to validate requirements before they became features.
Theory vs. Reality
The Plan and the Operating Reality
| The Plan Required | Operating Reality |
|---|---|
| Reliable portfolio visibility | Accurate inputs could produce incorrect or unexpected outputs |
| Trustworthy project records | Ghost data appeared and records required manual verification |
| Software supports practitioner capacity | Practitioners spent time troubleshooting and reconciling the tool |
| Product expertise shapes scope | Charters were written before product expertise entered |
| Users validate requirements | Direct user research and usability testing were prohibited |
| Requirements tested before build | Designers inherited predetermined features and scope |
Execution
How an aging portfolio system and the operating model surrounding it shaped the work beneath executive reporting.
The Environment
Billions Under Management. Software That Hadn’t Kept Up.
The portfolio software connected practitioners, managers, and executive reporting across a global organization. On paper, it created a continuous information path from people working closest to individual projects to leaders assessing the portfolio across regions.
In practice, the application had gone years without meaningful modernization. It was slow, difficult to navigate, prone to defects, and capable of behaving in ways users did not expect. Accurate inputs could produce conflicting information. “Ghost” data appeared where users did not expect it. Records sometimes had to be checked manually before practitioners could trust what they were seeing.
The consequences extended beyond inconvenience. The same people responsible for evaluating projects and identifying opportunities to improve long-term value were spending part of their capacity reconciling records, troubleshooting software, and finding ways around the system.
The people responsible for improving project value were spending part of their time determining whether the software describing those projects could be trusted.
The Product Environment
A Broader Internal Software Organization
Around the application sat a broader internal software organization of approximately 40 product designers supporting roughly 120 enterprise applications. Designers carried a minimum of three projects at a time, and workloads could be substantially higher.
Yet product management and design maturity remained low. Leaders outside those disciplines frequently defined charters, user stories, features, and scope before product expertise entered the work. Designers were therefore often asked to execute against decisions they had little opportunity to investigate or validate.
The 3 Ways Value Was Lost
Leakage, Erosion, Foregone Creation
Loss 1
Value Leakage
Troubleshooting, reconciliation, manual verification, rework, and downstream changes consumed recurring capacity. These costs appeared across teams, projects, support activity, and vendor records rather than as one consolidated measure of execution loss.
Loss 2
Value Erosion
As software reliability deteriorated, so did confidence in the information it produced. Practitioner capacity shifted toward compensating for the system, while defects and workarounds increasingly became part of normal operations.
Loss 3
Foregone Value Creation
Product expertise entered after many formative decisions had already been made. Improvements identified through design and product practice faced default rejection or required exceptions to enter scope, limiting opportunities to improve usability, adoption, and practitioner effectiveness.
Divergence
Where software conditions and governance choices began pulling operating reality away from the visibility leadership expected.
One Decision Across ~120 Applications
A Governance Choice, Propagated at Scale
Direct user research and usability testing with end users were prohibited.
The policy affected approximately 40 product designers working across roughly 120 internal enterprise applications. Teams could design and build software for internal users without the disciplines responsible for product experience being allowed to directly investigate those users’ needs or test whether proposed solutions actually worked for them.
That transformed what could appear to be isolated product problems into something structural.
Different applications served different purposes and users, but the process used to define them shared the same upstream constraint: requirements could enter development without direct validation from the people expected to use what was built.
Correlated by policy
One governance decision. ~40 designers. ~120 enterprise applications. Direct user research prohibited. Requirements risk propagated by policy.
What the Dashboard Could Not See
The Signals Hiding Inside the Work
Reconciliation failures
Accurate inputs could produce unexpected or conflicting information, requiring practitioners to investigate the software while project work waited.
Workarounds became normal
As software problems persisted, users developed ways to accomplish their work around the limitations of the system.
Ghost data required verification
When records did not reliably reflect what practitioners expected to see, additional effort was required to determine which information could be trusted.
Product expertise arrived late
Charters, features, and scope could be established before the disciplines responsible for investigating and validating user needs entered the work.
Executive reporting omitted the conditions underneath it
Leadership could see the information reported through the system without seeing the troubleshooting, reconciliation, workarounds, and capacity required to produce and validate it.
The cost had no owner
The effects appeared across practitioner time, product work, support activity, rework, and other systems. No single measure consolidated their economic consequence.
Unmeasured Exposure
What Leadership Never Quantified
The portfolio tracked projects, spend, milestones, and findings. It did not consolidate the economics of the operating friction underneath them.
Capacity Drain
Troubleshooting, reconciliation, manual verification, and workarounds consumed practitioner time. The cumulative capacity effect was not consolidated into project economics.
Requirements Rework
Requirements could proceed without direct user validation, allowing problems to surface later when correction was more difficult and expensive.
Information Reliability
Executives used portfolio reporting while practitioners encountered records requiring reconciliation and verification. The effect of those conditions on portfolio-level interpretation was not quantified.
Excluded Expertise
Product proposals, exception requests, and rejected recommendations documented expertise that struggled to enter formative decisions. The cumulative consequence was never analyzed.
Evidence Fragmentation
Tickets, support records, charters, vendor documentation, change records, and practitioner experience contained pieces of the operating picture. They were never assembled into a shared economic interpretation.
The records existed. The analysis did not.
Stakes
How compromised inputs, recurring workarounds, and hidden operating friction affected the view leadership relied upon.
The Consequence
Leadership Could See the Portfolio. Not the Conditions Producing the View.
The software was intended to make portfolio conditions visible across organizational layers and continents. Yet some of the conditions most capable of compromising that visibility—unreliable records, manual reconciliation, recurring workarounds, unvalidated requirements, and practitioner capacity consumed by the tool itself—sat outside executive reporting.
Practitioners continued documenting project findings. Managers continued reviewing them. Executives continued receiving portfolio-level information.
What the reporting could not show was how much effort was required to make the underlying information usable, where confidence in the system had deteriorated, or which recurring problems shared a common structural cause.
The organization did not lack information.
It lacked visibility into the conditions producing the information.
The Scale at Stake
Broader enterprise environment
Project portfolio represented through the operating environment
Individual project investments before major-capital classification
Projects requiring portfolio visibility
Product designers supporting the broader internal software environment
Internal enterprise applications operating within the shared product model
Insight
The final finding connects hidden operating conditions to portfolio economics and gives leaders a practical screen.
The Structural Finding
Authority and Proximity Had Drifted Apart
The people closest to the work could see defects, reconcile conflicting information, experience the workarounds, and observe where the software failed to support the job.
The people with authority to change the broader operating model saw the information that successfully traveled through it.
Between those layers, recurring friction became normalized. Workarounds blurred the boundary between the work practitioners were hired to perform and the additional work created by the system itself.
The organization already contained expertise capable of identifying many of these conditions earlier. What it lacked was a reliable mechanism for converting that evidence into an operating and economic case that could reach the people positioned to act.
The problem was not an absence of evidence. It was the distance between evidence, authority, and economic interpretation.
The Screen for Any Portfolio
Three Questions Every Leader Can Ask This Week
Leakage
What recurring work exists solely to compensate for broken tools, processes, or operating conditions—and where is its cumulative cost measured?
Erosion
Which conditions beneath executive reporting are degrading data quality, operating capacity, or confidence without appearing in reported performance?
Foregone Creation
Which sources of expertise are absent when important decisions are made, and what assumptions therefore remain untested?
The portfolio had extensive reporting. What it lacked was an economic view of the conditions underneath it.
If you are ready to connect execution conditions to portfolio economics, schedule a conversation.