One of the things a project manager should do for her team is to tell them about the weather. Is it sunny (we’re running to schedule with a happy client and a good product being produced), cloudy (a bit behind schedule with a happy client and acceptable product), stormy (behind schedule, unhappy client) or has an asteriod just hit?

A quick run-down from the PM each week is all that’s needed to keep everyone in touch. Without this information the team can’t make decisions in the right context and the project will inevitably suffer. This is more than just news. It needs to be analysis of the news, information.

An added bonus is that the team members, who know more about their own “neck-of-the-project” than everyone else, might be prompted to tell the PM something she doesn’t know, which will help the project.

P.S. I’ve never actually tried reporting to a team about the state of a project using a weather-based scale. People don’t tend to like analogies as much as I do (I love them) and so I’ve always feared their reaction (I’m thinking of you here Evil Sam). Instead I use normal, boring words.

I have a rule of thumb for determining how much undetected slippage will occur for any task. Its pretty high-tech and may challenge those of you who don’t have high-falutin university degrees.

The amount of undetected slippage that can occur on a task that was scheduled to take X, where X is in the range of one hour to one week, is X.

Pretty great eh? In other words if something is supposed to take a day and something goes wrong that causes the task to blow-out then, taking into account the realities of people and project dynamics, its likely that it won’t be until one day after the task was due to finish that it will be detected by “management”.

I know what you’re thinking. What about on a project with a daily progress meeting or one of those agile projects? I think the chances are that the slip still won’t be detected. People and group dynamics are just like that.

I have been thinking about the evolution of testing in “agile” projects. As the nerds get better at building software more reliably (via automated unit and integration tests) the need for manual testing is thankfully diminishing. This seems to be leading to testers morphing into either:

1. QA developers – who are basically developers who spend most of their time working on automated tests and associated frameworks; or
2. Tech savvy, proxy customers – who start to act as a type of detail-oriented business analyst.

The types of things I see testers doing more and more are — acting as stand-in customers by gaining a deep understanding of business rules and needs, reviewing acceptance test plans, challenging developers to keep up to date with automated regression/integration tests (which the tester will regularly use) and negotiating compromises.

This new breed of tester provides a link between the detail heavy, day-to-day reality of development and the customer needs. Importantly they act as a customer proxy in the private meetings that a company has where customers aren’t welcome. The very type of meeting where customer needs are often sold short for the convenience of the team. They basically help to keep the team honest.

Recent posts

Nerdherding for Beginners is written by Michael Harmer, released under the Creative Commons Attribution-Noncommercial 2.5 Australia licence powered by WordPress and designed by XiAP Design Studio.