Some books about software engineering are timeless classics. Among them, written as early as 1975 and still unbelievably relevant, is “The Mythical Man-Month” by Fred Brooks.
Tag Archives: project management
Learning to love the rain
From the attic: I’ve written this years ago but didn’t publish it for one reason or another. It’s not recent, but worth a thought or two anyways… Whatever, here comes:
The other day, I had a very interesting discussion with a friend-colleague-mentor about unpopular truths in large corporate environments.
Lost+Found quote: “What’s going on in the project” (Ward Cunningham)
For questions like, “What’s going on in the project,” we could design a database. But whatever fields we put in the database would turn out to be what’s not important about what’s going on in the project. What’s important about the project is the stuff that you don’t anticipate.
(Ward Cunningham, founder of the first Wiki)
Found at artima developer: “Exploring with Wiki” – A Conversation with Ward Cunningham, by Bill Venners;
October 20, 2003
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.
Decision Analysis II
Getting an objective decision straight despite the Decision Analysis quote from the pervious article has kept me thinking since mid-December.
Meanwhile, I have drawn an Influence Diagram for one of the more tricky questions on the job. First and foremost, drawing the chart has significantly helped clarify my own thoughts, so even if I dump it here and now, it was attention well spent. Analyzing the ~5 decisions, ~25 random variables and ~5 goals that contribute to this one set of decisions was quite enlightening.
To my own surprise, the other day I managed to transform the diagram so that I could actually present it without major unwanted political implications. The breakthrough came when I was about to give up and draw separate diagrams reflecting the assumed preferences of my main stakeholders.
Continue reading Decision Analysis II
… and nothing is going to happen
Today, I had an interesting discussion about empowerment, especially in a weak matrix organization. Eventually, the discussion reminded me of the Obituary of Richard Neustadt, the adviser to several presidents ($) of the USA, in The Economist (November 2003). The central part is (quoted from memory):
“He’ll sit here,” he [Truman] said [about Eisenhower], drumming his fingers on the desk, “and he’ll say, “Do this! Do that! – and nothing is going to happen! – it won’t be a bit like in the army!”
Well… if this is the amount of empowerment the most powerful man on this planet can command – how could I as a project manager as a project manager ask for more?
I think that project management is a lot about convincing and only a little about “empowerment”, and this means that there are three potential problems:
- First, it so happens every once in a while that somebody confuses “empowerment” with “veto right”. Such cases are particularly frequent among so-called internal governance bodies. Yes, this is empowerment in a sense… but it’s “wrong-way-round”. Real empowerment is the power to make things happen, not the power to stop.
- Second, the power to influence or convince actually means that the project manager can build a “bridge” between the project member’s personal goals and the project goals. Clear, aligned, specific goals within the company are a fairly obvious prerequisite to make that work.
- Third (or actually “2b”), incompatibilities of interests between different organizations that contribute to a project obviously break the “empowerment” of the project manager.
So what?
Upon closer inspection, the so-called line managers are often not more empowered: They can’t fire (at least not in Germany), and at least now in the financial crisis, they may have only very little financial freedom like over salaries etc. Don’t tell anybody, though 🙂
Eventually, what it all boils down to is, provocatively exaggerated:
There is no empowerment!
There is dis-empowerment.
There is an illusion of empowerment, and a good project manager knows how to sustain that.