This is part of an ongoing series. It continues from Finding a Root Cause. Visit Walking, Peanuts, and Systems if you’d like to start at the beginning.
Does our root cause make sense?
My hypothesis is that our inability to capture uncertainty is at the root of why there are so many problems with delivering projects on time. That is somewhat vague, so I need to better understand what the issue is.
One way to reframe the problem is by asking different questions: What makes project management hard? What would make project management easy?
Project management would be easy if the following conditions were true:
- The work required is known
- The available resources are known
- The dependencies are known
- The time required is known
- The communication required is known
If all of those things were known, project management would be turned into an intensive but straightforward optimization problem.
Realistic (hard) project management is the complete opposite of that:
- The work required is uncertain
- The available resources are uncertain
- The dependencies are uncertain
- The time required is uncertain
- The communication required is uncertain
So, the key difference that makes project management hard is uncertainty. We should make it easier to manage uncertainty.
That seems rather obvious. Obvious is good, because it makes it more likely that our thinking is logically correct. Obvious is bad, because, if it’s obvious, why has it not be solved?
What problems are the current solutions solving?
The symptoms I laid out have taken me into the project management domain. Tools like Jira are a good solution to consider. I’m by no means a Jira expert, but I’ve used it for numerous projects so my experience should be sufficient. What does Jira provide:
- Kanban board for tracking tasks
- Tools for tracking progress
- Tools for communication
- Location for documentation
- Gantt charts for planning
- Predictions based on statistics
- Backlog for tracking requests
- Reports
Something I think is worth noting: of all those features, only statistical based predictions really have uncertainty baked in. Everything else is treated as if uncertainty doesn’t exist (or is solved elsewhere).
All of those features are only useful once the uncertainty is removed. You only need a tool for communication once you know that you need to communicate. Gantt charts let you set a timeline, but they don’t enforce levels of certainty.
Default vs Possible
I don’t mean to imply that you absolutely can’t represent uncertainty in Jira or similar tools. But when I used Jira’s roadmap feature (i.e. Gantt chart), I had to set definite project delivery dates. If it’s possible to say a project will be finished in “about two weeks”, it wasn’t clear to me. And it certainly wasn’t enforced.
A Java and Clojure comparison is useful for explaining what I’m looking for. Clojure is built with Java, so, by definition, anything you can do in Clojure you can do in Java. The difference between the two languages is what is easy/hard to do, via defaults and enforcement.
Maybe we could represent uncertainty with all of the tools available in Jira. But I feel confident in saying Jira is not built with a focus on uncertainty, because none of the defaults or enforcements help you manage uncertainty.
Am I smarter than everyone at Jira?
If my thinking is logically correct, why isn’t Jira (or any of their competitors) solving it? Am I smarter than all of those companies? More insightful? Unlikely.
Inherent simplicity suggests that there is a core conflict that keeps us from solving root causes. The conflict is so ingrained that it keeps us from even attempting to solve the problem. We eventually cease to even consider it a problem. If that’s true, me coming up with a solution is more attributable to me actually making the attempt rather than me being smarter than everyone else.
So, if this uncertainty problem is a root cause, and providers are not solving it, we must identify a conflict that is well ingrained in how we think about project management. My next step is clear.