Project Management Book

...chapter 3 continued

Each project is unique: it will require a unique, temporary project organisation. The roles will reflect both the project's needs and the skills and abilities of the people who will fill those roles.

A set of project management rules, if you have such a thing, will say which roles are mandatory (and the only mandatory roles are project sponsor and project manager) and would list the mandatory things each of these roles must do.

The project management guidelines would provide a fuller list of the sorts of things a sponsor and project manager might usually do. The guidelines would also list other possible project roles (project user manager, etc) with a suggested set of responsibilities. The roles and responsibilities that appear in these guidelines would be very much tailored to the sorts of projects your company does. The guidelines do not tell you how to organise your project, they provide a starting point, samples to help you work out what's appropriate for your project. You might decide that one person should take on the roles of project manager and project user manager - but if you do, that person in principle gets both lists of responsibilities to perform, not one or the other. You might want to invent a completely new role because of your project's unique needs. It's up to you if you're the project manager.

Never just assign titles. Saying: "will you be Project User Manager?" may convey nothing about the role to the listener. A good technique is to discuss with the person what you'd like them to do and then get them to write down their own role description (one side of A4 max) and replay it to you the next day. Then you know whether they've taken it on board or not. (Though you might not want to try this approach with the sponsor.)

One company had a template for their Project Definition Document. It helpfully listed their standard project roles - sponsor, senior customer, senior supplier, project manager, etc with a box beside each role for the name. And what happened? Project managers would write a name in each box and that was project roles taken care of. No thought about whether a role was needed or not, no discussion with the person concerned. Madness!

There will be disputes during the project. For example, if the users feel their legitimate requirements are being ignored by the project user manager they must have the right of appeal to the project manager and, if they're still not happy, to their member of the project steering committee. If they can't decide, the sponsor makes a decision (toss a coin if necessary). All escalations to the steering committee should be accompanied by a recommended resolution from the project manager. Escalation paths need to be clear at the outset.

It's a good idea to take a photo of every member of the project team and arrange them hierarchically on a wall (and/or intranet site) showing each person's title so that anyone can see at a glance who's who, who does what and who reports to whom. This can also engender a feeling of belonging, even pride in being part of the project team.

Very small projects, very large projects

In the smallest project there are two people on the project organisation chart: the sponsor and the person who will manage and do all the work.

Slightly bigger, and we have a sponsor, a project manager (who won't spend all his time project managing) and below him a team of two or three people.

Up again, and we have something approaching our example organisation chart but, say, with one person acting both as project manager and project user manager, no IT project manager and an IT team leader managing the IT activities.

Up again and we have something akin to our chart, with one or more team leaders, which might imply a total team size of twenty or so.

Up again and under the project manager we might have a project IT manager, project user manager, quality manager, test manager, architecture manager, procurement manager and others, all reporting to the project manager.

Then we get into projects that are really collections of projects. So the head man might be called project director and under him a project manager for the (sub) project to develop the new order handling system, a project manager for the (sub) project to develop the new invoicing system, a project manager for the hardware (sub) project, etc. And some of the (sub) projects might be in-house, some outsourced and some may be hybrids with both in-house (say users) and outsourced (say IT) elements - and a well staffed project office doing their best to make sure everything is well organised. Quite a big task for the project director to sort that all out before the project/programme begins.

Clearly, you can't just lift a universal organisation chart and set of roles from a book of standards and adopt it as is.

So:

• design a project organisation that matches your project's needs
• ensure everyone from sponsor on down has a clearly defined role with no gaps or overlaps
• talk to each person, agree their responsibilities, get them to write it down and check back with you
• get line managers to commit resources and agree to take your input into those people's appraisals
• never just assign titles!

How to spot a good project

Ask the sponsor who is in charge. Without hesitation he will say he is. If it all goes wrong his job is on the line; he is the ultimate can carrier.

Ask the same question of the project manager and he will say the buck stops with him - the sponsor is just a figurehead.

If the project manager is a business person, the project IT manager will scoff and say that actually he, the project IT manager, is really running the project - what does the PM know about IT anyway?

Speak to the project user manager and he will tell you he is the lynchpin, the person whose work and decisions will do more than anyone else's to make the project a success (or failure): if the requirements are wrong we're all wasting our time!

The team leaders will tell you that actually they are running the project - doing all the detailed planning and tracking and getting the team members to do the work. (And by the way they probably are running the project.)

And what will the team members say? "We've no idea what all those people up there are doing - we're the only ones doing any real work, project success is obviously all down to us."

That is a very good sign. Everyone felt they were it, they were responsible, success depended upon them.

Contrast that with the opposite. Ask anyone who is responsible and they will say "not me!" and point to someone else and say "it's him". That's a worrying sign.

Whose job is it to make everyone feel responsible and accountable for project success? You've guessed it, our friend the project manager.

Privacy Policy and Cookies