I’m here in Rome this week, presenting a two-day seminar on  “Managing Death-March Projects” for Technology Transfer Institute. You should be there so you can hear whatever clever jokes may occur to me while I’m presenting my material, as well as the comments and questions from the other participants. But if you’re stuck in some other part of the world, or you couldn’t persuade your boss to send you to Rome, you can click here to download the (17MB) PDF version of the presentation, which has a whole  bunch of embedded links to other presentations, publications, books, articles, websites, etc.

Here’s a summary of the additions, changes, and corrections that I made in V54; for convenience, you’ll also find that they appear in red in the PDF materials, so you can see what has changed since V52 and V53:

1. On page 70, I added Google Maps to the list of Ajax examples.
2. On page 84, I added Google App Engine to the list of interesting products from Google.
3. On page 85, I provided a new (working) link and details about Zimbra.
4. On page 87, I added a link to IBM’s new “Bluehouse” product.
5. On pages 89-90, I added two new pages of details on the iPhone 3g.
6. On page 91, I provided additional details on CIsco’s acquisition of Five Across.
7. On page 132, I added a bullet point with a link to Nicholas Carr’s article on “Is Google Making Us Stupid?“

I probably won’t do any more updates for another week or two, but this should keep you busy for a while. Enjoy…

Here’s the presentation:

You should attend in person, if possible, so you can not only hear my presentation, but also some excellent talks by Beth Layman and Larry Dribin on other aspects of software metrics. But if you can’t find an excuse for coming to Rochester, then there’s a fallback option: you can download the 2.5MB PDF version of the presentation by simply clicking on the image below …

Happy reading!

Those are all important topics, and I suspect a lot of people need advice and guidance about the why, the what, and the how. But I don’t think it provides us with any insight or understanding about a depressing metric about metrics initiatives: only about 10% of newly-initiated metrics programs survive more than 18 months. They may be started with great fanfare and enthusiasm, and with the best of intentions; but they often have trouble getting past the first annual budget review. And they may suffer from lack of support, hostility, or outright mutiny.

The reason, quite simply, is politics. People are people, and it’s human nature to react in a variety of ways — not always positive! — to the notion of having one’s work measured. Based on my consulting work, project reviews, and visits to many, many IT organizations over the years, I’ve assembled a “baker’s dozen” list of 13 common political problems associated with metrics initiatives. Most of them will strike you as obvious and “common sense” — but that doesn’t mean they don’t happen.

Here’s the list:

1. Metrics are often used to “punish” people — e.g., to criticize them for bugs, or to fire the people with the lowest productivity.
2. A common perception is that newly-introduced metrics will be used to punish people — even if that’s not what management had in mind.
3. Metrics are sometimes used (or misused) as leverage in highly political negotiations about deadlines, budgets, and staffing in high-pressure, risky projects.
4. “Unintended consequences” — the introduction of a metrics initiative is likely to have “feedback loop” consequences that nobody expected or intended.
5. IT organizations sometimes introduce a metrics initiative that measures hundreds of different things, thus overwhelming everyone with a mountain of data.
6. Other IT organizations introduce a metrics initiative that focuses on only one measurement — e.g., programmer productivity measured in lines of code per person-month.
7. Management doesn’t realize that, in many cases, you get what you measure — e.g., if you create the impression that people will be measured by how many lines of code they write, then they’ll write lots of code, even if it’s buggy, stupid code.
8. The Hawthorne Effect.
9. The perception that the metrics data gathered by the newly-introduced metrics initiative will be kept secret, and not shared with the people doing the work.
10. The perception that the metrics data will be completely ignored by management.
11. The perception that, even if management does review the metrics results, they won’t take appropriate action — e.g., they’ll try to hide or bury the problem, or blame someone else for the embarrassing metrics.
12. The perception that the metrics results are not credible (sometimes, again, because management doesn’t want the world to see just how bad the metrics really are).
13. The perception that gathering/recording of metrics data will take too much time, and that it’s not productive — e.g., the reaction from software engineers that “we should be doing our work, not spending all of our time measuring the work that we don’t have time to do!”

