How to start managing an in-flight project?

Question

I have intermediate project management knowledge. I became a project manager for 2 software deployment projects for a company.

One of the projects is towards the end as we get close to deployment and in the other we are in the preparation of the testing phase.

I feel totally lost not knowing where to start and what to do. For example, some of the issues I face now is that everyone from infrastructure team and security team are saying "this is not my job" and I'm not sure how to manage that. Do I have to prepare and explain things for them in detail or shall I invite one member of their teams to join meetings with the vendor?

I don't have good security and infrastructure experience.

Is there a certain procedure I can follow to successfully deploy both systems?

Answer 1

The first thing you need to look at on an in-flight project is how is the project performing against its baseline, metrics, and customer's perception. If things are healthy, then join the team and consume as much information as you can. Let the team do what they are doing because they must be performing at least reasonably. And then slowly build team trust and take over leadership.

If things are in the toilet, then you must take control and do, and have the team do, the work that you think is necessary to perform. If someone on a struggling project tells you, "it's not my job," make it crystal clear that with that attitude none of the tasks will be "your job."

Most PMs with whom I have worked, and myself included, are not "experts" on all areas of the projects. You need to get past that. If you're not trust those experts or picking up the sense they're manipulating you, then replace them with someone you trust.

Answer 2

The first thing you need to do when taking over a project in-flight is to sit down with the team(s) or the individuals "in charge" and create a list.

You may get a lot of pushback - "it's a waste of my time" - but you won't get anywhere without this, as you've discovered, even if you inherit something similar.

This list includes all deliverables, their current status, the Action Items needed to finish & deliver, their expected delivery date as well as an owner.

Make sure to get the approval of the owner that they are responsible for this (sub-)item, either during the meeting or afterwards. You may have to have some follow-up meetings, but you cannot proceed without clear owners who agree.

You do not need to know the details, though it helps to have a basic understanding about the concepts, so that you don't say silly things - and that others don't BS you.

Now you should have enough information to create a tracking sheet, and to know who belongs to which task.

All that's left (so to speak) is regular Project Management.

Answer 3

Since these projects are in their final stages, you might need to hit the ground running and handle things with Agility:

1. Find out where you are
2. Take a small step towards your goal (and if there are multiple choices here, take the path of least regret, or the one that makes future change easier)
3. Adjust your understanding based on what you learned
4. Repeat

You obviously need to learn as much as you can about these projects because you need good understanding in order to make good decisions. But you also need to keep things moving while you learn these things. So you will have to rely on the teams to do their jobs.

From what you are describing, it seems things have worked out on both project somehow, but now they are stuck. So the priority seems to be this: getting them unstuck.

Personally, if I would be in this situation, I would start by gathering everyone together and then ask what is needed to get things going. Use these discussions to create a Responsibility assignment matrix and assign some dates to each task. Then follow-up on these tasks and help people to remove any impediments that might prevent the task from being achieved.

As mentioned in David Espina's answer you need to trust these people to do their jobs while you get up to speed and figure things out, and it would also help if there is some sort of a project charter for each of these projects, to give you the necessary authority to manage things while you lack some of the projects knowledge others already take for granted.

Answer 4

In short:

1. Make sure you understand the responsibilities of your team members (you emphasises that - then it has to be the first thing to do)
2. Get a confidence in that your team members are fulfilling their responsibilities
3. Gather the info about the opposite side of the project (e.g. vendor/customer's team, or them both)
4. First time - homework and preparation to the ongoing topics and issues (if you know the main problems that folks are working on at least at the high level, it gives you self confidence points;).

Each point in details:

• Reserve the time now to understand what your team members do and what they are supposed to do: who is responsible for each component of the project. Ask for a kick-off one more time the previous project manager/ longest-on-the-project person/ technical lead. solution architect/ most loyal colleague/ analysts (they'll explain the business, it's also good, as it can give an intro to the understanding of the current technical questions and issues).

• Compare your expectations within their current toDos and expected responsibilities.

• Gather the information about customer's/ vendor's team - who is responsible for what and the subordination relations 'boss - subordinate' (this can help you with timelines later, if communication with a direct person doesn't help, you'll be talking with the decision-maker directly).

  • Before going to meeting alone as a PM, first time you need to have something from your team to support you. Nevertheless: prep
  • are yourself to the meeting agenda and questions; arrange a test run of a meeting with loyal follks (for me it was helpful, when we had to prepare several proposals on the same topic - each of different complexity, which has to be explained in details to the customer).