I’ve never understood the obsession with “green” status among IT application development project managers, and the intense pressure put on them to “stay green” by the program management offices (PMOs) they report to. We would benefit from a cultural shift away from avoiding yellow status.

For those not in the field, it is in vogue to express IT project status using a stoplight analogy, where green means things are going well, yellow indicates some quality, schedule, or budget risk, and red means there’s imminent risk of failure.

My recent consulting assignments have been technical and administrative, so it has been a while since I’ve experienced it personally, but I’ve seen a number of big projects that were clearly in trouble feature cheery green status reports month after month. Some of these efforts succeeded but more went straight into the ditch.  In those latter cases status went abruptly red, followed by general gnashing of teeth, replacement of the PM, rebalancing of schedules and budgets, and updating of resumes among the project team.

Overly optimistic status reporting isn’t necessarily the PM’s fault. In my experience, many organizations have a culture that strongly discourages delivery of “bad news”.  More than once I’ve been pulled aside and asked to report green in spite of project realities, and I’ve understood the reason why. Managers need to choose their battles, and in these cases me reporting anything but green on my project would have drawn attention away from higher priority issues that person needed to deal with.

The problem with reporting green all the time is that sometimes it isn’t true, and if you think about it at all it doesn’t even make sense. There are lots of reasons why every IT project runs at sufficient risk to justify a yellow status on occasion:

• Most companies today run IT on as lean a budget as they can with strategies like offshoring and near-shoring, work from home, and limited travel allowances.  These strategies may reduce cost but they prevent team co-location. As every agile developer knows, project risk increases as co-location decreases.
• In spite of the high general unemployment rate senior technical specialists in tools like .Net, SQL Server, Oracle, MQSeries, and many others are scarce. Even if you can replace your recently resigned lead architect, odds are that it will take a solid month to find that replacement and then a month after that before the new player gets up to speed. Every significant IT project faces at least some risk of substantial delay due to loss of a key player.
• Frequently, today’s application projects bring in technologies that are either new to the market or the organization.  New software products can bring new design criteria, unforeseen infrastructure requirements, and user change management. Knowledge gaps in designing and deploying these new tools can result in rework or underwhelmed business customers.
• In addition to these challenges shared across the industry, projects typically face organizational, market, and culture risks unique to the particular organization.  For example, one project I managed many years ago required cooperation between a data management team and a software development team. Their design philosophies were different, but it wasn’t until an early performance test that we found out they were incompatible.  The performance test failed and we had to redesign the application from the ground up.  Such factors vary from project to project but they have been present to a greater or lesser degree on all the development efforts I’ve been on.

It is only realistic to expect one or more of these risks to become an issue from time to time on any significant project. Transparent status reporting requires the project manager to call out emerging issues with a yellow status from time to time (or even red if merited), and offer a plan to return to green. For example, in the early stages of requirements gathering and design, wouldn’t reporting yellow when needed help keep business stakeholders and architects on track and prevent the cutting of development and testing schedule that is so common during IT projects?

Reporting the reality of risks in a “yellow” state, rather than hiding behind politically correct “green” will bring about healthy discussions of risks and mitigations.  To me, these dialogues are the lifeblood of a project that help us avoid the ditch when the road gets bumpy.