We’ve all been there — we’re talking about our upcoming projects, discussing possible timelines and resource allocations, working to align our tactical work with the company and product strategy, when it hits you like a brick thrown through your living room window in the middle of the latest Game of Thrones episode:
So, where’s the project plan?
And that’s where it goes downhill. Because we all know that what’s usually meant by “project plan” is some extremely detailed, well-defined, cascading graphic from hell known as the Gantt chart. It’s been the go-to standard for project management and project planning for decades.
And it needs to die. A miserable, screaming, Melisandre-putting-it-on-the-fire-for-the Lord-of-Light death.
Gantt is Not Agile
First off, and perhaps most importantly, we’re living and breathing and working in an agile world now. Whether we like it or not, whether we accept it or not, and whether we actively practice it or not, others in our markets are, and they’re constantly improving themselves and their products. But when we look for those classic artifacts of yesteryear — the PRD and the MRD and the Project Plan and the Gantt Chart, and the Change Control Process — all we’re doing is holding on to relics from another time.
Let’s recall one of the principles of the Agile Manifesto: “[We value] responding to change over following a plan.” If there’s anything that looks like “following a plan,” it’s our old, rusty friend the Gantt chart. A Gantt chart leaves no room for error; it has no concept of iterative work; it cannot predict how technology might change or what feedback you’ll get from your customers or stakeholders. It says, in bold and bright colors: “We’re starting here, and we’ll do all of this in order until we reach there.”
And let’s not even consider the amount of time that one can spend creating and tweaking and updating and modifying and re-editing dates so that your Gantt chart looks good. Connecting the dots, layering in dependencies, fixing the errors that your tools force on you by their “assumptions” (MS Project, I’m making the Evil Eye at you right now). All of which is time better spent working with your teams to ensure they’re working on the right priorities at the right time, and with your customers and stakeholders to ensure that you’re
Gantt is Impractical
Sure, the Gantt chart is pretty. It’s clear. It’s easy to follow. But it’s also bullshit. Any project plan that pretends to be anything more than a snapshot of what you know right now and what the current plan is, subject to potentially massive, disruptive change at a moments notice is nothing more than a security blanket. It comforts you, it covers you, it makes you think that the world is all right, and that there’s no way the monsters can get to you. But it’s all a lie — it’s a GLADOS-level lie, right up there with the cake.
But the real problem with the Gantt chart is the cognitive dissonance that it creates. Ask anyone what they think of them, and they’ll tell you, with a straight face, that they view them as estimates, and that the target date at the end rarely is going to be the “real” end date. But get those same people in a meeting where you’re telling them, three months out from that “fake” date that things are going to slip, and they. Will. Flip. Their. Shit.
Why? Because they’ve made marketing plans, and they’ve made customer promises, and the training materials are ready to go, and the interns are leaving, and the British are coming, and a thousand other excuses to blame the developers and the product managers for giving everyone that project plan that they asked for.
Let’s be honest — nobody hears “this date is flexible.” Nobody hears “there are still some unknowns that might bite us.” Nobody hears “this is our best guess at a delivery date given what we know.” They see the Gantt chart, and the Gantt chart is God to them — it may as well be written on a stone tablet. The minute those bars and arrows and dates appear in front of those business stakeholders and the management team, they’re transfixed and all logic, reason, and understanding of the realities of building products goes out the window.
But There is Hope!
So, what the hell can we do? The business wants a project plan, but we all agree that Gantt charts are the Devil…right? Well, what we have to do is a little song and a little dance, and present them with something that cannot be viewed as a hard-target deadline. Start by easing back on the dates — turn them into “Sprints” without any relationship to months and years — “Sprint 1”, “Sprint 2”, “Sprint 3”, ad nauseum. This very small change actually alters the discussion at a fundamental level — we’ve managed to abstract away the dates, and are not talking in the language of iteration.
Another thing you can do is to remove all those dependencies and connections — flatten out the plan as much as you can, and transform all those small, individual deliverables into some container object — I like to call them “themes” and “epics” to stick with the Scrum terminology that I learned many years ago. The point is to focus on the goals, and not the path to get there. This allows the path to change, so long as the goal remains the same.
Finally, don’t be afraid to punt completely when asked for a project plan — position it carefully and clearly, so as not to make your management team and stakeholders think that you don’t have a plan, but refocus on the work that’s being done now and how it’s valuable, rather than what’s going to be done in the future. Use your Top Ten Priorities list to show that you do have a list of things to do, and that you all agree that the next thing up is flexible and decided at the time you’re ready to execute. Use the project plan discussion as a training and education opportunity on the values and benefits of being agile.
