Anecdotes for Project Managers: Cargo Cult

Another anecdote that is really working miracles is Richard Feynman’s story about Cargo Cult. I have to admit that I’m telling my own version. I’ve researched it on my own and massaged it a little bit to focus on the point I’m trying to make.

The situation where this anecdote works best is at milestone meetings, at larger companies: large companies have processes, even for project management. Project management processes typically focus on special milestones with special deliverables and a range of bored senior managers who have to take the decision.

The other day, I started one such meeting by telling the following story:
Continue reading Anecdotes for Project Managers: Cargo Cult


HDWKTWD – a User Story for Tasks

Have you ever experienced that a task has been agreed, and half-way through somebody comes back beaming with the statement “it’s done!”?

Every once in a while, this happens, and it happens more often in distributed teams than in localized ones. The point is: there was no real agreement about when the task is done. I’ve started a new experiment in my teams, I’m starting to add to every task a little “HDWKTWD” section.

What’s “HDWKTWD”? – It’s short for “How Do We Know That We’re Done”. A good task assignment already does that implicitly (compare “discuss the schedule for XYZ” to “agree on a schedule and inform everybody in an email.”), but sometimes it helps to be even more explicit 🙂

User stories deal with the user observable behavior of a system. Who says that this characterization of user stories should apply purely to programming? The trick is: If I’d make a movie – would an outsider be able to judge whether the goal has been reached or not?

In the example: “discuss the schedule”, everybody would be able to see that a discussion has happened – but that’s not the desired outcome. The desired outcome is an agreement. However, the agreement is not visible to an outsider until it’s documented in an email. Hence the re-worded HDWKTWD…

My first impression is that “user observable behavior” ‘s doing good for project management, too.


Decision Analysis III

It’s already a while ago that I presented my Influence Diagram to our sponsors (one may remember the Decision Analysis II article). The main value of the presentation was – as so often – in its preparation:

  • I’ve had my own mind clear on what I suggest and why
  • In the preparation meetings, peers and sponsors had to wrap their head around the entire topic.

So, eventually we had an engaged discussion about a situation most people had pretty well understood. While we didn’t really go through the presentation, we still arrived at – from my point of view – the right conclusions.

And a few days after the meetings, I received an email with four words: “good meeting – unlike most”.

It works.