Labelling in Outlook 2003 ala Gmail
Time tracking tools
Outlook 2003 + Flags = todo list
Scrum for Self : V2
ADD and antipatterns
« CSV to ASCII Grid
» Kerala moves on in conservation
Jonathan Petersen has a nice post on using weblogs as project management tools. He makes some very valid points about current state-of-affairs in normal project management. Using blogs for that might work, but I’m a bit sceptical.
Most IT organization have 3 project management tools:
- email - used for workflow, document revision control, and messaging (well and for ass-covering to be honest)
- Microsoft Project - used for work breakdown and progress tracking
- Microsoft Powerpoint - used for project status/rollup reporting to senior management
Amen!
In a traditional large corporate IT department the following happens when the CIO asks why a project went from green to red since the last program review meeting:
- The program manager who owns the project would dig through his email for the last couple project status reports (most likely an attached Word doc form).
- The program manager would then call the PM to get additional details of the problem.
- The PM would likely dig through HIS email to find the right thread from his development team.
- The PM and development team would likely pull together a meeting to ensure that they have a clear risk management plan and communicate that back to the program office (in a widely cc:ed email)
- The program manager asks a couple questions, updates a batch of cross-project timeline graphics and reworks their Powerpoint deck for the next program review meeting.
Double Amen!
Jonathan suggests a key point when using blogs for PM.
“The PM would subscribe to all those blogs and would publish a roll-up blog with links to details of various issues.”
I think this is a great idea. Practically, this might be a problem. For most PMs, this means a shift in mind-set. Generally, PMs tend to think that their job is not publishing to a vast audience, but to a limited audience that they know trust them. Now, this goes directly against - a usually accepted in theory, but seldom practiced - notion of 100% transparency. It is this reality that results in narrow-casted PowerPoint presentations that are intended to WOW the limited audience, without ever drilling into details. It is also the reality that results in focussing on accountability by a very finite set of people over a very finite period of time - the duration of the presentation.
That finiteness is a great comfort to PMs. Couple that with traditional e-mail oriented way of working, you have limited chance to go back and refer to some thing, when you have an AHA moment. Blogs and a browser supports AHA moments whenever they arise. This may not be a good thing, because it takes out finiteness of duration. People get to think later and to refer back later to make their own conclusions. Compare this with having to call the PM about the presentation - in that situation, you may not get enough time/leisure to make your own conclusions.
Additionally, it vastly increases the finite pool of people who can be aware of project status. This, might be a big problem for people who love their comfort zones!
A big difference blogging has with traditional PM status reporting is that bloggers want as many people as possible to read what they write, because they are proud of what they are and what they do. Traditional status reporting may be thought of as people with powers ask questions, but no one else.
So, for organizations that preach flat structure and not hierarchies, I believe blogs are the way to go. Sure, the information might be unstructured. This is not a difficult problem to solve with proper categorization.
One problem blogs don’t solve is that of planning. Strategies like instant outlining might help. Additional help can be had if a project team tries to answer the question: “How much detailed planning is there NOW?” - honestly
The real beauty of blogging for PM is that it evolves. Which means, it supports the simple mind-set of Observe, Analyze, Adjust. This is far better than trying to speculate an operational and procedural problem and then finding solutions - which usually results in costly software rollout and too much over-head during usage. Most IT departments don’t have the skill sets necessary to roll out their own custom software for process control. Most software vendors that have the skill set will try to make as generic a software as possible. Result: you have the classic issue of inertia (don't-want-change-mind-set) meeting high energy (we-paid-so-much-let-us-use-this).
Jonathan closes with a triple AMEN point:
“ The real problem is ones of politics. What are all those IT middle managers going to be doing to justify their salaries? I can’t answer that, but just imagine the productivity gains that might be had if the time and work of review and status meetings was put into actually solving problems instead of talking about them? ”
via Phil Windley - with great set of additional links.
Will blogs work for PM? I think it will.
Great comments and greatly appreciated. I particularly like your bullet point rationale.
http://www.corante.com/amateur/archives20030601.html#38525
Frank Patrick's focussed performance business blog have additional thoughts on this:
http://www.focusedperformance.com/2003_06_01_blarch.html#200401184
Proposal for a P-Log specification:
http://halmacomber.com/p-log_draft_spec.html
Very neat and a good start. Most of the needs can be met by MovableType or Plone.
And a schema for project vocabulary specification:
http://ideagraph.net/xmlns/project/