History of Project Management Software: Part I
Jira, Asana, Trello, Linear, ClickUp. If you work in software, it’s likely either you currently are using one of these project management tools (or a homegrown facsimile) at your business or you have in the past. They are practically ubiquitous. But maybe, like me, you’ve occasionally wondered what value they actually add? How did projects ever get finished before we had these tools? Let’s explore.
Early history
In the long-ago era of the 1900s we didn’t have any of the fancy cloud-based project management solutions. In the first half of the century there were some initial approaches inspired by Frederick Taylor’s scientific management, such as the now-infamous Gantt charts (~1910). It wasn’t until the 1950s that more structured project management techniques were developed, perhaps most notably the US Navy’s PERT (Program evaluation and review technique), which creates a network of nodes representing tasks and times to complete them. It’s not a coincidence that this occurred at the same time as digital computers started to be used by large organizations, indeed the possibility of computing such data about projects was a driving force in the development of these methods. As soon as computers were available, it didn’t take long for planners to start using them to attempt to improve the success of their projects.
Computer project management
As computers became more and more widespread in the 1960s and 70s, it is not surprising that developers of project management techniques started heavily applying them to software itself (the now-widespread practice of dogfooding). The Waterfall method was widely used in practice, although even in 1970 it was already being criticized because issues only discovered in later testing phases could mean “a major redesign is required” or even “the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs”[1].
Microsoft Project launched in 1984, and while it wasn’t the first commercial project management software, it did bring it to a much broader audience. It would be hard for anyone used to today’s tools to recognize, as it focused far more on scheduling and cost analysis than on coordination and planning. It would take a more significant change to bring us into the modern era of project management–the web.
Confluence
With the rise of the web in the 1990s, software developers suddenly had a way to ship code much more rapidly than before, either through offering downloads or via the content of their web sites. This led to a demand for faster iteration on the software itself (if it takes 6-12 months to ship CDs or floppies, it matters less how fast you build the code). It also meant that users could interact directly with developers, identifying and reporting bugs and helping to evaluate potential features. This led to a confluence of events that gave birth to the modern era of project management:
1998. Bugzilla, written by Terry Weissman at Netscape, was released as the first web-based open source bug tracker. Originally intended to track bugs for their project to open source the Navigator browser (which became Mozilla), it was quickly adopted by the broader open source community.
1999. SourceForge launched as a site for hosting open source projects, including bug reports.
2001. The Agile Manifesto is published, an attempt to steer the software industry away from heavyweight, documentation-driven development processes.
2002. Jira, Atlassian’s commercial bug tracker, first launched. It would later expand to include practically every imaginable feature.
One notable issue that slowed down adoption of these services was that they required hosting. This limited how fast adoption and iteration could happen. The subsequent decade saw a rise in “cloud-based” software, and project management was no different. In 2008 Asana was founded by ex-Facebook engineers Dustin Moskovitz and Justin Rosenstein, inspired by some tools they had built internally. They launched it to the public in 2011. The same year Trello launched as cloud software and Jira launched a cloud version as well. This was huge for adoption, since it meant a small team within a larger organization could join independently without relying on IT to set up the software.
Convergence
With the move to the cloud, the switch to periodic billing means that software cannot be developed as a static set of features that are sold once. When you are paying monthly, you expect some ongoing improvements, and so project management software started adding those features. By this point “waterfall” was a dirty word and the industry had converged on Agile as the one true path to developing software (of course no one actually agreed as to what that meant). This led to a convergence of features, with every project management tool adopting essentially the same set by around 2020: Gantt charts, dependencies, portfolios, burndown charts, sprints, and so on. Even latecomers like Linear, specifically built as a leaner alternative to the heavyweight concepts of Jira, offer many of the same features now.
And the build-up of these features came at exactly the “right time” for these companies to capitalize on the huge increase in remote work as a result of COVID-19. With everyone distributed, perhaps across many timezones, it became more important than ever for managers to track the progress of their teams. Without being able to “pop by” unannounced at someone’s desk to check on their project, how would you know the state of the world? Well, that’s where project management comes in. The pretty charts and colorful graphs will obscure any lack of understanding and make you confident that you know what’s actually going on.
With the convergence of features and the widespread adoption of these tools by distributed teams, today it barely matters which of the tools you use. Whereas before there was a big difference between shops using Jira and those using Asana, now they largely overlap, and it’s much more about how they are being used. Despite their origins in the Agile Manifesto, many of the approaches have now veered directly towards “processes and tools” over “individuals and interactions” (exactly the opposite of Agile is about).
And… perhaps to that we should also add “whether” they are being used? For… despite the near ubiquity of these solutions, nowhere did I explain what value they actually bring. To learn that you’ll have to wait until next week for part two of this series.
Don’t these look pretty much the same?
