The Cost of Underinvesting in Project Management Tooling
Updated: 2 hours ago
One of the most overlooked risks in project delivery is not strategy, funding, or resources. It is the absence of fit-for-purpose project management tooling.
In one of my engagements, like many other project professionals at some point in time, I found myself leading the mobilisation of a significant transformation initiative consisting of multiple 10 wk and 12 to 13-week delivery increments. The project was considered strategically important, highly visible, and foundational to future customer outcomes. Yet despite its importance, the organisation did not provide the project management tooling necessary to effectively plan, coordinate, track, and govern delivery.
The experience reinforced a leadership lesson that organisations often learn too late: when you ask a project manager to deliver without the appropriate tools, you are not reducing cost. You are increasing risk.
Professional Independence and Tool Neutrality
Before discussing specific technologies, it is important to note that my perspective is intentionally product-agnostic. I do not promote, endorse, receive commissions, incentives, gratuities, or any commercial benefit from any project management, portfolio management, or work management platform referenced in this article.
My position is based solely on ensuring all stakeholders are accountable for their assigned outcomes, delivery outcomes, governance requirements, and the practical realities of leading complex programmes and projects.
Whether the solution is Microsoft Project, Azure DevOps, Jira, ServiceNow PPM, Monday.com, Smartsheet, Planview, Asana, Trello, or any other platform is largely irrelevant. The discussion is not about advocating for a particular vendor or product. It is about ensuring that project managers and delivery teams are equipped with fit-for-purpose tooling that aligns with the delivery methodology, governance model, organisational culture, and project complexity.
Throughout my career, I have successfully delivered initiatives across multiple technology ecosystems and organisational environments, and project methodologies. My focus has always been on selecting and utilising the most appropriate tools available to support transparency, accountability, traceability, collaboration, and successful outcomes.
The central argument is therefore not that one tool is superior to another. Rather, it is that organisations should (endeavour to try and) avoid allowing licensing constraints, historical preferences, organisational silos, or technology allegiances to dictate delivery approaches when those decisions ultimately increase project risk and reduce the likelihood of successful outcomes.
In short, successful delivery is rarely determined by the brand name on the tool. It is determined by whether the organisation provides delivery teams with the capabilities required to execute effectively.
The Situation
The tooling available to me was limited primarily to:
Microsoft Excel
ServiceNow PPM
While ServiceNow PPM could support milestone reporting and high-level schedule visibility, it was not configured to support the practical realities of delivery management.
More critically:
Project team members were not provisioned access (within PPM)
Task owners could not be assigned and therefore could not directly update activities.
Contributors lacked visibility of dependencies.
Day-to-day work management was largely disconnected from executive reporting.
The obvious alternatives already existed within the organisation. Products such as Jira and Azure DevOps were available elsewhere in the ecosystem, yet access to these products that would provide a Scrum or Kanban style board was not provided. Whether this was due to licensing, cost controls, governance decisions, limited understanding and maturity, or organisational inertia is ultimately secondary. The outcome was the same: a modern delivery methodology was expected without the tooling required to support it. As I did find out later on, the ‘secondary’ was due to a wedded decision made that involved a past executive, their decision-making and funding – that left an indelible and unusable legacy for most involved in delivery. As I came to better understand, that was perhaps a level of organisational pride and naivety that this then was the only way forward. Until something really doesn’t work – or breaks. Or both.
As a consultant, I held my own Microsoft Project licensing through my business. However, using personal or external tooling would have breached professional standards around information security, intellectual property protection, and organisational governance. Therefore, that option was rightly off the table.
What Happens When the Right Tools Are Not Available?
Leaders (and clients when posed with this quandry) should ask themselves a simple question:
What are you actually prepared to accept when you choose not to provide the required project tooling?
Because the consequences are rarely limited to inconvenience.
You are implicitly accepting:
Reduced transparency
Weaker accountability
Increased reporting overhead
Greater delivery risk
Lower forecast accuracy
Decreased stakeholder confidence
The challenge becomes particularly acute when projects require genuine cross-functional collaboration. Throughout my consulting career and across numerous project engagements, one consistent observation has emerged: successful delivery depends as much on the operating model and tooling as it does on the technical capability of the individuals involved.
In this particular case, several technical leads and SMEs were accustomed to operating within their own specialist disciplines rather than as members of a cross-functional delivery team accountable for shared outcomes. While highly capable in their respective domains, the concept of collective ownership across planning, delivery, dependency management, and reporting was less mature.
Without a common task management platform (and the ability to move from ‘left to right’), there was no single source of truth through which ownership, priorities, progress, risks, actions, and dependencies could be aligned and managed. As a result, the project manager effectively became the integration layer between workstreams, stakeholders, and delivery teams.
This often meant that the project manager became the central point of contact for every conversation, decision, dependency, and status update. Information that should have been visible and accessible through tooling instead resided within meetings, email threads, personal notes, or the project manager's own tracking mechanisms. Tasks were discussed, actions agreed upon, and dependencies identified, but they were not always visible to the broader team in a transparent and traceable manner.
While this may appear manageable in the early phases of a project, it is neither scalable nor sustainable as complexity increases, or when managing parallel streams of work. More importantly, it creates significant operational risk at project closure.
When a project manager carries the weight of coordinating and maintaining delivery knowledge that should otherwise exist within a shared system, there is a real danger that critical context leaves with the project manager when the engagement concludes.
Project team members often return to their operational responsibilities, and without effective knowledge transfer, clear ownership structures, and accessible delivery records, organisations can struggle to establish the new operational baseline required to sustain the change that has just been delivered.
Ultimately, the absence of appropriate tooling not only impacts project execution but also undermines long-term adoption, ownership, and value realisation. The project may technically be delivered, but the organisation risks failing to fully embed, support, and capitalise on the outcomes it invested in creating.
The Pitfalls from a Project Management Perspective
Loss of Traceability
Without a dedicated delivery platform, linking requirements, tasks, owners, dependencies, risks, issues, and milestones becomes increasingly difficult.
Project artefacts become fragmented across emails, spreadsheets, meetings, and status reports.
Eventually, nobody is entirely confident where the latest information resides.
Administrative Overhead Replaces Leadership
Project managers ‘should’ spend their time driving outcomes, removing blockers, managing risk, and engaging stakeholders.
Instead, they become manual data administrators.
Hours are spent updating spreadsheets, reconciling status updates, and producing reports that ‘modern’ tooling would generate automatically.
Reduced Accountability
People are more likely to take ownership when responsibilities are visible to the wider team.
Without a shared board or task management platform, ownership becomes blurry.
Tasks are discussed but not recorded. Commitments are made but not tracked. Dependencies are identified but not monitored.
The result is predictable: slippage and risk.
Inability to Scale Governance
As complexity grows, ‘spreadsheet-based’ management quickly reaches its limits.
What may be manageable for twenty tasks becomes problematic for two hundred.
Without proper tooling, governance maturity remains constrained regardless of the capability of the delivery team.
The Pitfalls from a Client Perspective - Limited Visibility of Reality
Senior stakeholders often believe they have visibility because they receive milestone reports.
In reality, they are seeing outputs rather than (real) delivery health.
Without integrated task-level tracking (with accountable owners), emerging issues are often discovered far later than they should be.
Increased Cost of Delivery
Ironically, refusing relatively minor investment in project tooling typically increases project costs elsewhere.
The organisation pays through:
Longer mobilisation periods
Increased administration effort
More meetings
More manual reporting
Delayed decision-making
Reduced productivity
The cost is simply transferred rather than avoided.
Lower Confidence in Reporting
When reporting relies on manual collection and consolidation, confidence in schedule forecasts naturally decreases.
Executives (should) begin questioning the data because the delivery mechanisms behind the data are weak.
Greater Risk of Underdelivery
Perhaps most importantly, delivery outcomes become constrained by the operating environment.
Even highly capable project managers and technical teams can only compensate for tooling deficiencies to a certain extent.
Eventually, the absence of appropriate tools becomes a delivery risk in its own right.
Culture Matters as Much as Technology
This experience also highlighted that tooling and culture are inseparable.
(For this project, it was important for) Modern delivery approaches rely on transparency, accountability, collaboration, and shared ownership.
A Scrum board, Kanban board, Azure DevOps workspace, or Jira project is not simply a technology solution. It is a behavioural enabler.
It creates visibility.
It encourages ownership.
It reinforces accountability.
It supports collaboration across disciplines.
Without these mechanisms, teams naturally retreat to familiar silos.
The outcome is often a collection of individual contributors rather than a cohesive delivery team.
A Question for Leaders
If a project is important enough to be labelled strategic, transformational, or foundational, then it should be important enough to be equipped properly.
Leadership teams should ask themselves:
Are we selecting tools because they best support delivery outcomes, or because they are simply the tools we already have?
There is a significant difference.
Being wedded to a particular platform because "that is how we have always done it" can create hidden constraints that undermine the very value the organisation hopes to realise from its investment.
The reality is simple: successful projects require more than talented people and good intentions. They require an environment that enables delivery. Appropriate project management tooling is not a luxury or an optional enhancement. It is a fundamental control mechanism that supports accountability, transparency, governance, and ultimately successful outcomes.
When organisations choose not to provide those tools, they should do so with full awareness of the risks they are consciously accepting.
Let me be clear: this is not an argument for product-specific tooling, be it Microsoft Project, Azure DevOps, Jira, ServiceNow PPM, or any other specific platform. I am largely product-agnostic and neither promote nor benefit from any of the project management tooling mentioned.
The issue is not vendor selection; it is organisational readiness. The real question for leaders (and clients alike) is whether they provide the delivery environment, governance controls, and tooling capabilities needed to give strategic investments the best possible chance of success.
When organisations fail to do so, they are not simply constraining project managers – whom are often jettison in to get ‘stuff done’, they are consciously increasing delivery risk and reducing the value of the investment they expect those projects to realise.
In Closing
The lessons from this experience extend beyond any single project, organisation, methodology, or technology platform. At its core, successful delivery is rarely constrained by a lack of capability, commitment, or intent. More often, it is constrained by the environment in which delivery teams are expected to operate.
Project management tooling should never be viewed as an administrative convenience or an optional overhead. It is a fundamental delivery enabler that supports visibility, accountability, governance, collaboration, traceability, and informed decision-making. When organisations underinvest in tooling, they do not eliminate cost. They simply transfer that cost into increased manual effort, greater delivery risk, reduced productivity, weaker governance, and lower confidence in outcomes.
Importantly, the debate should not be framed as "modern" versus "traditional" tools, nor Agile versus Waterfall. In reality, every delivery approach requires fit-for-purpose tooling aligned with the methodology, the initiative's complexity, governance obligations, and the organisation's maturity.
For Agile and product-led delivery environments, tools such as Jira, Azure DevOps, Monday.com, Trello, or equivalent platforms can provide the transparency, flow management, team accountability, and iterative planning and capabilities required to support Scrum, Kanban, and other adaptive delivery models. Equally, for projects operating within more structured or predictive delivery frameworks, tools such as Microsoft Project, Basal Edge’s PMO Essentials, ServiceNow PPM, Planview, Smartsheet, or similar solutions provide critical capabilities for schedule management, dependency tracking, forecasting, resource planning, and governance oversight.
Neither approach is inherently superior. The right tool is the one that enables teams to effectively execute, govern, and sustain delivery outcomes. Organisations should therefore resist becoming overly attached to historical technology choices, executive preferences, budget-driven compromises, or the assumption that one platform can support every delivery need regardless of context.
The key consideration for leaders (and clients alike) is not which product they choose, but whether the tooling ecosystem they provide genuinely supports the behaviours, controls, collaboration models, and decision-making required for successful delivery.
Ultimately, projects succeed when capable people are empowered by fit-for-purpose processes, governance, culture, and technology. The right project tooling, whether supporting Agile, Waterfall, hybrid, programme, portfolio, or product-based delivery, is not a luxury. It is a foundational investment in delivery success.
If an initiative warrants strategic funding, executive attention, and organisational change, it should also have the tools its delivery teams need to succeed. Anything less is not cost optimisation. It is the conscious acceptance of avoidable risk.
About the Author
Sarah Verity is a senior transformation, program delivery, PMO, and business advisory professional with more than two decades of experience leading complex business and technology initiatives across higher education, telecommunications, insurance, government, disability services, healthcare, and corporate sectors.
Throughout her career, Sarah has established and uplifted PMOs, led enterprise-wide transformation programs, implemented governance frameworks, and delivered strategic initiatives across both Agile and traditional delivery environments. Her experience spans portfolio management, organisational change, technology modernisation, operating model transformation, and delivery capability uplift.
Sarah writes regularly about project delivery, stakeholder management, leadership, governance, transformation, PMO capability, organisational maturity, and the practical realities of leading strategic change. Her insights are drawn from firsthand experience working with executives, delivery teams, and organisations navigating complex transformation challenges.
If you're planning to uplift, transform, innovate, or strengthen your delivery capability, Sarah welcomes the opportunity to discuss how experienced project management and business advisory support can help turn strategy into measurable outcomes.
Email: sarah@sarahverity.me
Website: sarahverity.com
Business Advisory Services: Two In The Hand Consulting
"Successful transformation is rarely about having the perfect methodology or tool. It is about creating the right environment where people, processes, governance, and technology work together to deliver sustainable outcomes." – Sarah Verity
Comments