This is part of an ongoing series. It continues from Evaluating a Root Cause. Visit Walking, Peanuts, and Systems if you’d like to start at the beginning.
Hypothesis for invalid assumption:
We assume uncertainty is binary. We know nothing, or we know everything.
Maybe Not
After thinking some more about it, I’m less than convinced that my hypothesis is correct.
The common knowledge of “known unknowns” and “unknown unknowns” show that we recognize the difference. Goldratt talked about our language being a useful guide for determining our intuition. That our common language contradicts my hypothesis is a bad sign.
Next, if we made uncertainty visible, would we have to fundamentally change Jira or how people use it? I don’t think so. Changing Gantt chart start/end dates to start/end ranges is a conceptually straightforward change. Nothing significant would change about how projects are managed.
If we made uncertainty visible in Jira, would that turn around project delivery performance? Would certainty scores on projects change anything? More bluntly: would this metric or report be the one that fixes Jira? No, no, and definitely no.
Back to the Drawing Board?
I still believe uncertainty is key. I also think there are a few ideas I can put together for guidance:
- Cost accounting says that any improvement within the system improves the system. Throughput accounting says only improvements at the constraint improve the system.
- In Beyond the Goal, Goldratt points out that most project management follows the same rule: the way to make the entire project finish on time is to ensure that every task finishes on time.
- In The Goal, rather than try to manage the complexity of every machine in the plant, the solution is to manage the complexity at the constraints. The hard management is isolated at managing the buffers and capacity of the constraints.
- Object oriented programming has lots of strategies for managing state throughout the program. Clojure recognizes that state is hard, so it isolates the hard part of managing state. State lives at the edges, and that makes up a small part of the program. The majority of the program is easier pure functions.
To summarize:
- There are examples of isolating the hard part rather than removing it.
- There are examples of people assuming we have to manage the hard part everywhere.
Hypothesis 2.0
Invalid assumption: to successfully deliver a project, we must manage uncertainty everywhere.
Waterfall and Agile both assume this. The difference is in how each methodology chooses to manage the uncertainty.
Correction: to successfully deliver a project, we should isolate uncertainty and manage it there.
Now that I’ve put those thoughts together, I realize I’m just retreading similar ground to end up at Goldratt’s suggestions in Critical Chain. Maybe his way of thinking is so well-trod in my mind that it was bound to happen. I’m choosing to take it as a good sign because it was a surprise to end up here. Seeing similar strategies in e.g. Clojure is another good signal.
Jira, et al
My hypothesis points to the problems with current project management tools. There is no focusing mechanism. There is no strategy that helps isolate and manage uncertainty. Part of Jira’s selling point is its many features and how customizable it is. Competitors race to copy those features, mostly making them faster and better looking. Jira can be described as a large collection of tools, and it’s the user’s job to come up with a project management strategy for using those tools.
Successful project management strategies certainly aren’t obvious to me, so I expect the average user to have limited success if only handed a big bag of tools.
Next Steps
- Revisit my CRT. I knew it wasn’t perfect, so it’s not surprising that I need to square it with my new hypothesis. The CRT is important for future steps, so I can’t just abandon it.
- Think through the suggestions in Critical Chain. Those suggestions will likely play a significant role when I create my Future Reality Tree (FRT).