I originally discussed Gantt charts back in episode 62, but I found more history behind them while researching Scientific Management and Taylorism for episode 156. I originally thought to include this additional history in that episode, but it felt out of place - thus this separate episode to revisit Gantt charts.
Or listen at:
Published: Wed, 21 Dec 2022 16:11:18 GMT
Links
- Wikipedia: Gantt Charts
- Episode #62: Bad for ROI: The Gantt Chart
- Episode #156: The Pitch - the management practices of yesterday
Transcript
Hi. In this episode, I wanted to revisit a topic I've discussed previously - Gantt charts.
I originally discussed Gantt charts back in episode 62, but I found more history behind them while researching Scientific Management and Taylorism for episode 156. I originally thought to include this additional history in that episode, but it felt out of place - thus this separate episode.
Let's recap on what a Gantt chart is; from Wikipedia:.
"A Gantt chart is a type of bar chart that illustrates a project schedule. This chart lists the tasks to be performed on the vertical axis, and time intervals on the horizontal axis. The width of the horizontal bars in the graph shows the duration of each activity. Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements constitute the work breakdown structure of the project. Modern Gantt charts also show the dependency (i.e., precedence network) relationships between activities. Gantt charts can be used to show current schedule status using percent-complete shadings and a vertical "TODAY" line."
I expect most of you have seen a Gantt chart at some point in your life. It is an exceptionally effective method of conveying information about deterministic work for a project. It can be used to show the individual activities needed to complete the project along with estimated time scales and interdependencies - such as task B cannot start until task A is complete.
You may have noticed I've used the word "deterministic" in there, and I've been quite purposeful in that Gantt charts work best when all the work is deterministic - we know all the activities required to complete the project up front before we start - we know all the activities, how long each will take, who the work is best suited to, any inter-dependencies and the outcomes that will be delivered.
We often associate, and possibly correctly for deterministic work, that the Gantt chart is the plan for achieving a given outcome by given time with the given resources. And in truth, this shouldn't be unexpected, given the history of the Gantt chart.
The Gantt chart was popularised by Henry Gantt around 1910. Gantt was a contemporary and colleague of Frederick Winslow Taylor, the creator of Scientific Management or Taylorism. Henry Gantt's work is very much in a similar field as Taylor, building on the Scientific Management approach, with notable work being the popularisation of the Gantt chart and the Task and Bonus system - as a means of linking the bonus pay to managers of how well they taught their employees to improve performance.
While the Gantt chart bears Henry's name, the history actually predates Henry and is linked to work done in 1896. But Gantt made it a widely used tool by linking it to the improvements in manual labour coming from Scientific Management.
One of the key benefits for the Gantt chart is that it needs little, if any, training to understand it. It is an exceptionally good visual tool for delivering a lot of information quickly. Very much an example of a picture painting a thousand words.
And this is, at least to me, why Gantt charts are so popular and continue to be so today.
For me though, the problem with Gantt charts arises when they're use for non-deterministic tasks - tasks such as Software Development. Tasks that fall into the Complicated or Complex domain as described by the Cynefin framework - tasks that we do not know everything about up front - we will not know ahead of time all the activities to complete the task - we don't know how long each activity will be - we don't know who is best suited to do the work and we don't know the outcomes until we do it.
And if we don't know, the only thing we can do is guess.
Okay. Dirty little secret time - for all my negativity about Gantt charts, I have found them exceptionally useful. They can be an incredibly useful tool to explore the activities for any given piece of work. I find that I use them much less often than I used to, generally now favouring mind maps, but I have used them many times in the past to help me understand the dependencies and rough timescales of a complex series of activities.
So why then if I've used them myself, and I have to admit with success, would I advise against using them now?
Well, as an analogy, I could put a screw in using a hammer, but this is not the correct usage.
In the same way, a Gantt chart can be used as a tool for exploring Complicated or Complex activities - and a Gantt chart is great for visualising a plan for Clear deterministic work - but there is a difference between those two activities.
For the Clear deterministic work, the Gantt chart gives you the full directions to your chosen destination. Think of it like a list of written driving instructions with each and every turn written down in exacting detail. You follow the instructions, you get to where you want to go, and you could repeat that journey over and over again.
While with the Complicated and Complex, the non-deterministic, think about it as using something more like a satnav requiring constant updates on traffic conditions, roadworks, and even the best destination. No two journeys will be exactly the same.
Could you take a snapshot of the satnav before you start the journey? Yes, but there's no guarantee that the road conditions will remain the same as when you set off. And the bigger and the more complex the journey, the less likely the snapshot will give you the optimal journey.
And this is often where I find problems with using Gantt charts for Software Development. At the start of that project, that initial snapshot is distributed, the original plan, and this is unfortunately then taken the same way as it would be for deterministic work: it's expected to be complete and accurate.
Thus, when adjustments need to be made, this causes problems.
While, a Gantt chart is great for visualising those deterministic tasks, it is ill prepared for demonstrating the changeable nature of non-deterministic tasks. It simply can't cope with our journey looking one way yesterday and something different tomorrow.
And because it can't do that, it leads to confusion and friction.
Often with removed stakeholders assuming that the team are either not working to their commitments or not being competent enough to know the tasks ahead of time.
Thus one of the greatest benefits of a Gantt chart - that little, if any, training needed to understand it - is also its downfall when you try to convey the non-deterministic nature of Software Development.
When reading the Gantt chart, we will instinctively use it to apply a level of control that simply doesn't exist for non-deterministic work. We want to reduce risk and uncertainty and the Gantt chart would make us feel that we're doing that quite incorrectly with non-deterministic work.
If anything, it's artificially creates a belief that we do have that control. Thus, when reality kicks in, it looks like the team have made mistakes or are incompetent, when in truth it is a problem in how the reader has interpreted the graph.
And this artificial level of certainty was something I talked about in episode 62. But as I talked about in episode 62, a Gantt chart is a good tool, but the first question should be why are we creating it?
It's not uncommon that we're creating it because some feels we should - a legacy of we did it this way before approach.
But do we have a genuine "why" for creating it?
Surely we should start there.
If it's a leftover from the "we've always done it this way" then it needs to be challenged. We need to drill into the "why" to see if the Gantt chart is actually going to answer the "why" or if it will be used as proxy metrics by the reader to interpret their own answers.
I was once asked for data to produce a Gantt Chart for particular milestones; when I asked the question "why", I received the response that it was the user team that were asking so they could schedule their training. Something that I responded to with "Well, they can do that already. They're already capable of doing that training. The system is ready for them to do it."
There was simply no need to expend effort to produce a Gantt chart to answer that specific question.
In episode 62, I also talked about looking at any underlying problems rather than necessarily looking at Gantt charts in the first place. I talked about sometimes how the Gantt chart is hiding underlying problems issues with Software Development. It can often obscure the real problems we have.
If we have a project that is so complex and big that stakeholders would gain benefit from a Gantt chart, then we invariably have a combination of either too large a piece of work or incorrect organisational structure.
And that is the problem we should be attempting to resolve.
A Gantt chart will be a treatment for the symptom rather than the underlying cause. But you can go back to listen to episode 62 for more on that.
In this episode, I wanted to revisit the Gantt chart.
While a Gantt chart could be used for deterministic and non-deterministic work, much in the same way a hammer could be used to knock in a nail or a screw, it is far from optimal and prone to produce dysfunctional side effects when used in that non-deterministic work.
For me, the request for a Gantt chart is a prompt for asking the question "Why?"
Invariably, the question being asked is not for the Gantt chart itself, but rather the Gantt chafrt is being used as a proxy for another answer. There will likely be a better way of answering the original question if we just understand what it is.
And of course, as history shows, the Gantt chart was designed for deterministic work and we can expect it to provide great value in that. It was popularised and developed during the same period as Scientific Management. It was very closely linked to that work to improve the effectiveness of manual labour, that deterministic work.
The dysfunction start when we apply that same expectations to non-deterministic work, in our case, Software Development.
Thank you for taking the time to listen to this podcast. I look forward to speaking to you again next week.