If you have any additional items to add to this list, please let me know. And if you’ve seen (or created) any particularly clever ideas to solve, reduce, minimize, or avoid any of these problems, please let me know about that, too.

Meanwhile, I’ll add some additional thoughts and ideas about this area, as time permits, over the next few weeks.

As usual, I’ve provided several different ways of downloading the presentation materials. None of the material is copyrighted; it’s all “open source,” and you’re welcome to use it, modify it, share it with friends and colleagues, and collaborate with me to improve it in the days to come. For a simple overview of the presentation, you can click here to download the one-page, 24-megabyte PDF version of the “mind-map” shown below. This is likely to make more sense after you’ve seen the full set of materials, but it’s a nice concise summary of the key elements of the presentation.

You can also click here to download a 10.4-megabyte PDF version of the 19-page presentation itself; all of the embedded hyperlinks have been preserved, so you can follow the references to wherever they lead you. You can also find this version on my Slideshare.net page, which makes it easy to share the material with other people in your own network.

A couple days ago, in Ft. Lauderdale, I also made a Powerpoint version available; but I discovered that moving a Powerpoint file from the Mac to Windows is problematic, especially if you’re using something other than the usual boring Arial/Helvetica fonts; and since I find Powerpoint to be a pain in the neck anyway, I’ve thrown it out. If you have the good sense to be using a Macintosh and iWork, then you can click here to download the 15-megabyte Keynote file of the same presentation (which has the animations and builds that you won’t see in the PDF version, plus the native ability to modify the material). And finally, if you’d like to see the “collaborative” version (which is much uglier, but nevertheless sharable), click here to see the Google Apps version of the same material; if you actually want to modify this version, send me an email and I’ll add you to the list of collaborators.

Hopefully, this will be sufficient to let you view and access the materials in a way that’s convenient for you. If you have any questions or problems, please let me know. Meanwhile, enjoy …

For a simple overview of the presentation, you can click here to download the one-page, 23-megabyte PDF version of the “mind-map” shown below. This is likely to make more sense after you’ve seen the full set of materials, but it’s a nice concise summary of the key elements of the presentation.

You can also click here to download a 9-megabyte PDF version of the 19-page presentation itself; all of the embedded hyperlinks have been preserved, so you can follow the references to wherever they lead you. You can also find this version on my Slideshare.net page, which makes it easy to share the material with other people in your own network.

If you’d prefer a Powerpoint version of the same material, click here to download the 18-megabyte Powerpoint file. If you’re lucky enough to have a Macintosh and iWork, then you can click here to download the 13.2 Keynote file of the same presentation. And finally, if you’d like to see the “collaborative” version (which is much uglier, but nevertheless sharable), click here to see the Google Apps version of the same material; if you actually want to modify this version, send me an email and I’ll add you to the list of collaborators.

Hopefully, this will be sufficient to let you view and access the materials in a way that’s convenient for you. If you have any questions or problems, please let me know. Meanwhile, enjoy …

To download the 20.5-megabyte PDF of the mind-map summary of this presentation, click here (or on the thumbnail icon above). The hyperlinks are preserved in the PDF file, so you’ll see clickable links that you can pursue to get more information on 18 recommended books, and 41 other references (articles, websites, blog articles, etc.) on key aspects of software engineering.

For the fans who follow this blog closely, you may recall seeing a similar mind-map for a “Top Ten” presentation that I did in Jacksonville, Florida a couple weeks ago. Here is a summary of the additions/changes I’ve added to that material for tomorrow’s presentation in Albany:

1. For the mind-map branch that refers to Google HR strategy, I’ve now found an interesting article in the Oct 21, 2007 issue of The New York Times, entitled “The Google Way: Give Engineers Room.”
2. As an additional reference on “peopleware” issues, I’ve included a relatively new book entitled Leading Geeks.
3. For the mind-map branch that refers to “evidence-based scheduling,” I’ve found a better reference: a very detailed Oct 26, 2007 blog posting entitled “Evidence-Based Scheduling” (duh!) by Joel Spolsky, of New York City’s Fog Creek Software. Highly recommended!

Let me know if you have any suggestions for improving the material …