If you have ever played tetris, you would probably be able to understand what it means to build a project schedule. You are given a deadline and then all required tasks need to fit to that deadline. Hard expectations are set. A job for a project manager. A tough job.
American engineer Henry Gantt developed a bar chart (Gantt chart) in 1917 as a visual production scheduling tool. It became a popular method and is in wide use today in an essentially unaltered form. The Gantt chart indicates tasks and time in a graphical format allowing the allocation of tasks in time horizon, but not determining interdependencies between tasks. Gantt charts were first used on large construction projects and they proved their efficiency in remarkable projects like the Hoover Dam, started in 1931.
Meanwhile in Computing. Hardware development domain started using schedule-based planning early. Back in the 50’s the most powerful IBM machines had to follow a delivery schedule. Building of hardware was complex, still most of the relevant actions could be predicted. Additional risks could be managed. Whether it was measuring how long it might take a company to produce a new lamp, to be used in the computing engine, through how fast a good engineer could assemble the parts to how long it would take to ship the new item to the relevant location.
A simple domain, fairly simple tasks and fairly expected risks.
This started to change once software became more important than the hardware itself. When the personal computing revolution started. When it was no longer a small subset of operators using machines, but all of a sudden anyone could.
I tell this story to illustrate the truth of the statement I heard long ago in the Army: Plans are worthless, but planning is everything. There is a very great distinction because when you are planning for an emergency you must start with this one thing: the very definition of “emergency” is that it is unexpected, therefore it is not going to happen the way you are planning.
Dwight D. Eisenhower https://babel.hathitrust.org/cgi/pt?id=miua.4728417.1957.001&view=1up&seq=858
President Eisenhower was talking about large armies. Planning movements and expected goals. A very much simple domain too. Even if just on paper. Although he immediately makes a statement about emergency and unexpected. That part is rarely added for context when this saying is being quoted.
Now, most of the new software builds rarely follow the simple or obvious problem space. This was the hard lessons as the complexity and complication began to grow over years, learned by hundreds of engineers and managers.
The attempts to remove the ambiguity with months-long requirements gathering, followed by a build to the letter, increased cost and time to deliver. Also failed to satisfy the ever-changing needs of the end consumers. This is how Agile was born.
The model that better defined the software problem space, born much later was the Cynefin framework. Your problem domains can be classified as:
- Simple or Obvious – little unknowns or freedom, all constrained – easy to plan (like hardware replacement, certificate replacement, developer onboarding, best practices are well known)
- Chaotic – full freedom, all unknowns, close to no knowledge of constraints – impossible to plan (like unknown production issues, working on a codebase without any documentation, all practices are a novelty)
- Complicated – reasonable freedom, constraints are known, less unknowns – planning in short term possible (like replacing legacy systems, adding functionalities with a good user-base, good practices are in place)
- Complex – a lot of freedom, few constraints, a lot of unknowns – planning in short term possible, but requires continuous feedback (like building a new product without an engaged user base, practices start to emerge)
While a Gantt chart can be useful to cope with some of the “complicatedness” of projects, and embraces the importance of time and timing, it is based on principles that are not valid to all projects. The consequence is a propagation of a management approach that does not explicitly cope with complexity, ambiguity, uncertainty and change. In that respect, the Gantt chart fails to acknowledge insights from years of organization theory research and project management research with a firm grounding in contingency theory.
Gantt charts revisited: A critical analysis of its roots and implications to the management of projects today, Joana Geraldi, Thomas Lechter, https://www.emerald.com/insight/content/doi/10.1108/17538371211268889/full/html
This eye-opening framework should tell you that for most software projects it is hard to build a time-bound plan. Well to be fair you can build one. As long as you follow the rule – we either commit to scope or to time. Meaning you either get the outcome you want (but can’t predict time) or you get what you get within a defined timeframe.
I think using Gantt chart beyond where it was applied and developed for initially (this is Simple/Obvious problem domain; compared to most software projects) is brutally demotivating to say the least. However I would say the same for applying Agile, where it has no space to be (Simple/Obvious). Showing a Gantt chart to your stakeholders always builds expectations. Even if you add an explicit, voice message overlay on top. All people will remember is that you promised them a delivery by end of December. And they will expect it, no matter what.
And it could have been so much easier just to tell them – This is my goal or outcome. It is hard to list everything we need to do to get there. But this is what you should expect of me. Without the necessity of showing a Gantt schedule.
I personally call showing a Gantt schedule on software projects building Gant-driven disappointment.
To sum up on Gantt today:
Advantages of Gantt Charts
- Creates a picture of complexity
- Organises your thoughts
- Can be highly visible
- Is a simple method of showing progress
Disadvantages of Gantt Charts
- Can become extraordinarily complex
- Size of the bar does not indicate the amount of work
- Need to be constantly updated
- Builds a culture – I want this by this date, rather than I prefer this outcome
- On software projects – builds unrealistic expectations and due to that sets the projects to be most likely a disappointment
- Makes management and teams defensive – but we followed the schedule, it’s not our fault
- May falsely demonstrate that you know what you’re doing. (which is probably why most managers would select it, it shows you are in control. Watch out, as this might be a very misleading feeling)
For most software projects, I strongly recommend focusing on outcomes or if anything north-star annual or quarterly outcomes. A good mix of a timeline-less roadmaps and JIRA boards might give you a better outcome. Mix it with specific high-level outcomes and you are in a much better place.
This is unless you are in the simple problem domain.
Gustaw Fit 