Archive for the ‘Project Management’ Category
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.
A cliche-ridden corporate crisis in five limericks
In times of crisis, some managers tend to lapse into cliche-speak. So it’s no surprise that things go from bad to verse…
Market churn has set us adrift.
What we need is a paradigm shift.
Get our ducks in a row,
push the envelope,
to keep us from going o’er the cliff.
The boss says, “Let’s touch base.
Make game-plans for the next phase.
We’ll have meetings and talks.
Think outside the box,
to ensure we’re still in the race.”
But the elephant in the room
refuses to sing to our tune,
or dance to our beat,
sing from the same sheet
– even once in a blue moon.
Chin up! We’re still in the ring.
The fat lady hasn’t started to sing.
It ain’t over, they say,
’til it’s over, so hey,
let’s see what the new day will bring.
In the end, we stake our claim
to fifteen seconds of fame.
All said and done,
we’ve hit a home run
in the dying minutes of the game.
Incidentally, portions of this piece have been reproduced as an epigram in Chapter 1 of my book, The Heretic’s Guide to Best Practices. Quite appropriately, that chapter is entitled, Platitudes: empty words that make a lot of noise…
A pert myth
PERT (Program Evaluation and Review Technique) is a stock standard method to manage project schedule risk. It is taught (or at least mentioned) in just about every project management course. PERT was first used (and is considered to have originated) in the Polaris project, and is often credited as being one of the main reasons for the the success of that endeavour. The truth is considerably more nuanced: it turns out that PERT was used on the Polaris project more as PR than PM. It was often applied “after the fact” – when generating reports for Congress, who held the project purse-strings. This post is a brief look into the PERT myth, based on sources available online.
An excellent place to start is Glen Alleman’s post from 2005 entitled, Origins and Myth of PERT1. Glen draws attention to a RAND Corporation publication entitled, Quantitative Risk Analysis for Project Management – A Critical Review, written by Lionel Galway. The paper is essentially a survey of quantitative risk management and analysis techniques. The author has this to say about PERT:
…PERT was a great success from a public relations point of view, although only a relatively small portion of the Polaris program was ever managed using the technique. And this success led to adaptations of PERT such as PERT/cost that attempted to address cost issues as well. While PERT was widely acclaimed by the business and defense communities in the 1960s, later studies raised doubts about whether PERT contributed much to the management success of the Polaris project. Many contended that its primary contribution was to deflect management interference by the Navy and DoD (Department of Defense) by providing a “cover” of disciplined, quantitative, management carried out by modern methodologies…
Then, in the conclusion of the paper, he states:
…While the Polaris program touted PERT as a breakthrough in project management, as noted above not even a majority of the tasks in the project were controlled with PERT. Klementowski’s thesis in the late 1970s, although limited for generalization by the sampling technique, showed less than a majority of organizations using CPM/PERT techniques. And the interviews conducted for this report revealed a similar ambivalence: respondents affirmed the usefulness of the techniques in general, but did not provide much in the way of particular examples…
In a footnote on page 10 of the paper, the author draws attention to Sapolsky’s book The Polaris System Development: Bureaucratic and Programmatic Success in Government. Among other things, the book describes how the use of PERT on the project has been grossly overstated. Unfortunately the book is out of print, but there is an excellent review of it on Cadmus. The review has this to say about the use of PERT on the Polaris project:
…SPO (Special Projects Office) Director Vice Admiral William F. Raborn pushed PERT mercilessly. The colorful PERT charts impressed everyone, and coupled with the nature of the project, they exuded management “sex appeal.” This kept other DoD poachers at bay and politicians off SPO’s back. Other government services became so enamored with PERT, they quickly made it a requirement in subsequent contracts.A more objective assessment of PERT is that the network analysis2 is the major benefit. PERT can reduce cost and time overruns, and make its practitioners look like better managers…
The Royal Navy knew of the over-inflated success of PERT when it embarked on its own Polaris program in the 1960’s. The Royal Navy deliberately adopted PERT, essentially to keep Whitehall, Parliament and other critics away from their project. It worked just as well for the RN as it did for the USN
…
I found the accounts of PERT presented in these sources fascinating, because they highlight how project management history can be so much more ambiguous (and messier) than textbooks, teachers and trainers would have us believe. Techniques are often taught without any regard to their origins and limitations. Thus disassociated from their origins, they take on a life of their own leading to myths where from it is difficult to separate fact from fiction.
1 Glen Alleman also discusses some limitations of PERT in this and another post on his blog.
2 Network analysis refers to task sequencing (precedence and dependencies) rather than task durations.
Eight to Late 