Let’s revisit the failed school management project from Chapter 4. When my team did the assessment the project was set for User Acceptance Testing to begin, and the CIO was convinced they were good to go with the fall launch just months away. Within one day of arriving it was clear that they were behind and in serious trouble, the issues were in plain sight, obvious to anyone who cared to look. Any experienced PM spending a day on the project would have reached the same conclusion. Yet, though hard to believe, the project status was showing ‘on track’. No one was claiming things were perfect, they never are, but no one was saying, ‘Hey, we need 12 more months, and we need to stop the summer roadshow and fall launch.’
The most shocking aspect of this fiasco was the element of surprise – the samurai inside the birthday cake jumps out and cuts your dam head off. At the most fundamental level, in this example and in countless others I have seen, project management failed completely. If you can’t track a project, if you can’t get remotely close to having an accurate status, if the story being sold to executive management is woefully inaccurate and void of actionable data, then the game is up, turn off the lights and go home. The fundamentals of project management, characterized by microsoft project plans ( or spreadsheets ) that are seldom complete/current and largely ignored by the project team, the project manager often acting as a passive scribe, caught between teams arguing with each other and complaining about ridiculous schedules, and management demanding more with less, need to be remade. Out with the old and in with something that actually f’en works. And yes, before you ask, I have worked with many great project managers.
When a projects implodes there is a lot of blame to go around. The problem is not with a single person – the PM, it’s with a bunch of people, many who need to take project ownership a lot more seriously than they currently do. Delivery is a collective activity and project management is a collective responsibility.
I will come back to the broader project management function in the next chapter, for now lets focus on the issues with project status reporting. Let me first state the obvious –
Poor status reporting obfuscates project issues and is a primary cause for project failure.
Sure there are always many underlying and contributing issues, but if you can’t objectively state and track status then the issues that ultimately lead to project failure go unresolved and ignored. Out of sight, out of mind.
Why do I care so much about reporting, especially exec level reporting? There are 2 obvious reasons:
A. I have seen way to many execs blindsided by projects hitting the wall at 100 mph. Yeah, they generally weren’t watching close enough, but execs are busy people with lots of things to watch. The underlying cause in every case was inaccurate/incomplete/misleading status on project health and progress.
B. If a project team cannot present a succinct, accurate and complete declaration of project health that they all agree with, then how does it adjust allocation of time, resources and attention to the areas most in need. How does it prioritize its work? In both of the case studies I have mentioned, integration testing was way behind, yet Product keep piling on new requirements because they didn’t know ( and maybe didn’t particularly care ) that testing was behind.
The obvious question – why would tracking be so challenging?
Well, there are a few reasons:
1. Tracking indifference
It is common for a project team not even to be aware of overall project status and what is being reported. The reporting / tracking function is viewed as a PM role, considered by some to be management bureaucracy and counter to the wonderful(!) self-organizing team Agile promotes. With questionable/incomplete input from various parties, the PM boils down a bunch of scattered data points and produces a roll up of status which is presented at the weekly project review. Most people on the team don’t pay much/any attention to the status, in many cases it is not even circulated across the team. And there you have the first problem, everyone should know the reported status especially senior members on the team. So let me directly ask senior dev, QA, business analysts, and the associated managers. Do you know the overall reported status on your project, not just your particular slice? Do you agree with it, is there important data missing, are all critical risks & issues captured? Answering for many teams I have worked with, the answer to most of these questions will be a puzzled frown. Many people who need to be informed about status are not, and many people who’s input is needed to determine status are not asked. This is a very serious problem that is resolved with the Delivery Assurance team.
2. Fluffy metrics
What metrics do you track?
In many projects little thought is given to the question. For the weekly status review someone will throw together a powerpoint deck with subjective green, yellow, red status against various work streams or activities. There will be lots of other subjective statements and lists of what was accomplished, what is left, issues and risks, maybe some burn down charts, some dev stats on progress, bug stats – new, fixed, open, etc. A veritable cornucopia of data, that right up to the moment when the project hits the wall, will fail to predict the looming disaster.
Even when things look bad, project teams have a strong tendency to believe that it will all work itself out – we’re good if the integration testing goes well ( even though we all know it never goes well ), we are back on track if we can accelerate dev ( even though we are already at our limit ), we can focus on code hardening if requirement creep slows ( even though we know the product team can’t control their imagination ). I have walked into projects that are at the point of imploding, and encounter PMs, managers, devs etc who truly believe they can turn it around, right up to, and even beyond the point, when the shit hits the fan. At times this blind determination can push a project over the line, at other times it simply masks serious issues and increases the level of shock and disappointment when the crash happens. In all cases, optimism thrives on fluffy metrics.
4. Partial disclosure
I have been in boardrooms, at project reviews, where the fear of god was in everyone. Truly horrible affairs were execs regularly slammed project teams, and pushed everyone into survival mode, happy to throw others under the bus to save their own skin. Even though this is thankfully a rare occurrence, project reviews are more akin to a trip to the dentist than a visit to Disneyland. Even in the most ideal setting there is a strong tendency for a team to downplay issues and not admit to problems ( and their mistakes ) when everything may eventually sort itself out. Execs likewise may not actively foster complete disclosure and take the time to completely understand and help resolve the complex problems faced by the team. The project review becomes a low value affair, with all parties simply going through the motions, execs posing softball questions because they don’t have enough data to ask meaningful questions, and presenters tactfully avoiding potential land minds that could expose cracks in their ‘on track’ story .
All these issues feed on each other. When a project fails they are at epidemic proportions and no one actually knows the true state of things. In the absence of real data wishful thinking has long ago taken hold, the team pushes forward in a fog, often for months, not sure where the finish line is and how far they have to go. No one wants to admit to problems because no one is sure how significant they are. The game of chicken will be played right up to a significant dateline, suddenly UAT is 2 weeks off and everyone must face up to the reality of the situation. The team can’t bury their heads in the sand anymore, FRED is in critical care.
More on project tracking soon and the steps needed to fix it. Up next, the Project management Function.