There is No Magic Ring of Power

Summary

• It's tempting to see project management software as the solution to project management problems, but, in the world of software development, it's a false hope.
• Project management software suffers from misaligned incentives, offers false precision, and disguises a huge investment in developing a shared information architecture. These problems will lead to frustrated teams, stakeholders, management... and project managers.
• Spreadsheets and a good understanding of what's important to stakeholders can meet the tracking needs of even large software projects. When they can't, the best solution is often organizational design, not more software.
• Despite these shortcomings in the world of software development, project management software tools can be invaluable in domains where the path to success is understood and task durations are more reliably predictable—such as physical construction projects.

Hot Take

If you have a problem organizing your team’s work and hitting its deliverables, and you move the team over to using project management software, now you have two problems. For most projects involving software development, project management software is worse than a waste of time.

You know the “One Ring” in J.R.R. Tolkein’s Lord of the Rings? Project management software has a lot in common with it:

• People think it grants immense power (everyone wants it, right?)
• It does… sort of… but it’s not the power most people really need (turning invisible is cool, but has its limits), and…
• It’s a trap: over time it takes over your soul, and you become its servant, rather than it serving you (see, for instance, Gollum…)

I know: for many readers, these will be fighting words! Let me explain.

Project Management Software Won’t Save You

I remember a conversation with a Senior Director at a big tech company who’d just been hired for a Technical Program Management (TPM) role and put in charge of a large team of software development TPMs. They were new to the company, and they’d never been a TPM before. The two of us were talking about the state of their new organization, and the steps they planned to take to improve its performance.

High on this Director’s list of things to do: acquire, deploy, and mandate the use of a suite of “enterprise” project management tools. Their plan was that this would improve operations by guiding their team to follow best practices in project management, and by saving them time through automation of reporting.

Gentle reader, I’d seen this movie before (eight times, in fact…) and, except in specific situations (which we’ll get to), the movie always ended the same way:

• TPMs were frustrated by the amount of extra work they needed to do to “feed the system”, with no benefit to themselves.
• Stakeholders were frustrated because they now received beautiful project diagrams and reports which didn’t address the key things they needed to know… and which were always wrong, anyway.
• Management was frustrated because the promised benefits of the project management software never materialized; the only thing that changed was that now their teams and stakeholders were complaining to them all the time. Management would usually put the failure down to “resistance to change” from their org.

I’ve seen this pattern repeat over and over again when trying to fit software development projects into the shapes required by project management tools. Everyone wants The One Ring, but when they get it, they don’t get what they expected.

Before I get into why that is, and what you can do about it, let’s clarify a few things:

• I’m talking here specifically about project management of software development projects.
• I’m going to use the term “project tools” as a shorthand for software systems designed specifically for project management; for example, Microsoft Project, Primavera, Monday, Asana, etc. I’m not including issue trackers or workflow management systems. Things get a little weird because products in these other categories sometimes add project management features, and vice versa.

Now when I say “project tools” you’ll know what I’m talking about. 😀

What’s Wrong With Project Tools?

People often have a picture in their heads of what project tools will do for them, that includes things like:

• We won’t have to ask anyone for status updates, because everyone working on the project will just enter their updates into the tool themselves.
• Because all dependencies—including between teams—can be tracked in the tool, any change of dates or status will automatically ripple through the system, ensuring there’s always accurate information about delivery dates.
• We won’t have to produce reports on project progress, because the tool will generate reports for us.
• We’ll have a single “source of truth” for all our projects. Anything anyone wants to know will be available in the tool.
• The tool will force everyone to be consistent about how projects are run, how terms are used, and more.

Well… sorry to be blunt, but those ideals are all fantasies.

There are a three deep problems that dash all these hopes:

Misalignment of incentives

Most of your team members and members of other teams don’t receive any benefit from doing the boring, detailed work of inputting task estimates and progress status information… so they’re simply not going to do it. If they’re threatened by management, they’ll report… something… but data accuracy will be terrible.

