BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Is Project Status Relative?

Is Project Status Relative?

Bookmarks
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. 

Rate this Article

Adoption
Style

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.

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

Community comments

  • Why use subjective measures?

    by Les Walker,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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) Preuss,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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) Preuss,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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) Preuss,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

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

BT