Labelling in Outlook 2003 ala Gmail
Time tracking tools
Outlook 2003 + Flags = todo list
Scrum for Self : V2
ADD and antipatterns
« Preventing duplicates in VARRAY columns
» Intepreter of Maladies
One of my basic beliefs about project management is that it’s first and foremost about promises -- making reasonable promises and keeping them. As I’ve written elsewhere, effective project management is about turning significantly uncertain efforts into reasonably certain outcomes. That’s the outcome. That’s the "why" associated with project management. But the question that I had in mind with this new spin was more related to "how?"
If project management is the answer, what’s the question? My contention is that it’s "What should I be working on?"
A must-read for all project managers. I like extend this a little bit.
In a typical software development project, a project manager should act as a good conduit between customers and resources. The measure of being a good conduit is how effective the project manager is in reducing the surprises. In both directions.
Customers will have change requests mid-way through the project. Resources will have technical difficulties, allocation issues etc. In such situations, the manager’s ability to do the following will mean life and death for the project:
The last point is crucial. If a project manager is fond of communication, but not on effective communication, there is a good chance that he or she will amplify the disruption in both directions! This is really bad.
These days, I realize every management consultant likes to put in a point about human factor in change management in just about anything they try to convey ;-) Yet, an effective project manager of an on-going project needs to be able to act as an absorber of changes. Their primary goal should be to have a firm grasp on what is going on now and their secondary goal is to have a firm command over what ought to happen next.
It is a difficult job. My experience is that having a regular project manager and a backup project manager helps a great deal. The backup manager need not be a full time project manager. A practice I used to follow was to have the regular manager manage it from Monday to Thursday. On Friday, the backup manager takes over for that day. This ensured an automatic QA for the management data. It made the project a bit more agile in that it is not entirely dependent on one person. It helped the career aspirations of the backup managers. It really helped to assign different resources as backup managers every week. Definitely creates an impression in the team that there are no levels and that we were in this together, with distributed accountability and responsibility.