It started with a scenario. It is Day 1 of a project and you turn up as the newly appointed project manager (PM). What do you do? This is a bit of a trick question. ‘Day 1’ suggests the first day on a Gantt chart depicting the activities needed to execute the project. But of course this can only happen when lots of other things have happened first.
The scope of the project will have had to be defined. Perhaps contracts will have to be negotiated. Contract negotiation needs some requirements to have been developed. If work is going to be done in-house then resources - most importantly staff - will need to be identified. The list goes on.
Perhaps the PM is in place right at the start of this preparatory work, or it could be that they are parachuted in at some point some way along the start-up process. The thing is that the PMs are often thrown into environments in which they are, to a greater or less extent, strangers.
Success as a PM can often be measured by the speed with which they can become fully immersed in the particular circumstances of a project and its context, and also the extent they remain sensitive to what is going on as the project is progressed.
Initially this is a matter of doing your homework. You will need to read the existing contracts and requirements carefully. You will need to talk to the people who are already immersed in the project, especially about the real motivations for the project. Having a competent and supportive project sponsor is a massive advantage to the PM.
All this should contribute to a sensitivity and awareness which can be carried through to planning. For example, these may identify stress points in the project whose impacts need to be softened. Thus critical implementation milestones should not be planned for when there are existing critical operational episodes, such as the launch of a new product. When new IT functionality is introduced staff need time to become fully effective in its use.
PMs with well-developed awareness and sensitivity are probably more prepared to deal with unplanned events, partly as they are able to anticipate the likelihood of some changes, such as staff changes.
While these qualities are undoubtedly desirable in a PM, Project Eye wonders whether this could be a lot to ask of one person. Project Eye is not usually an advocate of bureaucracy, but, for example, a formalised and rigorous change control can ensure that added requirements or the modification of requirements that have already been implemented are only accepted when the extra resources and time they need have been agreed. If the system works well then this can take a lot of pressure off the PM.
It may be the more formal aspects of the management of projects are covered in the BCS publication that Jeff has written with Chris Dale, ‘Managing IT Projects For Business Change’ Jeff’s talk suggests this might be worth looking at.
