The End of Power Point and Excel Project Management
Endless manual chasing of status and progress updates across projects must end now
A transformation director asks a straightforward question: “If we postpone this release, which business outcomes move with it?”
The program team has a milestone plan, a budget report, several delivery backlogs, and a steering committee presentation. Answering the question still requires people to reconnect the information. Which capabilities depend on the release? Which markets are affected? Can the business adopt a partial delivery? Does postponement reduce cost, or simply extend the period in which two solutions must operate?
Each document may be accurate. The relationships between them still have to be reconstructed.
This is what I mean by PowerPoint project management: an approach in which the management picture is repeatedly assembled for a meeting, while much of the underlying logic remains scattered across files, tools, and people.
For CEOs, CIOs, and transformation directors, the opportunity is to make that logic a maintained part of the transformation.
When the presentation becomes the management system
PowerPoint provides a useful way to explain a situation, frame a choice, and secure a decision. The difficulty begins when the presentation becomes the place where the decision, its consequences, and the delivery commitment are maintained.
Consider a milestone that changes after a steering committee meeting. Someone updates the slide. Someone else revises a plan. Delivery teams adjust their backlogs. Finance reviews the forecast. The business prepares for a different adoption date.
Unless these changes are connected, their consistency depends on people remembering every consequence and finding every affected owner. The same problem appears with a green status indicator. It might mean that development is on schedule. It might say little about whether the required data is validated, the operating organisation is ready, or the intended business capability can actually be used.
A senior leader needs to understand what the status includes, what evidence supports it, and which conditions remain unresolved. A summary becomes more useful when those answers can be traced.
From management documents to a connected model
A connected transformation model maintains the important management items and their relationships: objectives, capabilities, requirements, decisions, dependencies, delivery commitments, adoption responsibilities, and evidence.
Each item has an identity and an owner. A decision has a recorded rationale. A dependency connects specific items. A release has defined acceptance conditions. Reports draw on that information and show when it was last confirmed.
At LINNFOSS, we describe these connections as the Transformation Graph. It allows the management team to follow business intent through the work required to realise it.
The underlying principle already has practical precedents. Microsoft’s Power BI guidance recommends separating a shared data model from its reports when multiple reports will use it. The information can support different views without being independently rebuilt for each audience.[1]
Microsoft also provides lineage views showing relationships among data sources, models, and reports.[2] Those relationships concern analytics, but the management lesson is useful: understanding a change requires visibility into what depends on it.
Atlassian’s Teamwork Graph illustrates another application of connected information. Atlassian describes it as a way to connect work and context across applications for teams and AI.[3]
This is a vendor’s approach, rather than proof that any platform will solve a particular transformation. It nevertheless shows how software can maintain relationships that would otherwise need to be assembled manually.
For executives, the design question is which relationships must be maintained to support their decisions.
A catalogue release with several different meanings of done
Consider an illustrative manufacturer replacing its product-information platform and customer front end.
The intended outcome is that customers and sales teams can find, select, and configure suitable products using validated information in the supported markets.
Several workstreams contribute. One supplies product data. Another publishes the catalogue. Others handle translations, selection rules, infrastructure, and the customer interface.
A steering committee deck reports each workstream against its milestones. The catalogue is on schedule. The front end is progressing. Translation has an issue. Selection services remain under review. Now the product-data team discovers that an attribute used in selection has inconsistent units across two product families.
The executive issue is whether customers can make a reliable product choice at release. Resolving it requires a view across workstreams. In a connected model, the attribute is linked to the affected families, selection rules, catalogue records, and test evidence. The issue owner records the inconsistency. The relevant teams assess its effects. The release owner can see which acceptance conditions remain unmet.
The management team can then examine concrete options: correct the data before release, exclude the affected families from the first release, or postpone the capability. Each option has consequences. Excluding families changes the customer scope. Correcting the data requires capacity and validation. Postponement may extend legacy operation and move planned benefits.
The steering committee presentation can summarise these choices. Its recommendation comes from information that remains available after the meeting, including the assumptions and evidence behind it.
When a decision is approved, it is linked to the affected scope, work, release, and business owner. The next review can examine whether that decision was implemented.
Reusable patterns preserve more than a template
A document template gives a team a starting format. A reusable management pattern can also preserve how the work is performed.
For the catalogue example, a data-readiness pattern might define the accountable owner, the validation required, the treatment of exceptions, and the evidence needed before publication.
The next product family can use the same approach while adapting its engineering rules and market requirements. Improvements to the method can be reviewed and carried into later work.
This is the direction informing our work on LINNFOSS software products and the workbench: preserving the connection between intent, decisions, implementation, and evidence as the work evolves.
The practical value of reuse is that teams can start with a defined method and improve it through experience. They still need to judge whether the pattern fits the situation.
AI needs the management context
Connected information also provides a basis for more useful AI assistance.
In the catalogue scenario, a bounded AI workflow could examine the issue and its linked records, identify missing assessments, and prepare an impact summary for the release owner. It could distinguish confirmed dependencies from connections that still need review.
That requires access to the relevant information, clear instructions, and a defined scope of action. Anthropic’s guidance on context engineering emphasises curating relevant information and giving agents clear tools and instructions.[4]
Uploading a collection of presentations does not establish which decision is approved, which assumption has expired, or who can change the release commitment. Those meanings need to be maintained.
Anthropic also distinguishes predefined workflows from agents that determine their own sequence of actions, and recommends using the simplest approach that meets the need.[5] A straightforward rule may be sufficient to flag a missing owner. AI may help interpret an ambiguous issue. Funding and scope decisions still require authorised judgment.
How to begin without adding another layer of administration
A useful starting point is one business capability and the decisions required to deliver it. Give a business owner and a delivery lead responsibility for testing the approach together.
1. Define the usable business outcome
Describe what someone will be able to do, under which conditions, and how acceptance will be demonstrated.
For the catalogue example, specify the supported product families and markets, the customer actions enabled, and the validation required. This creates a basis for evaluating whether the combined workstreams deliver the commitment.
2. Identify the information behind the next decision
Select a real question, such as whether the capability is ready for release.
Connect only the information needed to answer it: scope, critical dependencies, unresolved decisions, responsible owners, and acceptance evidence. Record where each item is maintained and when it was confirmed.
Use existing systems where they can support these connections. Avoid creating a parallel copy of information that already has an authoritative owner.
3. Make one change travel through the model
Test the model with an actual change to a requirement, dependency, or release condition.
Check whether the affected owners and commitments can be identified.
Review the consequences with those owners and preserve the approved decision alongside the affected work. Missing connections will reveal where the model needs improvement.
4. Use the model in the leadership review
Prepare the executive view from the maintained information. Show the decision required, its consequences, the evidence, and the remaining uncertainty.
Retain a dated record of what leadership approved. A current operational view and a historical decision record serve different purposes, and both matter.
5. Measure whether management improves
Compare the effort required to answer the decision question before and after the pilot. Track manual reconciliation, unresolved dependencies, and whether approved changes reach the affected teams.
Expand the approach when these results justify the maintenance effort.
Leadership must make the information matter
Software cannot resolve an ownership dispute or secure business commitment by itself. A connected model makes those issues visible, but someone still has to act.
The organisation needs agreed meanings for status and readiness, clear decision rights, and a routine for maintaining important information. If leadership continues to request separate reports with independently revised facts, teams will have to maintain both approaches.
For the CEO, the test is whether investment can be traced to a usable outcome. For the CIO, it is whether technical dependencies and release conditions support that outcome. For the transformation director, it is whether decisions lead to coordinated action across the workstreams.
PowerPoint can continue to communicate the answer. The management system beneath it should preserve how the answer was reached and what happens next.
At your next transformation review, select one promised business outcome. Ask the team to trace it to the work, dependencies, owner, and acceptance evidence while you are in the room.
The effort required to make that connection will tell you where to begin.
References - End of Power Point Project Management
Tags:
Comments