In this BONUS episode, we dive deep into The Project Management Trap, continuing our exploration from Episode 1 where we established that software is societal infrastructure being managed with tools from the 1800s. We examine why project management frameworks – designed for building railroads and ships – are fundamentally misaligned with software development, and what happens when we treat living capabilities like construction projects with defined endpoints.
The Origin Story – Where Project Management Came From
“The problem isn’t that project management is bad. The problem is that software isn’t building a railroad or a building, or setting up a process that will run forever (like a factory).”
Project management emerged from industries with hard physical constraints – building the Transcontinental Railroad in the 1860s, coordinating factory machinery, managing finite and expensive materials. The Gantt chart, invented in the 1910s for factory scheduling, worked brilliantly for coordinating massive undertakings with calculable physics, irreversible decisions, and clear completion points. When the rails met, you were done. When the bridge was built, the project ended. These tools gave us remarkable precision for building ships, bridges, factories, and highways. But software operates in a completely different reality – one where the raw materials are time and brainpower, not minerals and hardware, and where the transformation happens in unique creative moments rather than repeated mechanical movements.
The Seductive Clarity Of Project Management Artifacts
“In software, we almost never know either of those things with certainty.”
Project management is tempting for software leaders because it offers comforting certainty. Gantt charts show every task laid out, milestones mark clear progress, “percent complete” gives us a number, and a defined “done” promises relief. The typical software project kickoff breaks down into neat phases: requirements gathering (6 weeks), design (4 weeks), development (16 weeks), testing (4 weeks), deployment (2 weeks) – total 32 weeks, done by Q3. Leadership loves this. Finance can budget it. Everyone can plan around it. But this is false precision. Software isn’t pouring concrete where you measure twice and pour once. Every line of code is a hypothesis about what users need and how the system should behave. That 32-week plan assumes we know exactly what to build and exactly how long each piece takes – assumptions that are almost never true in software development.
The Completion Illusion
“Software products succeed by evolving. Projects end; products adapt.”
“Done” is the wrong goal for living software. We expand on the Slack story from Episode 1 to illustrate this point. If Slack’s team had thought in project terms in 2013, they might have built a functional tool with channels, direct messages, file sharing, and search – shipped on time and on budget by Q2 2014, project complete. But that wasn’t the end; it was the beginning. Through continuous user feedback and evolution, Slack added threaded conversations (2017), audio/video calls (2016), workflow automation (2019), and Canvas for knowledge management (2023). Each wasn’t maintenance or bug fixing – these were fundamental enhancements. Glass’s research shows that 60% of maintenance costs are enhancements, not fixes. By 2021, when Salesforce acquired Slack for $27.7 billion, it bore little resemblance to the 2014 version. The value wasn’t in that initial “project” – it was in the continuous evolution. If they’d thought “build it, ship it, done,” Slack would have died competing against HipChat and Campfire.
When Projects Succeed (Well, Some Do, Anyway) But Software Fails
“They tried to succeed at project management. They ended up failing at both software delivery AND project management!”
Vasco references his article “The Software Crisis is Real,” examining five distinct cases from five different countries that represent what’s wrong with project thinking for software. These projects tried hard to do everything right by project management standards: detailed requirements (thousands of pages), milestone tracking, contractor coordination, hitting fixed deadlines, and proper auditing. What they didn’t have was iterative delivery to test with real users early, feedback loops to discover problems incrementally, adaptability to change based on learning, or a “living capability” mindset. Project thinking demanded: get all requirements right upfront (otherwise no funding), build it all, test at the end, launch on deadline. Software thinking demands: launch something minimal early, get real user feedback, iterate rapidly, evolve the capability. These projects succeeded at following project management rules but failed at delivering valuable software.
What Software-Native Delivery Management Looks Like
“Software is unpredictable not because we’re bad at planning – it’s unpredictable because we’re creating novel solutions to complex problems, and in a completely different economic system.”
If not projects, then what? Vasco has been exploring this question for years, since publishing the NoEstimates book. The answer starts with thinking in products and capabilities, not projects – recognizing that products have ongoing evolution, capabilities are cultivated and improved rather than “delivered” and done, and value is measured in outcomes rather than task completion. Instead of comprehensive planning, we need iteration and constant decision-making based on validated hypotheses: start with “We believe users need X,” run experiments by building small and testing with real users, then learn and adapt. Instead of fixed scope, define the problem (not the solution), allow the solution to evolve as you learn, and optimize for learning speed rather than task completion.
The contrast is clear: project thinking says “We will build features A, B, C, D, and E by Q3, then we’re done.” Software-native thinking says “We’re solving problem X for users. We’ll start with the riskiest hypothesis, build a minimal version, ship it to 100 users next week, and learn whether we’re on the right track.” The appropriate response to software’s inherent unpredictability isn’t better planning – it’s faster learning.
References for Further Reading
- Vasco Duarte’s article on the Software Leadership Workshop newsletter: “The Software Crisis is Real”
- Glass, Robert L. “Facts and Fallacies of Software Engineering” – Fact 42: “Enhancement is responsible for roughly 60 percent of software maintenance costs. Error correction is roughly 17 percent. Therefore, software maintenance is largely about adding new capability to old software, not fixing it.”
- NoEstimates Book: How To Measure Project Progress Without Estimating
- Slack evolution timeline: Company history and feature releases
- The unexpected design challenge behind Slack’s new threaded conversations
- Slack voice and video chat
- Slack launches admin workflow automation and announcement channels
- Meet Slack Canvas – Slack’s answer to the knowledge management problem.
About Vasco Duarte
Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success.
You can link with Vasco Duarte on LinkedIn.
Vasco Duarte is a thought leader in the Agile space, co-founder of Agile Finland, and host of the Scrum Master Toolbox Podcast, which has over 10 million downloads. Author of NoEstimates: How To Measure Project Progress Without Estimating, Vasco is a sought-after speaker and consultant helping organizations embrace Agile practices to achieve business success.