I’ve been thinking recently about the various roles project stakeholders play, and how they may distort the environment around a project until that distortion in turn impacts the reality of the project. Let me offer two key examples. The first, coined by Scott Ambler, is known as greenshifting. In this case, the further information moves from the team, the better – hence “green” on a status report – the project looks. This is a common dynamic, one that most people have experienced first hand. The team members report out numerous challenges, which the project manager – who is there to make sure problems don’t emerge of course – puts as positive a spin on it as he can. This may get filtered up through any number of managers who need to present their work in the best light, such that a project under serious duress will appear to be in perfectly good shape.In my experience I have seen this play out numerous times, as well as the opposite dimension where a project may have some challenges but be fundamentally sound. However, it crossed some invisible line somewhere within the organization and was thus declared a problem. One project I worked on delivered more product, over significantly better quality (quantitatively and qualitatively) than any similar project in that domain. This little Agile project had raving stakeholders, and yet there was the program manager talking about solving our “budget problem”, as it ended up relying too heavily on one external contracting company over some other vendors. While the total budget was consistent with the original estimate, dollars were coming from the wrong line item and that was causing problems upstream. In another pilot Agile project, stakeholders were incredibly involved in the project, so involved that they continued to give feedback, making requests even after the project finished. Unfortunately, the organization had no way to track such requests beyond the project, and they got logged in the enterprise bug tracker. They later showed up as defects and the project became branded as having poor quality because the further you moved away from the project, the more these pieces of information distorted.
The Impact of Shifting Perceptions
Both of these types of situations can cause serious problems, notably for Agile projects. Green shifting disables feedback loops and shuts down learning. As escalated issues disappear before the team’s very eyes, they move in one of two directions. Either they aggressively raise every single issue in an attempt to pierce the bubble, leading to acrimonious relationships and broken trust between the team and management, or they simply stop reporting issues, and everything looks very good… until it doesn’t. One of my coworker retold to me a story he had at one organization where he led a change initiative to help a CIO who famously quipped, “all our metrics say green, and yet we lose money every quarter”.
Meanwhile, red shifting can end up killing change initiatives. Organizations that redshift will end up finding failure in every project they pursue. The challenge becomes that the clustering effect shows that it’s okay to be wrong, as long as you are consistent with your peers. If we look across the spectrum – financial markets, geopolitical developments, you name it – supposed experts can be wrong all the time, as long as they are consistent with those around them. This is where change initiatives die. If everything will end up being called a failure, and you are pioneering a new process, like say Scrum or lean, then invariably someone will pick over the declared failure of your project and say, “ah ha! Here’s the culprit”. In this type of environment, those that don’t look like all the others are quickly ejected from the system. It can be a powerful homogenizing force and undermine any change effort.
Now comes the really weird part. I have seen organizations simultaneously green and red shift, on the same project, at the same time. How does this happen? It is the simple outgrowth of the modern large organization which may have a project spanning numerous different stakeholders with different perspectives, motives, and concerns. One group may feel compelled to see the project succeed, and thus optimistically “greenshift” to make things sound better than they are. Sadly, Agile projects are not immune from this, as I have seen people want Agile projects succeed so much that they may fall into this trap in spite of the various feedback loops available to them. At the same time, another stakeholder, let’s say a group of architects, may redshift the project because they keep hearing that developers are refactoring code or that they have yet to see what they consider to be a satisfactory design. Who is right in this situation? We could make it even more complex. Let’s say the PMO is redshifting, because they value some metric for on time delivery, a metric the team is going to miss. Meanwhile, the QA team is raving about this project, as the code quality is significantly better than they’ve ever seen before. These situations are indicative of a failure to establish a single, agreed upon definition of success. It’s not that any one person in the earlier situations was wrong, but with no agreed upon reference, some may reflect that things are going great, others that it is going much, much worse. This can create a huge amount of noise in the system, and also encourage political fighting as each group tries to establish their narrative as the most important one.
The Sources of Shifting
Ultimately, I see that the amount of perception shifting a project experiences will be the function of three dynamics, the interests of different stakeholders, how far removed they are from direct insight into the project, and the medium through which they get information. Different perspectives will invariably lead to some individuals thinking much more or much less of a project. Meanwhile, the further they are from hearing precisely what’s going on in the project, the more likely the message they hear will be distorted.
The first challenge then is to establish a common point of reference amongst stakeholders. This is a critical factor in any project, so that when people hear a project is in trouble or doing well, they understand “by what measure”. What we’re talking about is basically some version of the iron triangle; we have multiple dimensions, and can not optimize on all of them at once. To try and say everything is important is to say that nothing is. Of course, projects may have many more dimensions than just the three traditional ones measured by PMI. Customer satisfaction, market penetration, team morale, legal compliance, and any other number of factors may weigh into how different people evaluate a project. Rob Thomsett in his book Radical Project Management, outlined a concept he called success sliders. This type of a tool is a powerful way to help gain better insight into the motivation of stakeholders and align interests. Below is an example done with a series of different stakeholders.
In this case, we have seven different individuals rating seven different dimensions. They must force rank their selections from most important to least. The visual chart allows us to see everyone’s relative weighting. The point of this process isn’t to put criteria to a vote, nor is it to offer teams an “out” in case they get in trouble, but rather to help gain insight into the nature of a project. Some dimensions, like quality, we see near universal agreement on, this information will help the team when they have to make a million individual decisions in execution that they should not take shortcuts that would sacrifice quality. Conversely, we see that timely delivery is actually a lower priority compared to the other dimensions. This discovery can help us better evaluate the true health of a project should we see delays but quality holds up. Some of the even more interesting data points are the ones like performance or budget. Here, we see a few people far away from the crowd. They may have a piece of information the other don’t that is influencing their decision. This exercise helps elicit this discontinuities so that everyone can have a better perspective. When doing this type of exercise with clients, we will frequently start by sampling the group, like illustrated above, and then see if the team can agree on a single set of priorities. Thereby helping us be very clear what we mean when we say a project is doing well or poorly.
Bring Stakeholders Close to Projects
Everything distorts with distance and perception of a project is no exception. As the children’s game of telephone illustrates, messages can become distorted to the point of absurdity when passed through too many filters. Thus, the project that reports a status which is rolled up into several times into – each time being re-interpreted and summarized – will invariably shift one way or the other. Or, the message may be shifted based on the audience, and what people may think they want to, or should, hear. One of the most powerful techniques I have seen was introduced to me by a coworker, Alex Singh, who organizes one single status meeting for his projects. He generally recommends that managers or stakeholders who want to know what’s going on don’t attend the stand up, but rather go to this one meeting. Regardless of position, function, or part of the company, everyone shares the same status meeting. Thus, the technology group hears the same message the business hears, which is the same the PMO hears. Even better, they hear each others’ concerns and questions. In organizations that have fallen deep into silos, I really can’t describe how powerful this simple concept is and how much credibility it creates for the team.
Choose Your Medium Carefully
Messages change based upon the medium through which they are conveyed. I can’t say precisely why, but I suspect it has to do with the likelihood it can be disseminated to a broader audience. Electronic reports and dashboards are the most likely to travel far and wide as someone can easily forward it on to an innumerable amount of other people with little or no context, and in my experience those are the most likely to green shift. Although within this domain, no single metric is as worthless and likely to green shift as the red / yellow / green status indicator. I wish I understood why, perhaps its the visceral immediacy of that near-universal color coding, but I have found this metric to greenshift so horribly that by the time it shows anything but “green”, the project is already doomed.
Conversely, personal one on one conversations are impossible to perfectly reproduce. They generally have a level of trust accompanying direct, human interaction, and in my experience those are the least likely to shift. It’s worth pointing out that the conversation is also two way and dynamic, so if someone becomes concerned, the speaker can quickly adjust what they are saying and address the concern. Of course these conversations take time and can be more costly to disseminate. I have found that physical information radiators strike a happy balance. They provide consistent information in a quick format, like a digital dashboard. Simultaneously, their physical nature prevents them from being forwarded easily to everyone. In fact, when they are set up in close proximity to the team, if someone sees something concerning, they can quickly talk to someone to better understand the context. Thus, they offer the best of both worlds.
In the End, Perception May Become Reality
Agile is all about empirical results, so I can see a certain strain of thought that would dismiss these issues as the actual release would wipe away any misconceptions around a project. Unfortunately, sometimes perception may influence reality more than we’d like. In some large organizations, especially where the system in question is not actually tied to sales or some other qualitatively definitive measure, perception of those around a project can matter profoundly. If stakeholder expectations are never aligned, or discontinuities at least identified, then some very powerful people within organizations can come to the conclusion that Agile doesn’t work for them and seek to undermine the use of it. In fact, one of my favorite tales is George Schtliz’s tale of “Jorge the Pig“, his parable for the project he ran perfectly, but then got shut down anyway because he didn’t manage his stakeholders.
Shifting may impact a project in other ways as well. A redshifting project will invariably have managers somewhere escalating issues forcing team members to prepare more status reports, go speak at more meetings and in many ways spend time dealing with organizational swirl rather than delivering product. Conversely, a greenshifting project may never get the management attention required to clear its impediments until it is too late. Indeed, these optical illusions can prove deadly to your project and a savvy team takes them into account.