On Health and Transparency

Having spent a number of years in project and program management (as well as IT Operations), one of my favorite subjects is transparency.

For the purposes of this article, I’m focusing on “traditional” project and program delivery (irrespective of methodology), not product-based operating environments, though many concepts would apply to both.

 

Context

An inevitable truth of managing programs (especially large ones) is: Things will change.  I think of these changes as “points of inflection”, namely times when some level of pivot is needed either within a single project or across multiple work efforts in a coordinated fashion to get things realigned, stable, and back to operating in a healthy way… typically with a revised delivery schedule.

What makes a programs successful at these points of inflection is three things:

1. Having good transparency – Knowing where you are at the present time in relation to your ultimate goal, so that you can evaluate the remedy (or remedies) needed to adjust course
2. Making the right “turn” – Adjusting the scope, approach, plan, work efforts, risk profile, etc. so that you address the issues identified in a way that increases operating stability, plan integrity, and quality of the ultimate solution and/or deliverables
3. Turning quickly – Making the appropriate adjustments as quickly as possible after the issues are identified to rectify the situation. This can’t be emphasized enough, given a significant amount of disruption, cost, and other negative impacts tend to come as a result of organizational inaction related to materialized risks.  As has been said in consulting many times, “bad news doesn’t get better with time”… and the sooner critical issues or risks are addressed, the better.

So looking at the above, the critical dependency is transparency because, without an understanding of where you are, there’s no way to evaluate whether the changes you make will ultimately help or hurt your delivery effort.

 

The Challenge

This is where the problem starts: Wanting transparency is different than needing lots of metrics, and the latter is where a significant percentage of projects and IT operations efforts waste time, energy, and cost that ultimately undermine delivery and/or operational excellence.  The goal of transparency is to enable governance and risk management.  Reporting in of itself is administrative in nature and adds marginal value (unless it is of a regulatory nature, of course).

What tends to happen is that, rather than approach transparency in a top-down fashion, with a focus on enabling engagement and action, leaders take a bottom-up approach, assuming that the more data they have, the more they can ultimately understand and control.  This is a critical mistake that happens on projects all the time… reporting so much information that the fundamentals are lost amidst the noise. 

One root cause of the above situation is that there are a good number of leaders who see status as organizational comfort food, as if having excessive documentation will provide “proof of ongoing work” for customers or to create a level of air cover in the event that things ultimately go wrong.  On the latter point, having led high risk and complexity delivery efforts, particularly in consulting… the minute anything goes wrong, if you’re a project or program manager, you can pretty much assume you’ll be taking the blame regardless of whether the issue or risk has been documented on a status report… and that’s the job, and it’s ok… because no one said these jobs are easy.

This is either what makes project and program management work difficult or very rewarding, depending on how you choose to see it.  Your best work tends to be happening when nothing goes wrong, in which case people may well ask what you do all day.  In the converse scenario, when things are not going well, you may find yourself in the situation where people ask what you’ve been doing, and you won’t want the answer to involve having spent hours writing or updating reports.  Our goal in delivery is producing value (i.e., business outcomes), not status.

 

Some Examples

Three different situations (each from a different organization) come to mind where “reporting” got in the way of actual transparency:

First, I was asked to cover a delivery project from an oversight standpoint while the director responsible for the work was out on vacation.  The project manager, a trained PMP, had a well-organized and documented project, with an abundance of metrics.  A source of particular pride was the earned value (EVM) calculation, which indicated that the team was 90+% complete on the project.  Upon reviewing the artifacts, we realized that the effort related to producing deliverables was not included in the plan, and therefore, the EVM calculation didn’t include the full project scope and it was actually massively BEHIND where it was supposed to be (something in the 70+% range).  In practice, the project manager had spent so much time managing metrics that they forgot to make sure the scope of the project was represented in the plan, effectively compromising what they had been reporting for weeks.  The good news is that, having recognized the gap, we made the necessary corrections, pulled in some additional help, and got things back on track.  Overall, however, the lesson learned was that metrics are only as good as the understanding they provide for the underlying effort itself.

