Project Manager's Survival Kit

Managing a project is no less challenging than fighting a war, be it a multi-million dollar project, involving over a hundred team members and spanning multiple geographical locations OR a small project with less than 20 team members occupying no more than a corner of your office space!

Regardless of the size, every project needs to be handled with an equal precision and needs the same set of skills to be applied by a Project Manager. Experience has shown that the amount of challenges faced by a project manager during a project do not come down just because a project is smaller in size. For smaller projects, even if the number of stakeholders and thereby the quantum of requirements may not be as large as bigger projects, the quantum of changes happening to the original requirements may be more, thereby having a potential to disrupt the project schedule and budget.

In short, no matter what the project size is, every Project Manager needs a survival toolkit. Here are some of the tools that are key to the survival of a Project Manager in a crisis situation.

Project Scope Document

Knowing the project boundaries is vital for a project's success. Both, inclusions and exclusions to the scope of the project have to be crisp and clear right from day one. Having a scope statement signed off early in the project life-cycle safeguards the Project Manager from the hassles of having to justify the scope creep later in the project.

Typically, the Project Sponsor signs-off the Project Scope Statement, which can also be considered as an approval from all the stakeholders. Having said that, the Project Manager must still get a buy-in from the customer on the final project scope before any development on the project commences and before it is signed off by the Project Sponsor. 

It's a fact that no matter how much you detail out the project scope, customer will never stop adding to the scope/modifying the scope till the end of the project. There's no project out there that has 100% scope defined and frozen at the beginning of the project. The additions/modifications to the scope that come during the project execution are known as Change Requests and are typically managed using the processes defined in the Monitoring and Controlling process group.

The project scope document acts as a base document that helps a Project Manager to identify the changes to the original scope and thereby qualify them as Change Requests.

Project Schedule

Project Schedule tells the stakeholders what to expect when, during the project life-cycle. It helps the Project Manager and the project team to align the resources as per the delivery schedule. Project Schedule should be detailed out to the final deliverable level.

Experience tells us that a project invariably has a tendency to deviate from the original schedule. Hence it becomes all the more important for a Project Manager to track the schedule closely and include all the deviations to the original schedule. To be able to identify the correct amount of deviation, the schedule needs to be "baselined" first.

Tracking the project schedule helps the Project Manager check the slippages in the timelines quite early in the project life-cycle. It also helps the Project Manager plan dependency resolution so as to avoid delays on the critical path. Whereas, not tracking the schedule regularly may result in the project going out of control.

Project Risk Register

A Project Manager who thinks his project does not involve any risk, is headed towards a disaster!

Every project, big or small, has at least some amount of risk involved in it. For instance, non receipt of timely customer approvals on certain deliverable on closure of a stage/phase, before moving on to the next stage/phase of the project.

Risk Register is maintained to list down all such type of risks, right from day one, and also to identify it's overall impact on the project. It has to be regularly reviewed by the Project Manager to update the risks that were identified earlier, if there has been a change in the status or strategy to handle those risks, and add new risks that are identified along the way. This will help the Project Manager to plan the strategy of handling the risk in advance, without affecting or delaying the project.

Project Stakeholder Register

Every stakeholder in a project is important, though the level of importance may vary. The level of importance depends upon the influence that the stakeholder can have on the final project outcome.

It is important for a Project Manager to remember, that even a single dissatisfied stakeholder can alter the outcome of the project! Hence it becomes all the more important for a Project Manager to understand every stakeholder's requirement properly and map the deliverable accordingly.

Stakeholder Register is a list of Stakeholders with their level of importance, the level of influence they can have on the project and the type and mode of communication that the Project Manager needs to have with the Stakeholder. The list may get updated as the existing stakeholders get replaced with new ones OR when additional stakeholders get involved with the project.

This document helps the Project Manager avoid running into a situation where he has to absorb a requirement from an Stakeholder, who was not identified earlier and thereby allow a scope creep and delay.

Communication Matrix

Communicating is THE most important activity performed by the Project Manager throughout the project! A successful Project Manager always focuses his energies on effectively communicating between the stakeholders and the project team.

Communication Matrix is one such document that clearly defines how the communication will happen with all the stakeholders and project team members. It also ensures that the flow of information is seamless within the project circle.

It has been observed that many a times the reason for expectations mismatch is incomplete or wrong information being communicated to the stakeholders. It also causes a lot of re-work, scope and/or budget creep and lower satisfaction levels amongst the key stakeholders.

Getting the matrix right on day one, helps the Project Manager in ensuring the information flows to the right people, through a right channel and avoid escalation of tensions later in the project.

Change Log

"Change is the only constant!"

Same applies to a project too. The requirements that form the base of the project execution, are never constant, and keep on evolving as the project matures. In short, requirements can and do change during the project execution.

Project Manager should always be better prepared for these changes, failing which can have adverse effects on the project.

Changes can come due to various reasons and can initiate from any stakeholder. Change Request Log is a document that logs all the changes that come to the Project Manager, with a reference to the original requirement. The log not only maintains the change request, but also the reason for the change, the originator of the change and the date when the request was initiated.

This document is the saving grace for the Project Manager in situations when the evolution of a particular set of requirements have to be traced back. This is especially helpful when stakeholders change or get added to the project.

Similarly, there are a lot of other documents that aid the project manager during various stages of the project. But the ones listed above are the tools that make up the Survival kit for a Project Manager during the challenging times in a project. They keep the Project Manager on his toes and ensure that the project never goes down the hill.

I would love to hear your opinions on this article and all your suggestions/arguments are welcome.