Project Management Charts I Have Known
I love charts and graphs. I remember one of the coolest programs I had for DOS was “Harvard Graphics”, which just created graphs. Fun times.
But then I became an independent business owner writing software for people. And then a contractor, tech lead, architect, and architect lead. Finally, I was doing some technical PM work! Yay! More graphs! Back then, you weren’t nothin’ if you didn’t have a GANTT chart to show somebody.
GANTT charts were really all I needed until people started wanting to do “formal” Agile — that’s Agile with all the names, roles, rituals, and such. (Back before agile was Agile, everybody worked, everybody helped one another, and we had stuff we promised the client we would do every week. Obviously this was too simple?)
Once Agile came along, everybody was talking about Scrum, Sprints, and Burn-down charts. Who can forget this guy?
The burndown worked on a simple yet brilliant principle: if every day everybody guesses how much they have left, you can spot problems in complex work way ahead of the time you would if you interviewed each person separately to try to figure out what was going on. And when the guesses reach zero? There’s no more work to be had. Individually the guesses may be crap, but over many people, the overall numbers tend to be useful — even though they may not mean anything! The change is what you’re looking for, along with the linear regression that shows where “done” is.
It’s not engineering or a science. It’s a hack. But done correctly, it works. Plus it’s a nice little graph.
Assuming the team and nature of the work remains the same, there are two major things that change in any project: how much stuff you have left to do and how good you are at doing stuff. The burn-up captures both of those. It’s a personal favorite, although I don’t see it in the wild as much as I’d like to. It’s not difficult to do, it involves guesses as we’ve said before, and over time it eventually starts being as dead-accurate as if it were a math problem. (Part of this might be the team psyching itself out that the chart accurately reflects where things are — but that’s a story for another day.)
I was teaching a coaching team many years ago and had a young coach bring me this graph that one of his Scrum Masters had put together.
These guys were once every morning guessing how many hours they had left to do, then the SM was assembling it all into a graph of “How much we guess we have left”, “How much we budgeted”, “Actual hours we used”, and “How much budgeted we have remaining”
Wow! That’s a bunch of lines! It was a matrixed environment. That means that while there were teams, each person on the team was also on several other teams at the same time. Sounds crazy? It is. But it gives people the impression that there are a bunch of projects all being worked on at once without folks having to have difficult conversations about what’s important and what’s not.
(Each person also had multiple managers they reported to. One for each project, one for their department, and one “people manager”. Did I mention that these people needed to be agile in a big way? It was great. Once we showed up, the first thing they wanted to do was make a complicated set of diagrams and instruction manuals for exactly how to be agile. But I digress.)
I would never want a team to standardize something like this, but I liked what happened here. This team kept having a problem with delivering, even though they had 3-week sprints and could have just changed how much they promised to do and everything would be fine. But somehow they kept disappointing the customer and nobody knew why.
So the SM did this chart, which over several sprints showed that nobody worked much on the project the first week, just a little the second week, and then they tried to cram it all in on the last week. This was probably because everybody was busy on other projects doing the same thing.
They did a chart for a few sprints, figured out what was wrong, then stopped doing the chart.
I’m going to skip a bunch of Statistical Process Control charts — man, do those guys love charts! But I have to show this one.
The (somewhat) new guys on the agile block are the Kanban folks. They take out the guessing entirely and just break stuff into really small pieces and track how fast the pieces get done. With large enough numbers, it’s the same difference. The CFD diagram is probably the key diagram to get all of the PM goodness you want without having to ask people to estimate anything.
There are also more program-level charts, showing how dependencies are managed and how complex releases happen. I’m scoping those out too — there are lot of PMs that do projects. Not as many that do programs. Some of it actually scales out nicely. If you can do a project burn-up, you can do a program burn-up. Same goes for CFDs.
But it’s time we talk about the elephant in the room. Or rather, the elephant in this post.
What is the most important and useful graph on this page?
It’s the elephant.
That’s because none of these graphs are useful at all. They’re just graphs. Pieces of paper with images on them. At least the elephant is honest about it. Do these graphs tell you something? They might — but as a manager, you’re not the person who needs to know stuff. The team is. And handing them pieces of paper — or showing something on a screen — probably won’t get much attention or buy-in.
Management is about people. If you say you’re a manager, I want to see your mouth moving, your ears listening, and your body in close proximity to the people you’re trying to help. After all, the primary goal of management is the elimination of obstacles. (Secondary is the coordination with outside constraints). If you’re not physically participating in important conversations, you’re not managing. You may be dictating. But you’re not managing.
Here’s somebody who’s managing.
Every day when the team meets, after their five-minute standup, Shaunte draws a couple of graphs; whatever the team is interested in tracking that sprint. They always do burn-down because somebody is always asking “Are you done yet?” and that isn’t important enough to interrupt their work. They add in more as-needed, depending on the problems they’re working.
This is called publish-subscribe. If a bunch of people want something from me, instead of each of them bringing me into a meeting, I publish it in one spot. Then “subscribers” can come and get the information as needed. Saves a ton of time.
The team stands there while the graphs are updated. After all, they are the ones that own the data. The purpose of the graphs is to save time later on. It’s their graph, not hers. Sometimes they rotate around who does the graphs.
“Well!” I hear you say. “Certainly these graphs should be put into a tool! We have all kinds of great tools to handle this kind of grunt work! People can come online and see the graphs from anywhere! And the graphs are much nicer too! None of this crappy schoolhouse craft show.”
But the purpose of PM graphs aren’t to create data to move around, they’re to assist in management — conversations. Project Management is not bits and bytes. It’s people. Yes, you do reports that have these kinds of things in them — but that’s not the work. The graph alone is worthless because you don’t have the context and can’t engage in the conversation. In fact, it’s worse than worthless because it gives you the impression that you know something now that you didn’t before. If you’re four-steps removed from the team that’s fine. You don’t have to know a lot. If you’re only a step or two? It’s not. Do your job.
These graphs are hand-created because the team has to own and talk about them as they evolve. That’s their purpose. You don’t make a graph so that somebody else can read it and swoop into the team to announce all the things they’ve done wrong. You make a graph so that as you update it, the people affected can learn more and have better conversations about what’s happening.
They’re physically put on the wall because the team owns this. It isn’t some report you get when you push a button. It’s the replacement for a bunch of meetings. If you’re interested in how the team is doing? Come by and look at the chart. Got questions? Cool! There’s the team. You now have data plus context plus access to the people you need to do your job. This also saves you time. In fact, the first thing you should do as a program manager or higher is a “Wall walk” every morning. Before folks get there, walk around and let each team tell you how it’s going. Then you can pick and choose where to go listen and help out based on the need they report
Isn’t that a lot better than a management-level meeting where a bunch of folks look at charts made by some tool that don’t mean anything and are a hassle for everybody to update?
I’ve known a lot of Project Management charts in my time. But I’ve only known four tools that I’ve seen consistently kick ass over and over again: your feet, your eyes, your ears, and good conversations. You use them in that order.
July 11, 2018