“So, How’s It Going?” Thoughts on Reporting Project Progress
Whether your wizardly software work is structured according to agile or waterfall methodologies, there are likely muggles somewhere near the top of your org chart who want short summaries of project progress.
These people are often responsible for deciding which projects are funded, approving budgets, and arranging promotions and salaries for leaders. They usually aren’t stupid or evil, but they may not understand the full scope of the effort. Sometimes they want a status summarized more than it can be without sacrificing context; to serve them well, you need to avoid this.
Be thoughtful when someone asks, “So, how’s it going?” Because if you summarize too much, these same leaders may feel misled later.
An effective status update should describe six things:
- Scope: What did you set out to do, what has been done, and what remains to be done?
- Schedule: What was the original schedule goal, and what is the current schedule projection?
- Resources: What was the original resource allocation (people and budget), what has been consumed to date, and what is the current estimate to complete?
- Issues: What open issues are being worked on or threaten progress?
- Risks: What significant risks are being monitored?
- Changes: What significant changes in scope, schedule, or resources have been agreed to or are looming?
I’ve seen both project managers and executives push back on this outline as too detailed, preferring to have a status reported as red/yellow/green, percent complete, or velocity. But these oversimplified measures risk miscommunication and ultimately the dreaded “Why didn’t you tell me sooner?” response from muggle leadership.
Imagine we are working on a computer gaming project with a ten-person team that is estimated at a thousand story points. The velocity of the team on prior projects was one hundred story points per month (to make the math easy), and the project has been going for five months. You have delivered five hundred ten story points. In this scenario, you might be tempted to summarize status as “green,” or “on track,” or “51 percent complete.”
But what if the team had to work massive overtime for the past three months to sustain the velocity? What if your lead developer has just given notice? What if the producer has told you over coffee that there may be a significant change in functionality coming? What if code is beginning to bog down on the target processor and you aren’t yet sure why?
These are all plausible scenarios, but you have not established a standard mechanism to communicate this information. Worse, if you have been communicating nothing but “green” for the past five months, it seems like you are suddenly trying to prepare people for later excuses, rather than provide a more comprehensive view of a complex undertaking.
Software development is complex. Executives’ desire for simple statuses isn’t irrational, but to serve the executives and our organizations well, we need to not simplify out meaningful texture and content. Our status updates can be thorough but still brief if we establish and use effective mechanisms for communication.
