How not to do Project Management

When you are taken on for a project management role, or allocated to lead a project, it is easy to assume that key people in the organisation know and understand your role, and that you understand all the problems. Big mistake. Here are five fatal assumptions that you can make about what you do, and what they think about it. 1 …

[Bruno Girin]

No news is good news (not)

The best project manager I ever worked with had a mantra that he repeated to everybody in the team on a regular basis: "I don't care if it's good new or bad news, just tell me". The idea was that the earlier he knew about changes, good or bad, the better he could plan ahead and navigate around the icebergs and floating containers with minimal effort.

In practice, this is an issue I've seen on so many projects: people who would withhold bad news until the last minute, at which point it was too late to do anything sensible about it, resulting in massive impact on timelines and budgets.

[Matt Bryant]

Two biggest hurdles I see for PMs.

First, put simply, is cost. Internal PMs have to be kept busy as management don't like seeing them sitting idle, which gives very little time for the PMs to post mortem, compare notes or train themselves for new technologies. Any delay in a project can leave them racing to complete as they have another project waiting to go, or trying to run several projects at once. External PMs, whom are brought in as part of a project sold to us by a third-party, suffer from the problem that they do not control either budgets or how the budget has been realised. I have lost count of the number of times when I have sat in a meeting with a salesgrunt and he has tried to cut the cost of his proposal by trimming out PM days. If we are taking PM work from an external, I ask for the PM to be in on the planning BEFORE the sale, so we actually get some realistic planning, as otherwise there are all types of political shenanigans as the salesgrunt sees his margin (and therefore his commission) disappearing in unexpected consulting and PM days. I have had fun with some salesgrunts that have assured me, since they know how to use M$ Project, they can scope the project accurately!

The second big issue I see with PMs is development. We have a few very experienced PMs that have the grey hairs from years of PM stress and usually specialise in one area, and we have junior PMs that are very green and cover anything, but very little in between. I often suggest we stick a junior on every project to shadow one of the experienced PMs but this is usually ignored due to cost concerns, so that when the juniors are trusted with a bigger or more complex project they usually have a very steep and stressful learning curve. I'd be interested if anyone has come across a better way of getting juniors more experience without upsetting the beancounters.

[Nimrod]

Planning

As Helmuth von Moltke the Elder said "no plan survives first contact with the enemy"

Planning is not a one off activity but a constant throughout the life of your project.

Oh and the FP is absolutely right the earlier we are aware of bad news the longer we have to deal with it.

[Cliff]

The 6 P's

Great advice I had in the past...

6P's - Proper Planning Prevents Piss-Poor Performance

Mythical phases - the business always needs to tinker with a project whilst you've got the development team committed to a particular architecture, any shifting ground will cost the project time and money, for which the PM gets it in the neck. Instead, agree with the business about how fabulous those suggestions are (soft skills), then suggest they belong in phase2 (or 3 or 4). The business feels listened to, and you don't have to spend time unpicking the bones of the system at a critical stage.

Plan your user test plans upfront in agreement with the business - if it passes those tests, it's accepted, so you don't get the project signoff held to ransom over some enhancements someone decides they want.

And the best one ever... "If you ever see the planners leaving a company - RUN!" - As the project office see both the budgets and schedules, they get first wind of trouble ahead. My ex-boss told me this the week before he quit, it turned out the MD was fraudulently massaging the books for a company sell-off, and ended up doing prison time. Luckily I'd also jumped before it hit the fan!

[Zolko]

50%

Nice article, very spot on. Unfortunately for me, I had recently ignored point #4 and over-estimated the political impact of a successful project.

But you also forget to mention that a project is about people, and a project manager spends 50% of it's time on human resources. Encourage people who work well, help those that have problems, sideline the trouble-makers, keep the directors at bay...

[thecakeis(not)alie]

Critical bit:

Freeze the bloody requirements before starting the project! If changes absolutely must be made, ensure that it is /known/ that change requests will cost money. Lots and lots of money. Every single change request will require a budget reassessment. I have nothing but contempt for people that approve project A but really want project Y. So you are signed on for (and budgeted for) A only to be “change requested” to Y. Y of course being 5 times the functionality of A and twenty times harder to implement.

[Mike Powers]

Icebergs

I kind of like that analogy--"a ship's captain constantly on the bridge on the lookout for icebergs and floating containers". The PM is one of those people in the position where a properly-done job is unnoticed; after all, nobody bothered to count how many icebergs the Titanic *didn't* hit.

[Anonymous Coward]

Agreed

In my book, the prime rule of project management is that "if it goes right, it's the team; if it fails, it's the PM".

[Ian Johnston]

Oh dear god no

Have we not all suffered enough from the myth that "management" is a transferable skill? Now here's another bunch coming along and saying they can run industries and projects better than people who actually know what needs to be done and what can be done.

The whole idea of contract project managers is the dead giveaway - like management consultants they'll come in, screw up an then bugger off leaving their victims to sort out the damage they've done.

Resist, comrades, resist.

[John Smith 19]

Excellant points but I think I can add a couple.

"Planning" is not an event, it's a *process*. Things change. Awkward managers suddenly discover this absolutely *vital* new requirement they simply can't live without and can mandate into the schedule, or some solid reliable developer type gets hit by a bus going for a sandwich and a replacement is foisted upon you with all the hallmarks of a PFY. These *should* trigger re-planning or at least impact analysis.

A book on the wars fought by the Israeli army up to 1984 (there have been quite a few) noted the flip side of "No plan survives contact with the enemy," which is "next time the survivors will know better."

On a personal note I never worked a project where *anyone* gave anything like a well argued time table or why. My gut feeling is that the only *real* way to get a feel for how "big" a project is going to be is to use a system which captures *all* the versions of evolving design documents *along* with code developed to them. to calibrate the PM's mental metre stick.

As I have never worked for Loral (formerly IBM Federal Systems) I have never seen such a system at work.

[ScepticMan]

Time, Cost and Quality

It's an oldie but a goodie but it still holds true. Pick any two out of three: Time, Cost and Quality

PMs understand Time and Cost but don't understand the details of what they are delivering. That should be the responsibility of the technical lead - who should be a peer of the PM at least. That avoids a conflict of interest.

The failed projects I have worked on all had a PM who thought he understood what was being delivered and made (or allowed) changes to the scope/requirements. These usually stuffed up the project because the consequences were not known and understood.

My advice is to always have a technical lead on the project, other than the PM, responsible for the product being delivered. The technical lead should report to the same person, people, committee as the PM.

Engineering projects usually have a chief engineer. ICT projects usually don’t have a technical lead.