BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Is Project Status Relative?

by Deborah Hartmann Preuss on Aug 22, 2006 |
Inveterate watchers of PBS documentaries will already know as a star moves away from an observer, its colour does a "red-shift", and while moving toward the observer a "blue-shift" occurs.  Project watchers will be equally aware of the phenomenon Scott Ambler is calling the "green shift" which occurs when people rework the information contained in status reports to make them more politically palatable to their manager.

It would be funny if it didn't cause so much consternation: the idea is that project status will increasingly "green shift", e.g. improve, the more political filters that it goes through.  For example, I tell my manager that the project status is red, he tells his manager that it's yellow, and she tells her manager that things are going perfectly fine.  Then a developer has a twilight-zone experience in which she runs into a senior exec in the elevator and receives warm accolades for some mysterious team "success" of which she knows absolutely nothing.  This certainly explains why some places discourage developers from talking to management, doesn't it? 

But can management handle the truth?  Can they afford not to?  Ambler proposes that green shifting is a significant contributor to project failure.  If senior management is unable to find out the true status of a project, then they will be unable to bring resources to bear to fix the problem(s) before it's too late.  Ambler looks at how Agile teams develop project status transparency with management, in his recent article "Green Shift Anti-Pattern" written for the Doctor Dobbs Journal newsletter. 

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Why use subjective measures? by Les Walker

I have to disagree with the assumption here that people who report status just look at all the indications and make up a status of red, yellow, or green. I would find such a system pretty frightening. Measurements should not be "how much more do you think you have to go?" but "how much can you demonstrate that you've done?"

Development plans should be oriented towards what will be demonstrable at different milestones. Milestones should be close enough together that you get a reasonable granularity of reporting. If you make your milestone, you're green. If you don't, you fail the entire feature delivery and you're yellow. Fail enough deliveries and you're red. Lie about it even one time and you're fired.

Agile helps because you're always moving forward and QA/QE engineers can be looking at the software at any point in time and verifying that the features that you claimed to be ready with are actually ready. Scrum meetings are probably pretty good for getting fingerspitzengefuhl -- (how's that for a word) -- but just removing layers of subjective interpretation doesn't really give you accurate status.

Re: Why use subjective measures? by Deborah Hartmann

Hi Les.
I have to disagree with the assumption here that people who report status just look at all the indications and make up a status of red, yellow, or green. I would find such a system pretty frightening."
I have to agree - it's scary, and useless too.

But I've observed precisely such a meeting. I've watched participants "look at the indications", agree that they were in red, but decide to "let someone else go red this week, we did it last week", finally settling on yellow. Ack!

Hmmm, now that I think about it, maybe that was the original seed for my Appropriate Agile Metrics paper, lol.

deb

Re: Why use subjective measures? by Marc Stock

You can disagree but it doesn't change the fact that this is a common phenomenon. It happens because managers (the higher the level, the more likely) don't want to deliver bad news to their bosses because they fear (rightly or wrongly) that one or more of the following will happen:

1) their career at the company will be jeopardized because they will develop a reputation for not getting things done.

2) it will impact their bonus.

3) they will lose their job.

Consequently, when the project runs late and senior management finally finds out that the deadline won't be met, they're surprised and furious (and oh...look at the budget!). I don't know what the lower level managers say to them other than, "it looked like we were gonna make it and I'm surprised too" even though they knew damn well the project was in trouble. As a developer, I'm always curious as to whether the senior management thinks that the lower/mid-level managers were just blowing sunshine up their rears or if they think the development team was hiding it.

That said, Mr. Ambler pointing out this as an anti-pattern is like pointing out that touching the lit end of a blow torch isn't very smart.

Re: Why use subjective measures? by Les Walker

Yes, I misspoke. What I meant to say is that they "shouldn't," not that they "don't." The tone of this article is that it's okay as long as you reduce the level of filtering. He seems to be answering yes to the question of the title. I disagree. Any filtering is enough to wildly distort the picture that the owners see of the project's status.

Re: Why use subjective measures? by Deborah Hartmann

Any filtering is enough to wildly distort the picture that the owners see of the project's status.
One of my favourite words when I'm teaching Agile is "transparency" :-)

Gives us something to strive for, at least.

But it's written right here! - was: Re: Why use subjective measures? by Deborah Hartmann

Mr. Ambler pointing out this as an anti-pattern is like pointing out that touching the lit end of a blow torch isn't very smart.
Yes, for you and me, sure. But doesn't it help, sometimes, to have collateral to back up what you're telling sceptical colleagues?

The way the big boys do it by j c

Dont rely on status. Put someone in charge of the project and tell them the date.

When they miss it fire them immediately.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

7 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT