Golden Rules

There are a number of Golden Rules which I cannot overemphasise. They all relate to the 'cracks in the pavement', rather than to the more obvious bread and butter issues.

i) Software does not make you a project manager

You will probably find it helpful to purchase and use a project management software package, e.g. Microsoft Project. However, ownership of such a package does not make you a Project Manager. It is too easy to become dependent on the powerful facilities such packages offer and to miss more important issues, for example that two members of your team never seem to agree about anything, or that the project objectives are suddenly becoming unattainable.

ii) Project Management is too important to be left to the project manager

It is vital to instil in the project team the awareness that they are all responsible, not for just their own patch of work, but for the well being of the project as a whole. If they come across information which they believe will impact upon other parties' work in the project, they should bring it to the notice of the team - by communicating first with the Project Manager.

iii) Communicate communicate communicate

This point flows from the previous. All too often team members assume that Fred will have noticed that x is now y; they work on the basis that y is the case; Fred is still working to x. The result: lost time and additional expenditure to correct the mistake. I suspect that the majority of projects have large parcels of work that needed to be carried out more than once, for this very reason.

iv) Be conscious of your own bias

Problems commonly arise from communication problems between teams with different skill bases and hence different cultures. If the Project Manager has a background in one of these areas (e.g. in software development) there is a danger that he will conceive of the project in software-led terms. More dangerous, he may be more sympathetic in arbitrating between software developers and other parties since he may empathise more closely with the pressures the software team is under. It is imperative that the Project Manager offers complete objectivity and can respond with equal sympathy to requests etc. from any party.

v) Be very wary when dealing with innovation

As the amount of innovation in any project increases, so the risk increases exponentially. If project A has innovation a incorporated, and Project B has innovation b, do not assume that if Project C has both innovations a and b that the risk of project C will equal the risk of Project A + risk of Project B. It is likely to be 2 or 3 times that. Particularly in multimedia, expect and prepare for problems.

http://ibis.nott.ac.uk/guidelines/ch8/chap8.html