As organizations grow, senior leadership inevitably asks for more aggregated reporting; there is too much going on for them to know all the details. A popular version of this reporting is the stoplight: red, yellow, green. But when you reduce complex efforts into a single color, there can be a shocking loss of fidelity.
A member of my team recently introduced me to a new concept: the “Watermelon Project.” These are projects on your dashboard that are green on the outside while being red on the inside. (Some online definitions call them “red and bleeding” on the inside, for what it’s worth.) He didn’t invent the term, but I found the concept fascinating, and it resonated with my experiences. Let us examine why the phenomenon exists at all, and then some examples of types of watermelons.
Boiling it down to a color. At a certain organizational size, senior leadership stops being able to remain in touch with all the details of the projects that are in-flight. While they are capable and interested in a deep dive, they don’t have the bandwidth to do it for every project, so they look for quick indicators as to where to best spend their time. A long time ago, someone cleverly decided to use the stoplight approach, calling projects red, yellow or green. Calling a project red eventually became an invitation for an executive to dig into a project, causing the leadership of the project a lot of unwanted attention.
Because of this reality, few product owners or project managers want to declare that their project is red, even if it truly is on fire. I can tell you that as a manager of project managers, I would explicitly tell them that if the first time I found out that project was red was on some kind of dashboard or executive report they would be looking for a new job the following morning. While there is nothing wrong with highlighting that your project is in trouble, doing so by inviting executive scrutiny as a first step feels like poor project and stakeholder management.
This has caused many a project manager to look for any excuse to call their project green, or at worst, yellow (these are called grapefruits, and are a topic for a different article.) This way, the project can blissfully careen off a cliff, with no interference or extra work needed. The team is either hopeful that the project will right itself again before anyone finds out, or it won’t and no one will notice. So they encase their red project in a shell of green, and hold their breath. In other words, they turn their projects into watermelons.
TYPES OF WATERMELONS
There are lots of ways that a project manager can make a project look like it is going well, even if it isn’t. Some of these involve lying and deception, but those tend to be easy to catch (and the correction path is pretty well known.) What is harder to catch is when what the teams knows and what is being outwardly reported are close to each other, unless you look hard enough, or to extend the metaphor, cut open the project and look inside. And one of the more difficult ones to catch is when the project itself is humming along, but the final product won’t fulfill the actual need.
Changes in scope, changes in value. Changing the scope of a project happens all the time, and is completely natural. Schedules can change, features can be cut or added, and developers can be added or taken away. Projects can go through dozens of re-scoping exercises for each release, leaving the final product something barely recognizable from the original intent. In itself, this isn’t a problem. As we learn more about the customer and the problem, pivoting on what the project will deliver is often a good thing. New features and requirements that come during the middle and end phases of a product can sometimes add significant value. But it’s possible and easy to do the opposite.
As projects move along, the final delivery triangulates across the three levers that project teams have to play with: features, cost and time. Most organizations have little appetite for increasing the cost of a project, and they have some tolerance, but not a lot, for slipping a schedule. Many project managers that I know have an “on-time and on-budget” metric that they must hit as part of their performance review. What they are unlikely to have is a “must hit feature list” measurement.
As a project schedule seems less and less likely to represent reality, a good project manager will start calling out schedule risk, and perhaps even turning the project itself yellow. A very easy reaction to this is to cut functionality from the final product, reducing the amount of time it will take to develop, thereby getting it back on schedule. Hooray, the project is back to green. The first couple of times this happens, the team is likely to cut features that aren’t critical to the business case. Sometimes doing this even gets them back to truly green. Other times, the team starts cutting functionality that is actually vital to the product, or they put it in a nebulous “Phase Two” that is unlikely to get funded anyway.
This may mean that the team is reporting that they are on time and on budget, or near enough as to make no difference, but what they are delivering will fail in the market due to lack of features. Everything being measured on the project such as cost, burndown charts, effort, schedule, are all showing as being okay. But the value of the deliverable is suffering, causing the project to be green on the outside, and red on the inside.