One project tool implementation I observed at close range took years of hard work by dozens of smart people, but ultimately didn’t deliver on its promises because not even program managers saw any value in maintaining it, let alone engineers. It was seen as something to keep track of VP-level portfolios far up in the stratosphere, way above the people who had to put in extra hours to keep the system fed with new data.

This all changes if the team sees a clear benefit to providing the information—engineers are usually happy to keep issue trackers up-to-date, for example, because their own work depends on it. Indeed, Google built a great project tool on top of its issue tracker—issues (“bugs”) were treated as “tasks” that you could build higher-level project structures from. With that approach, engineers were happy to keep project data current, because it directly benefited them. That’s not how commercial project tools usually work, though.

False precision

There are some domains where project tools work well and provide serious value (see below), but they are generally domains where there’s a known, well-trodden path to project success. Software development is usually not that: in software, if someone has solved the problem you’re working on before, you can usually just use what they did (copy it, license it, etc.). In most software projects, though, most of the work is building things that no one has built before.

If you ask an electrical contractor how long it will take their team to wire up a building of a given size, type, and condition, they can probably give you a solid estimate—they’ve done this before. If you ask a software engineer how long it will take their team to build a complex software system, they will have a hard time giving an answer… and when they do come up with one it will often be way off—not because they’re bad at estimating, but because there’s no basis for estimating!

Tie these two problems together, and you end up with a fine example of a time-honored maxim in computer science, “Garbage In, Garbage Out”; whatever automated reporting and algorithmic rescheduling your project tool is theoretically capable of won’t matter if the data you’re able to feed it is somewhere between sketchy and just plain wrong. And if the people responsible for feeding it don’t receive any benefit from doing so in the first place… well, you get the point.

These problems were some of the key drivers behind the genesis of Agile software development approaches (also: here’s a great article that goes into depth about how tech companies do software project management).

Information Architecture

A third deep problem with using project tools for software projects is tied to another computer science principle: “There are only two hard things in Computer Science: cache invalidation and naming things.” (quoting Phil Karlton)

“Naming things” is relevant here because, it’s harder to get people to use the same project frameworks, methodology, and terminology, then it is to align incentives or to get accurate project information. Here are some examples to illustrate this point:

• Status indicators like “red”, “yellow”, and “green” will be misleading if people don’t agree on unambiguous definitions of what each color means. When you say your project is “yellow”, is that the same as my “yellow”, or is it more like my “red”? I’ve seen closely-linked projects span the spectrum despite being in the same state; I’ve also seen every project in an organization change colors depending on what executive leadership says at program review meetings, too.
• I remember a TPM (Technical Program Manager) on my team telling me about a serious problem: a team had committed to delivering a working API in “Q3”... but we were well into Q3 and there was still no API, but the the team kept insisting they were on schedule. It turned out that while the team that needed that API had assumed Q3 meant “July 1”, the team making the commitment had actually meant “September 30”. (Sadly, this really happened, and the impact was visible to customers; we always used full dates for commitments, after that!)

These are trivial examples that are easy to resolve once you know about them; there are many, many others, though, that require careful thought, and a concerted communication effort to get everyone on the same page—what standard milestones should every project have? What criteria decides which projects need to follow the methodology and terminology standards? Do you organize work in your project tool using tags, categories, or a naming convention? On and on.

People often think that using a project tool will make these problems go away, because they’ll enforce standardization. Unfortunately, “opinionated” tools that only let users do things one way can only be sold to one customer; to sell to many customers, software vendors need to make their tools flexible, accommodating a kaleidoscope of approaches. And reader, I promise you: if a tool lets users do things in 10 different ways, people in your company will use all 10! The flexibility vendors need to build into their tools to expand their market makes the whole “information architecture” problem worse.

So What Can You Do About This?

So if a project tool isn’t going to deliver what you want, what will? Let’s start by asking what it is you’re really trying to achieve. At the root, what most people are looking for is something to help them keep track of who’s responsible for what, and when they’re supposed to deliver it. Something you can use to make sure the ball isn’t being dropped and important steps aren’t being skipped. A reference you can go to to give yourself a quick overview of the current state of play.

