Beyond the alphabet soup of PRINCE2, MSP, PMBOK, ITIL, Agile
One of the key challenges faced by a Project Manager is to ensure their project is not beholden to an individual for its success or failure. This is especially the case longer the project is in motion. This challenge is faced by the project teams more often than it is acknowledged.
Consider what happens if one of the key staff want to take a vacation, they fall ill or has a family issue, decide to leave altogether or the Project Manager wants to take some time off?
Project Managers are inherently risk averse. There is a tendency to utilize people they have previously worked with and to try and maximize their productivity. It is also against project management ethos to spend time doing this that does not progress your project forward and lead to ticking off a specified outcome. This caution is well served, until the first sign of resource shuffle.
How does the Project Manager prevent a calamitous turn of events? One of the Agile software development methodologies has a very interesting approach. Extreme Programming (XP) insists two developers work together to deliver tasks assigned to them. XP claims improved quality delivery and resulting lesser cost of lifetime delivery as the reasons for the approach. However, this also immediately lessens the reliance on one particular developer. As well as efficiency gains, the approach immediately provides a level of knowledge sharing.
When assimilating a new member in the project team, one of the key challenges challenges is to get the same productivity from the new member as was the case with someone that had been an integral part of the project. This difficulty is usually in the form of knowledge the previous team member had picked up that is not documented anywhere. Even if the new resource is equally as competent as the one they are replacing, they still may not know the approaches that had already been tried and discarded. The only way to ensure the new resource does not waste time by trying the discarded approaches is to have good documentation of tasks assigned and progress on those.
You reap what you sow. If you plan for and encourage a wider team participation in your project, you will be in less risk of getting stuck when something unforeseen happens with your resources. In many cases, the additional effort required is a difficult argument to make. I find it is easiest to get my message across by quantifying the impact in terms of schedule delay or cost to project.
Senior Project Manager at Eagle Technology, APMG Accredited ITIL, MSP + PRINCE2 Practitioner, governance expert, cricket fanatic, squash pretender. Opinions expressed are purely from my experience of leading teams and running projects, and in no way claims to represent those of my employers or customers.
Pingback: How do I communicate project schedule? « Project Management in Practice