Measuring Project Health

I've been known to say that explaining a single idea so well that it can't be misunderstood takes me about 1,000 words.

Well, yesterday, on the context-driven testing yahoo group, someone asked for sample software metrics, and, short on time, I quipped off a quick three or four sentence reply.

And, of course, I wrote something that may apply some of the time under some situations that was easily mis-understood, and the conversation quickly degenerated.

My Bad. Really, I should have known better. The original poster replied again, asking for ways to measure project health.

Ok, I'll take the bait again, but it's going to be on my blog, it's going to be an essay, and this time, I'm going to write the entire thousand words.


Measuring Project Health

There are all kinds of measures - both formal and informal. I am leery of formal, single-dimensional measures, as they are too easy too game, and last month I wrote "Against Systems" to try to explain why.

So, while there may be metrics like "estimate-to-completion" ratio for project health, you can also gather information about a project informally.

For example, a lot of my work has been with commercial teams in matrixed organizations. So a developer is a member of two "teams" - both the project team and the line team of software developers. When the project is under stress, certain things start to happen:

1) The developer's desk starts to get messy

2) The developer stops making commitments, and changes his language to passive-aggressive "I guess ... if you say so"

3) Personal-responsibility disppears from common use. People start talking about "roles" and "The Process."

4) The developer stops looking at you in the eye when giving status

5) When chosen by the team, tasks stop being measurable. "Put Foo into production" becomes "Finish researching BAR"

6) Status becomes ... hard to figure out. Sample status reports say things like "I got stuck and had to spend an extra seven hours on foo today, but I guess we are ok"

7) Teams start fighting each other by discipline. US Vs. Them starts to happen between developers and testers

8) "Hot Potato" starts to happen on project tasks

9) Builds start to go "over the wall" that are completely hopeless, where the install doesn't even work

10) People start talking an odd tone of voice. When you listen real carefully, you start to pick up on conversations you aren't intended to hear. And they are not good.

11) People stop talking in meetings

12) Fear - be it of layoffs or whatever - enters the workplace

... I could go on and on. The point is that communication stops happening and people get defensive under stress. So, when those things start to happen consistently to the entire team, there is a correlation. That does not imply causation. It's possible, for example, that the stock market just crashed or the most popular person on the team is going through a divorce or was just diagnosed with throat cancer.

Then again, in all three of those cases, the team is going to suffer a decrease in productivity, and, when you think about it, the team is un-healthy. If the team is un-healthy, the project probably is probably in even worse shape.

In my experience, this informal method, often called "Management by Walking Around and listening"(*) can be much more effective than any formal, gannt-chart approach to measuring project health. (Most of my experience is in small project teams of under forty people, often within a larger parent organization.)

Conclusions
Overall, yes, you can have formal approaches to measure project health. Jerry Weinberg, for example, has an excellent book on measurement titled Quality Software Management Volume II: First-Order Measurement. (QSM II) I even recommend the book - but wait ...

Before getting to QSM II, I first recommend three other books that describe informal systems for measurement and management - PeopleWare, Becoming a Technical Leader, and QSM I: Systems Thinking.

Once you've read those books, and given it some good thought, how do you measure your projects? And how should you respond once you have the measurements? Ultimately, like everything else, that's still up to you.

Good Luck.


FootNotes
(*) - For more information about gathering information in a formal vs informal way, Rands in Repose goes so far as to describe the two techniques as two different personality types, and suggests ways of dealing with each one here.