Anyone who has worked in project management for even the shortest time understands that what we all need is a crystal ball. “Will we hit our date?” is the first, biggest question we all face. And more often than not, one we struggle to get right. “Is it working” probably comes in a close second. We struggle every day to know if our current project will work, and also if our last project kept working.
I want to discuss briefly what we can do, as we don’t have an actual crystal ball, to gain insight into our projects.
At the most basic level, all projects start the same way. We have a set of features, and an amount of time. Divide those, and you have your work rate. You can track a burn down or check off lines in your Gantt chart. If you fall below your expected rate – Congratulations, you are behind schedule! Please panic now. Corrective action commences.
And once you send this product out into the wild, Start measuring! Did it sell? Are the servers running? Are customers returning it unopened? How about performance numbers? Hello, is this thing even on?
Where this falls apart for most of us is that the great majority of data that we use to track our projects are Following Indicators, meaning that they are following some event that has already happened. We are measuring something and trying to piece together a story about our project. We gather server logs, customer feedback, sales numbers. We track bug count, schedule dates, workload. We depend on having a well-instrumented product, and being able to gather and parse this data quickly. But nothing changes the fact that whatever we were looking for has already happened, and we can’t change it.
What we want, are a good set of Leading Indicators for our projects. Something we can measure that tells us that something is about to happen, but hasn’t happened yet. I don’t want to know that my project is already behind schedule, I want to know that something is about to push me off schedule, and I want to know what that thing is. I don’t want to know that my server is down, I want to know that my server is unhealthy, and that it may go down soon. I want the option of taking preventative action, not just corrective action.
If you have a computer that still has a spinning hard drive (instead of an SSD) you may be familiar with S.M.A.R.T. reporting. Self-Monitoring, Analysis and Reporting Technology (S.M.A.R.T.) is on the majority of recent systems, and is designed to predict an imminent hard drive failure, warning the user so that data can be moved to a new, functioning drive. It uses a series of Leading Indicators of failure (changes in heat, vibration, Read/write times, etc.) and when these meet a predetermined threshold that matches a failure pattern, it throws an alert.
Obviously, since the other alternative is the loss of data on the drive, this is an amazing feature. While it won’t prevent all failures, it represents the best scenario in this option – proactive alerting – and allows for preventative maintenance.
So how would we apply this to project management?
Follow the Leader
As I noted before, every project manager today knows to pull in metrics that tell them about their project. For a typical software project, it might look like the following:
- Project Backlog (Tracked in JIRA or TFS)
- Ship end date
- Number of sprints until ship
- Dev capacity (hours and estimates)
- Daily scrum status (features in current sprint + changes to backlog)
- Current customer adoption metrics (usage, abandonment)
- Server Performance, availability, reachability, etc.
- Customer feedback
And there could be much more. There is literally no end to the amount of data that can be measured about a project, but in the end there isn’t enough time to measure everything, and not everything you can measure is actionable. All of the above are still Following Indicators, and can provide valuable insight into a project’s status. But there are also ways we can pull leading indicators out of a team. Communication is usually identified as a “soft skill” in a project, but a project manager with the pulse on their team can identify areas in a project to keep their eye on.
These can be the Leading Indicators that we are trying to build. While not a cut and dry as a hard metric, they can be invaluable if tracked.
- Are specs complete, or are features defined on the fly?
- Is there positive handoff of tasks/bugs across teams?
- Are teams tracking features pulled and added to sprints? Is there even a process to do this?
- Who manages failure postmortems? Is there follow-up for corrective actions?
- Are results of QA testing properly reviewed? Is there a no-go bar for quality?
In every case, we are using commitment to process as the leading indicator. It doesn’t mean that any specific process is what keep the team on track, but when a team agrees on a method of work, and they run into issues, do they make corrections as a group, or just ignore it and run full steam ahead?
What would this look like in real life? It would look like Brown M&M’s. For everyone who was a Van Halen fan, the story of demanding no Brown M&M’s in the dressing room is legend. But it wasn’t about being a bunch of Rock Divas. It had a purpose.
Quoting David Lee Roth’s Autobiography:
“Van Halen was the first band to take huge productions into tertiary, third-level markets. We’d pull up with nine eighteen-wheeler trucks, full of gear, where the standard was three trucks, max. And there were many, many technical errors — whether it was the girders couldn’t support the weight, or the flooring would sink in, or the doors weren’t big enough to move the gear through.
The contract rider read like a version of the Chinese Yellow Pages because there was so much equipment, and so many human beings to make it function. So just as a little test, in the technical aspect of the rider, it would say “Article 148: There will be fifteen amperage voltage sockets at twenty-foot spaces, evenly, providing nineteen amperes …” This kind of thing. And article number 126, in the middle of nowhere, was: “There will be no brown M&M’s in the backstage area, upon pain of forfeiture of the show, with full compensation.”
So, when I would walk backstage, if I saw a brown M&M in that bowl … well, line-check the entire production. Guaranteed you’re going to arrive at a technical error. They didn’t read the contract. Guaranteed you’d run into a problem. Sometimes it would threaten to just destroy the whole show. Something like, literally, life-threatening. “
The M&M’s were their Leading Indicator of a failed process. It gave an immediate indication that something was amiss. It might just be chocolate, it might be stage setup. But once this indicator was found, an investigation followed.
We can apply the same to our projects, by expecting teams to follow process as out leading indicator, checking things out when they don’t, then once we see an issue, using our following indicators and metrics to see if we were right. Try to correct it before it becomes a customer impacting issue. It might take time to get right, but it will be worth the effort.
What color M&M’s are you looking for?