90% of the time (maybe more), the perfect tool for this is… a spreadsheet. A commercial project tool might be prettier, but it’s not going to be easier to use, and it’s certainly going to be harder to adapt to your particular situation.

What about generating reports for management and senior stakeholders? Well, what do they actually want? Do they want to dive deep into the fine details of your project? Do they want to hear, week after week, that you’re in “yellow” status (or “green”, or whatever)? Or that you’re now “40% complete”? I suggest they don’t care about any of that, and that to the extent they do, telling them you’re “yellow” or at “40%” is not just unhelpful—it can be misleading, too (e.g. what does “40% complete” even mean for a software project?).

Here’s what they really want to know: are things going ok? Any surprises? Do you need any help?

I’ve got to believe that if you found yourself face-to-face with a senior stakeholder—say, in an elevator for a minute or two—that, without any prep or reference materials, you could give them a quick verbal update that told them exactly what they wanted to know—no software tools required! You could do this because you’re actively involved in the effort, keeping track of details in a spreadsheet or notebook or whatever approach works for you. You already know what your critical path is and what your key risks are because of the work you’re doing every day—you don’t need a project tool to run an analysis on your dependency network to figure them out.

What I’m saying here is: don’t sell yourself short—I’ve seen TPMs and engineers successfully manage large development efforts with spreadsheets and their wits.

One could make an argument that when enough people are involved those spreadsheets can become unwieldy, and you need something more formal to manage project data and communications. I understand their siren call… but for all the reasons I outlined earlier, I strongly believe they’ll fail to deliver on their promise. A better approach, in my opinion, is to see these situations as a signal that the work isn’t partitioned in the best way, and the problem is better thought of as something to be solved by organizational design.

When Are Project Management Tools Useful?

As I alluded to a couple times above, there are cases where project tools are valuable, even indispensable. What most of these situations have in common is that while the projects they’re dealing with may be large and complex, they’re nevertheless predictable. I had experience at Google with projects of these sorts that built data centers and the network that connects those data centers together. Both cases involved large numbers of workers, in many different disciplines, over a period of years. Despite the scale, the component pieces of these projects, in themselves, are well understood and predictable:

• People know how to do each part, know how much equipment and raw material will be required, the need for how many hours of labor of which skills, and so on.
• Most of the workforce is fungible within specialties. For data centers: electricians can trade off work between each other, as can carpenters, plumbers, etc. For networks, deployment engineers often specialized in different types of technology or different geographic regions, but could often fill in for each other when the workload required it.
• Contractors and subcontractors are generally paid either for hours worked (easy to measure) or for progress or milestones achieved (easy to measure). The prospect of payment aligns incentives around status reporting. For employees, most work was done in sections that were either finished or not, again making progress easy to measure.

Project tools are a good fit for projects like this.

How You Can Bring Order From Chaos, Today

Please don't be like Gollum chasing after the Ring of Power, only to have it twist his body and mind! Be like Frodo, and his trusty blade spreadsheet!

Here are some things you can do now to apply these ideas:

• If you are having trouble getting data from your project team (e.g. status), consider “what’s in it for them”? How could you align incentives, so they see a benefit to providing you with the information you need?
• Develop an “elevator pitch” for your project. Ignore what status reports are “supposed to be”; ask yourself what a senior stakeholder would really want to know about it, in 1–2 minutes? Look at your current status reports; do they convey what your elevator pitch would? If not, how can you adjust the format, content, and cadence of your reports to make them more useful?
• If you are longing for a professional project tool to make your life easier, think about: what are you hoping it will do for you? How are you hoping it will make your life better? Are there easier ways you could achieve the same thing?

Want to Learn More?

• How Big Tech Runs Tech Projects and the Curious Absence of Scrum, in Gergely Orosz’ Pragmatic Programmer newsletter. He summarizes from his own experience (Uber, Skype, Microsoft, etc.), plus from what he’s learned from speaking to engineers at many different companies.

What Do You Think?

I'd love to hear about your experiences with project tools! Have you had a different experience with them than I have? Found situations in software development where they’re more useful? If you're a paid supporter of this newsletter (hint, hint!) you can add comments below.