Q:

Dear Ammar,

I was assigned as a project manager on a project that is half way through.  I was given two weeks to receive hand over from the previous project manager.  I am relatively new to the company and not familiar with the project at all.  What do you advise me to do?

KQ.

A:

Dear K,

Taking on a project in progress is tricky business, so your concerns are understandable, especially that you are new to the organization.  Depending on how they are managed, projects in progress can be black boxes with failure lurking within, so to speak.  The problem is that, on poorly managed projects,  failure is never evident until the project is very close to its target completion date.  There are many reasons for this high level of uncertainty associated with projects in progress.  Putting aside justifiable uncertainties that come from the inherent nature of a risky project, poor project management complicates issues and adds tremendously to the project risk.  Using project management, the project team should be able to apply planning techniques to reduce uncertainty early in the project by proactively addressing projects’ risks and rigorously planning project work.  However, if a project manager is under external pressures or lacks knowledge or experience, she might not give enough time or attention to proper project planning.  Then, the project becomes like a can of worms, waiting to be opened. 

Most seasoned project managers hate taking over undergoing projects.  However, it is inevitable that one day, a project manager is obliged to take on someone else’s project, as in your case.

For starters, I urge you to put on your skepticism hat as you are handed over the project.  Next, find out how much hand over time are you allowed, and will the previous project manager be there throughout the handover.  Plan the handover carefully and prepare to do lots of information gathering by reading project documents and listening to project stakeholders. 

On your reading list, make sure you have the project contract, charter, specifications, and plan.    Make sure to request all previous versions of the project baseline, not only the current project plan.  Remember that the plan is not only a schedule.  It should include scope definition, quality plan, communication plan, as well as the project schedule.  Also request the risk and issues logs. 

If the project manager indicates that the above information does not exist then this is a cause for alarm.  A project without a baseline is a project that does not have a reference point.  Without it, there is no objective way to determine whether the project is meeting its time, cost, quality, and scope related targets and any judgment on the health of the project becomes a subjective judgment call that could be misleading. If the plan or baseline does not exist, then raise the issue with management and insist on them giving you time to re-plan the remainder of the project as soon as possible. 

Assuming that the project actually has a plan and a baseline, your next step should be to ask for all previous progress reports, change requests, and project correspondence.  As part of your review, verify that all change requests are reflected in the project baseline.  During the documentation review,  work with stakeholders to ensure that the plan reflects their current expectations about the project. 

Now its time for “scope verification.”  For everything shown as complete or in progress in the previous plan, verify yourself the level of completeness. Is it really complete? Is it really 99% complete? How was completeness determined? Was it complete to the right quality standards? If you see something missing or not going right, this is not the time to be discrete or tolerant.  If you take it as is, it becomes your problem.  If there are documents missing, or parts of the work were not done properly, then bring it up.  Remember: once you accept the project, then it is yours.  Any problem you do not bring up will become your problem and your responsibility. 

In addition to documentation reviews, get introduced to the project stakeholders as soon as possible.  Ask them to help you in the hand over efforts and to help you better understand the project.  Tell them how they can reach you and make your self available to them if they wanted to chat with you formally or informally. 

Personally interview key stakeholders of the project.  Ask them for their feelings on the project progress, any concerns they have, their assessment of project status, and ask for their advice on making the project a success.  On your list of people to interview, make sure you meet the client representative, sponsor, team leaders, and key suppliers, in addition to the previous project manager.  During the interviews, watch for the words as well as the body language and tone of the key stakeholders. For example, are they speaking freely or seem to be censoring their statements? Do they change their tone and their statements to appease you or other attendants at the interview? These can be signs of closed communication environment preventing stakeholders from speaking their mind.  This can be very dangerous. 

After meeting everyone and reading the documents, you will have a gut feeling about the project.  If it does not feel right to you, then trust your instinct; something must be wrong with that project.  Organize your thoughts and feelings about the project, along with your findings and recommendations and head to the project sponsor’s office. 

Some people feel that refusing to do a project is not an option.  I disagree.  If you review a project and it looks like a disaster waiting to happen, then your responsibility is to report your findings truthfully and assertively to management, and formulate a plan that will put the project back on track.    If management is cooperative and buys into your plan then fine.  But if you feel your attempts at identifying the problems and resolving them are shunned by management, then you have a choice to say no.  Remember: if they want you to manage the project, then they should give you the room to lead the project to success.  I have seen many project managers refuse to take on a project because the project was already a wreck or because management is not committed to its success.  Some have been fired, but most have not. Either way, none of them, as far as I know, regretted standing up for what they believed was right.  However, all those who have taken on a project against their better judgment, including myself, have come back and regretted it.

One last point to remember: do not try to be a hero.  If the project is hopeless, do not assume you will be the savior who will magically turn it around.  There is no magic in project management.  There is common sense. 

Good luck

Ammar