The means, not the end
One of my continual complaints about the way project management is taught and practised is that the focus is on process rather than success. I’ve alluded to this in an earlier post, in which I drew an analogy between the fixation on process and being blinded by a light. Thus transfixed by process, the project manager loses sight of the real objective of the project- which, presumably, is to create high quality deliverables. Preoccupation with process has other negative side-effects too. In a recent post, Scott Berkun points out that it is the reason that project managers [generally] get no respect from those who do “real work” on the project. Project managers are often seen as obsessed with artefacts such as schedules, plans etc., which team members do not see as being critical to project success.
The reality is, project managers are sometimes caught between two conflicting imperatives:
- To get the job done – which requires them to focus on helping the team.
- To satisfy the requirements of project management standards mandated by their organisations or PMOs.
Many project managers focus on the latter, completely ignoring the former. Now, I’m not advocating the wholesale dumping of standards. These should be followed wherever appropriate, but only insofar as they contribute to the project. A lot of process-related stuff is simply administrative stuff that the team will see as irrelevant - stuff that a project manager has to do, but doesn’t contribute to project success. On the other hand, there are several things – not mandated by methodologies – that a project managers can do to really help the team focus on outcomes. Here are some of them:
- Minimise distractions and irritants: This amounts to keeping bureaucratic overhead inflicted on the team to a bare minimum. The project manager should be taking care of all administrative work, involving team members only when absolutely necessary. A distraction (or should I say, irritant) familiar to most is the unnecessary meeting. Forget regular status meetings, if possible. If you absolutely must have it, restrict it to a 10 minute stand-up affair.
- No surprises: A project manager needs to anticipate potential problems or risks. In my opinion one of the main functions of a project manager is to foresee and avoid nasty surprises, or project banana skins as I’ve called them in an earlier piece.
- Empower the team: Those who do the work are best placed to make decisions regarding the work. Sure, the project manager needs to ensure that decisions made are consistent with project goals and don’t create any conflict, but the decision itself is best left to the experts who are doing the work. This brings me to the last point which is to
- Get out of the way: The project team knows what they have to do. Leave them to it. Many project managers (particularly those with a strong technical background) feel the compulsive need to get involved in details. Team members will view such behaviour as interference at best, or micromanagement at worst. Don’t do it.
Processes and methodologies sometimes get in the way of project work because of the undue importance accorded to these by project (and programme) managers who really should know better. Despite the requirements of PMOs, the real aim of a project isn’t the creation of project management artefacts. Project managers are far better served by focusing on the objectives of the project, and helping their teams do the same. Methodologies and processes should be tailored to help one do so – even on a per-project basis, if necessary. Remember, they are only the means, not the end.