In another situation, I inherited a client engagement where one of the divisional CIOs had the team producing a forty-page status report covering all delivery efforts in the portfolio on a weekly basis.  It was well understood that the client wasn’t reading the report, but rather requested it to force the team to evaluate their project health on a continuing basis.  The implication being that writing status helps project managers focus on their project, which is actually the opposite of what happens in practice.  The more time project managers spend in administrivia, the less time they tend to spend on activities that add value, such as communicating with customers, engaging with their delivery team(s), identifying and managing risks, reviewing the plan for gaps and issues, and so on.  It took some convincing, but this was an activity that we ultimately eliminated that not only reduced administrative effort, but also allowed us to cut a full-time position that had been staffed solely to report on that portfolio of work.

Finally, I was asked to take a short-term assignment to help a divisional CIO organize his PMO, particularly the reporting being done across a relatively large and diverse portfolio of work.  Similar to previous situation, he showed me a stack of printed status roughly four inches thick that he was receiving weekly across his delivery leaders, ultimately which we replaced with a four-page dashboard organized across financial health, strategic programs, ongoing discretionary projects, and production support.  Rather than produce information on a project-by-project basis, we requested standard information from each delivery team at a summarized level that helped highlight areas where intervention was actually required and eliminated a significant amount of the administration related to written status.  In practice, the minute the yellow or red light goes on, someone likely needs to have a conversation anyway, so writing a lot of documentation doesn’t tend to help anyone.  The end result was less paperwork and a lot of relieved project managers.

 

Focusing on What Matters

Coming back to transparency, some fundamental concepts that I believe are important:

• If you can’t understand the overall situation, the details don’t matter
• Qualitative information can be just as good as quantitative data, given the quality of detailed project metrics is often suspect and imperfect anyway
• Any metric that is reported should be actionable, otherwise it is likely noise and a distraction
• Once things get into the ‘yellow’ or ‘red’ there is a discussion coming, so there is little value in writing a lot of language in a status report that ultimately will be discussed anyway
• It’s completely fine (and often helpful) to track detailed items within a project, but report on summary characteristics from a governance standpoint

In line with the above, these are the primary seven ‘indicators’ (all in R/Y/G) that I consider important to track across projects in a program or portfolio of work, along with their conceptual definitions:

• Overall Health – Indication of the Delivery Quality overall, given the following six dimensions
• Scope – Requirements are clear and understood
• Budget – Financially in line with expectations
• Staffing – Team is skilled and staffed to deliver the work
• Schedule – Work is being executed in line with expectations
• Quality – Work product is in line with or exceeding expectations
• Risk – Concerns areas are understood and being mitigated effectively

Where the indicators are defined as:

• Green – On Track
• Yellow – Needs Attention (50%+ chance of an issue)
• Red – Requires Action (Issue exists, discussion or intervention needed)

This isn’t to say that things like next major milestone, %complete, %test cases planned/ executed/ passed, etc. are not useful to report, but they generally fall at a lower level of criticality once the above indicators are addressed.  My general preference is to have details only where there is additional insight needed (for example, Schedule is “yellow”, in which case progress metrics specific to the current activities may provide useful information).

 

Conclusion

While a lot has been written about these topics, the goal of this article was simply to share a few concepts about transparency, the role it plays in effective governance and risk management, and the often questionable value of reporting in itself.

There are many best practices related to transparency and reporting, but the main takeaways:

• If you don’t have effective transparency, you are highly exposed to the experience of the people leading an effort, and your ability to govern and manage risk and change will be limited
• If you don’t know how you will use information (down to the individual metrics) being reported on a delivery effort (or operational dashboard), don’t collect them. It’s likely a waste of time
• The more you measure and report, the less you’ll likely notice the critical things that matter
• The more time you force delivery leaders to spend on reporting, the less likely they are to be focused on their actual delivery responsibilities
• The goal of transparency is to drive engagement and action (and value), not administration

I hope the information was useful… as always, feedback and comments welcome.

-CJG 08/21/2021