Changing project manager – who, how, what?

“Karl, you have to take over the project, otherwise it’s doomed!” This is difficult for Karl. He can’t really say no, because the order is coming from his boss. But perhaps he doesn’t want to say yes. What should he do? And what would you do in Karl’s situation? What should you concentrate on when taking over a project, how can you make a sensible decision and lead the project to success?

The reason for changing project manager

To take over a project that has already begun is a challenge – for the new project manager, for the project team and also for management. If a project is threatening to break down, then mistakes have been made, situations have been falsely judged, and abilities and approaches have been over or underestimated. Who made which mistakes in which situations is often difficult to judge. When changing project manager, it is important to understand why it is necessary. Are they personal reasons, like the current project manager falling ill? Is it because of the project manager’s availability – do they have more projects that they are managing at the same time? Is the behaviour of the project manager not always exemplary and upsetting communication with the team? Or is it a matter of performance, because of the knowledge, skills and experience of the project manager? When it is because of personal reasons like illness or unavailability of the project manager, then it is relatively easy to organize a change, because the current and future project leaders are following the same goal. It’s just passing the baton. But if the reason is the performance or the behaviour of the project leader, then the motif could vary. “Do your stuff on your own!” “Find your own information!” or “If you can do it better, then surely you don’t need my help”. Expressions like this have presumably happened more than once in comparable situations. Clear communication between management and the incumbent project manager about the reasons for the project manager change and the expectations of the project takeover is then here all the more important. Unfortunately this seems a lot easier in theory than it is in reality. If replacing the project manager is a total surprise and without warning, then the business management didn’t communicate ideally. In addition they also take a risk in that if the project continues to fail despite the change, they are more responsible than they were originally. Nonetheless, they will take the risk to save the project if the opportunity arises.

Changing the project leader

Changing project manager – an option to save a project?

General project information and the status quo

How is the project going? Before you decide to take over, you have to know what you’re getting involved with. What expectations are bound to the project? When is the project successful? Which expectations connect management with the project leader? What does the project leader expect from the team and what does the team expect from them? And what expectations do stakeholders have? The better such questions can be answered before you decide whether or not to take on the project, the more sound it turns out.

If the management wants to change as little as possible and at the same time wants everything to go better, this expectation is already a part of the problem. Even when time constraints, impatience and restlessness prevail, it is important to know what it’s all about, which goals are being pursued and what the problems are. It is also important to differentiate between the plan and the actuality. Original project goals can be moved, business cases changed. Examining missed milestones is only meaningful if you can recognize a reason for the discrepancies. If there were late deliveries did you change the requirements, or were some employees sick? Maybe you will find aspects that have proved important during the project that weren’t initially planned for, so that delays are unavoidable.

These are the important questions:

  • Which stakeholders were identified and what goals do they have? How is the stakeholder communication going and have all stakeholders actually been identified?
  • What is the project goal and the business case? Which adaptations were there during the project?
  • How does the appointment calendar look, what discrepancies are there and why?
  • How do the resource plan and the current resource availability look?
  • What is the state of the requirements? What has already been done, what has to be done and what requirements are there?
  • How is the project organized? How will it be processed, with which tools and methods? And how satisfied are the participants?
  • How is the project communication being done internally? With the team, with the specialist departments, with the business management, the committee or the project management office? And are external partner being communicated with?
  • What is the state of the documentation? How is it being documented internally and externally? Which burdens of proof have to be upheld?
  • How are the planned and the current expenses? How is it looking with the costs?
  • Which risks are there and which measures are being taken to minimize and avoid them? Have risks already been taken?
  • And: how important is the project – for the business management, the business, the customers and the employees?

Incidentally, the phase that the project finds itself in is not decisive for the project manager change. It is easier if it happens earlier, whether the project is being prepared, defined or realized, being closed or operated – it is always decisive if the future investment in the plan is worth it, not just the time that has already been devoted to the project. Even if multiple person-years have been spent, just ask yourself if the future investment is worth it. The answer can also lead to a project cancellation – an option that should always be in the sights of the business management.

Personal analysis

The communicated and possibly documented status quo and the actual status quo can be different. The team, individual team members or the business management can have their own impressions. It is definitely not a disadvantage to know these. That is why the inventory is imperative. And an evaluation of the achievability of the project. If you take over a project although you don’t believe it can be realized as planned, that prerequisites are lacking and that framework conditions are not correct – you are not doing yourself any favors.

Do you know the feeling when lots of information is available but the origin of the problems doesn’t really become clear? The information about the plans and the status quo, about the qualitative and time-bound challenges are very important – but where do the problems lie? Call them quiet problems. Not every problem has to be a chance. Just list all the existing problems and weigh them up. With the management, the team and with the existing project leader. And then, together with all the participants, consider what would happen if this problem was not solved. Clearness has to prevail here. And the management has to know that it is probably not enough to just change the project leader.

For the personal analysis and your decision it should be irrelevant if you are an employee of the company or an external advisor. It is not always easy for employees to say their opinions openly and the joke, “Do you know what an exchange of views? When you go to the boss with your view and come back with theirs,” is unfortunately not just funny. So if you can’t say your opinion or are not allowed to, you probably shouldn’t take over the project – neither as an employee nor as an external advisor.

The first step after the project manager change

You have decided to take over the project. You organize new goals with the management or confirm existing ones. You try to formulate demands to the management (for example, more employees, more time, more organizational competencies) and define measures for the project’s success. You make an arrangement of the project takeover – internally and, if necessary, externally, by naming the reasons. And then? Should the project keep going as before? In politics, new office holders have a 100 day deadline to get to know the ropes and the show their first success. Agree on a changeover phase (of course, fitting in with the project) and communicate the “unadorned status”. The transfer phase is a type of insurance for you. The initially communicated project information and your personal analysis are always estimations from the outside, but only when you have experienced the project from the inside can you really judge. That way the recovered findings from the transfer period can be the foundation for your further project work and offer you the possibility to eliminate causes of the difficulties in the project and design the project successfully.

Summary

To take over a running project is not an easy task. If you are busy with a project takeover, it is important to reach a sound estimation of the status quo and the achievability of the project. If you miss an opportunity for an analysis at this point, you will not get it again later. At the same time you want to avoid unnecessary expenses, innumerable meetings, workshops and long interviews. You are in a dilemma – the project is threatening to fail and you have to keep quiet to make a good decision. Don’t let yourself be infected by agitation in the project environment. The offer from the business management to take over a project is a compliment, because the management trust you to save the project. Nevertheless, this is not a reason to decide in passing to take over the project, it is fundamental to speak about the problems of the project, to define appropriate priorities. The transfer phase additionally gives you the possibility to gain further insights and, as an insider, to better set the path to project success.

Of course, changing project leaders is no guarantee of the success of a project. What experience do you have in similar situations? And what advice would you give Karl?

My name is Michael Schenkel – and I believe in tools, if they are useful. Tools that support users in their work, tools that provide a common working environment for all types of roles in a project.

0 replies

This discussion is missing your voice.

Leave a Reply

Your email address will not be published. Required fields are marked *