Why Kill the Gantt Chart?
First of all, let’s clarify something. There is nothing wrong with the Gantt chart if you use it to visualize dependencies or sequencing. However, at the moment when you attach start and end dates to the individual work items, you become the root of all evil. Why is that? Because:
- We have the means to twist hands, a.k.a. “the project is late, you will work on the weekend”
- We have the means to justify bad decisions, a.k.a. “They want us to do it by Friday, let’s not do what we have to, but what we can”.
- We know when we are on time, a.k.a. “The charts are green, but no one knows what the heck is going on around here”.
- We have some more time, no rush, a.k.a. “The task is planned for 3 days, let’s make sure it takes at least that long”.
Building Gantt charts is acceptable in contexts with low variability, but they might be a real nightmare in knowledge work.
When we build software or plan a marketing campaign, we just don’t know how much time things are going to take.
How could we possibly build an accurate Gantt chart? It is obvious that we need a better way of planning and that’s where Kanban planning comes into play.
A Strange Phenomenon
One of the strange issues, that we at Kanbanize see, is that people don’t make any difference between planning, estimating and scheduling.
Sometimes, even experienced project managers don’t differentiate between these words, and they should. Moving forward without clarifying these terms is pointless, so let’s set straight the definitions first.
Planning (The Good)
Planning is our attempt to sequence work in a way that it is reasonable to complete. It happens in the beginning of a given time period or a project/program phase.
If we are building a house, for example, we will plan whether we first need the foundations or we first order the windows or we first choose the heating system and so on.
We talk about approximate time frames that we envision for the project completion. Also, we come up with a rough idea of the total cost.
If we have enough information, we also plan what dependencies we will have and try to come up with appropriate measures to handle them.
All this is common sense and it is totally fine to do it, no matter if you are doing Kanban, Lean, Scrum, Waterfall or anything else.
Estimating (The Bad)
While rough estimations are totally fine, and it’s what we do anyway, when we try to create a general plan, estimating on the individual work item level is a rather wasteful activity. There are many reasons why we shouldn’t do it:
- We never know how much time individual tasks take
- When we estimate work, we usually create unrealistic expectations
- If we have to estimate, we usually add a huge buffer to our estimation, “just in case”
For one reason or another, however, most teams are asked to estimate work. Even teams that proudly claim they’re “Agile”, still estimate work. At Kanbanize, we only estimate if a task is larger than two weeks or not – that’s pretty much everything that we need.
Scheduling (The Ugly)
Scheduling work means that we fix the start and end date of each individual task. Scheduling in knowledge work is a waste. Period.
If someone claims that they can effectively schedule the work of a team of knowledge workers more than one week in the future (even this is questionable), slap them in the face and don’t talk to them ever again.
Playing Nostradamus is probably the biggest mistake you can make as a project manager. Seriously, don’t do it.
From Gantt Charts to Kanban Planning
It is no brainer that we need to plan our work before actually doing it. However, we should accept the fact that we have no control over the future and we just can’t know how long things are going to take. Not even if it’s in our Gantt chart.
Accepting this will allow us to change the way we plan from a deterministic to a probabilistic approach. That’s right, the first step is knowing that we don’t know.
The ultimate challenge is to accept that we only know what is important now – at this very moment.
That’s how the Just in Time manufacturing came to exist and companies started building only what the customer had already ordered. That’s how Kanban came to exist – we needed a method to help us with our daily work and deal with the unpredictable future.
At Kanbanize we call the Kanban board “The new Gantt Chart”. You cannot translate one into the other, without losing some of the characteristics, but there’s a pretty good correlation, which makes the Kanban Planning possible.
Imagine that the “Not Started” area of your Kanban board is a reversed timeline – the rightmost column is “now” and the leftmost, sometime in the future:
With this basic timeline in place, we can easily use stickies to plan when some items are most likely to be delivered. If one item has to be expedited or postponed, we just take the Kanban card and move it to another column of the Kanban board.
That’s pretty much the Kanban Planning approach – just reorder the stickies to be in the right column. Of course, we should use Kanban cards if we are using Kanban software for this purpose. What an easier and more flexible way to plan?
How do we Know if the Kanban Planning is Accurate?
Gotcha! It won’t be. However, it will be as accurate as it can ever become, especially if you use technology to support you.
As part of the Analytics module in Kanbanize, we do have Monte Carlo simulations, which we use to forecast how many work items we can deliver by a given date in the future. These simulations are based on real historical data, which makes them the most reliable way to answer the “When is it going to be done?” question.
With this data in place, it is easy to create our Kanban Planning board. Not only that you do this in a fraction of the time you’d need for a detailed plan, but this type of planning is likely to be more accurate than your gut feelings.
Even further, you can use the Kanban Planning technique to forecast not just on the Kanban team level, but also on the Portfolio Kanban level.
So, let’s kill the Gantt chart and replace it with the only reasonable replacement – the visual Kanban Planning board.