We learned a lot about scheduling and task delegation this week and one major question arose. If the PM changes at different phases of a project (beginning, mid, near conclusion), and the an error in the scope is identified in the mid-phase, what do you suggest doing? More specifically, because the tasks delegated are based on the understanding of the scope and what needs to be accomplished for a project to be completed, if an unaccounted for task is needed to be added to the hierarchy of tasks and then to the schedule, how do you suggest a PM go about managing the existing staff to accomplish this? Do they get more staff, outsource, or just move the schedule around reducing the room for errors increasing risk of failure in the event of delays?
(Assuming that the current staff have the skill sets needed)
If its the beginning, should the whole project genesis procedure be repeated by the new PM but using the information collected by the previous PM?
This is a great question but I think it needs to be specified why the change in PM occurred. If it was due to that person leaving your company to take another job or personal reasons... etc. I believe the new PM should more or less ensure tasks are completed in the manner they were originally prescribed. However, this person will also be bringing a new perspective to the problem and might be able to make certain changes that can improve the project's efficiency without making major changes to the scheduled tasks.
It sounds like your question may have been referring more to a scenario where there are major flaws appearing in a project causing the old PM to be fired or removed from the project. In this case, I believe it would be up to the new PM to decide if there are only portions of the current plan that will need adjustment or if the plan should be entirely redone. As you mentioned a factor that must be taken into consideration is how far into the project you are already along with how much of the project that's been completed so far is actually useable. In either way, major changes should be expected and the failures experienced thus far likely caused some setbacks. The deadlines and expected timelines for each phase of the project would definitely need to be re-evaluated.
I have experienced this quiet a few times as I work closely with PM’s. So anytime there is a change in a PM, due to any reason either the PM leaving or a senior PM taking over the project, there is always a kick off meeting to go over the project scope and the completed tasks as well as the uncompleted tasks. Anyone who plays a role in the project is part of this kick of meeting so all aspects and tasks of the project can be addressed. A new game plan (project scope) is created in this kick off meeting. From this kick off meeting the new PM learns if new resources are needed for any tasks that were newly discovered or if they can delegate people to specific tasks.
I had experienced a change in PM once in my career, and the resulting events were similar to what jlw23 had mentioned. We had a get up to speed meeting with the new PM, which I attended with my team lead. In this meeting, all team leads discussed the current status of their tasks. The new PM was quickly filled in on how the project is progressing, and all members talked about whether current aspects of the project should be changed based on observations, such as getting more resources for certain tasks or changing something up. Once all details were out, a new blueprint was created for the project based on the issues and observations the team leads mentioned, as well as what the new PM deemed should be done. In the end the meeting was a “get up to speed and optimize” meeting for the new PM.
This actually occurred in my team a few months ago. The previous PM got a new job with another J&J branch and one of the principle R&D engineers got promoted to becoming PM. So in our case, it wasn't a huge shift in that the new PM was someone who was already on the team for several years so they did not have to get up-to-speed with where the team and projects were at. The only updating that really occurred is that now we were just reporting to another person on the team. The new PM however had a huge shift in responsibilities and had to get respective training for the position. Overall, the timelines for all of our projects are still on track and there are slight differences in management styles between the old PM and the new PM but they are positive changes. So this question really depends on the situation - if we were to get a PM from outside the team, I'm sure things would have turned out a lot more different and there would have been delays in our projects.
This question reminds me of a saying that I believe is very true to the project manager position. It is called the 6Ps, “Proper Planning Prevents Pretty Poor Performance”. If the PM correctly planned the project, it should allow buffer room for errors and new regulations being involved. With everyone’s access to media it is clear to see how dynamic the medical field is and how badly it can alter a project. When setting a due date or expected date of conclusion a PM should schedule in empty time that is for issues like this. It is not a bad idea to bring in a defined term employee to complete the supplementary project, but staffing is not as easy as many believe. The process of going through resumes, interviews, and training can add more time then just having the current staff complete the project. Also there is the risk that you hire an employee that turns out simply to be a poor employee. Their failure can drastically affect that team’s ability to complete the project. I think extending deadlines might be a more successful approach then increasing staff size.
If an error in the scope is identified at mid-stage I would suggest that the initial scope and planning phase be looked at. From there we can analyze what changes will need to be made and then we can follow those changes up the line and see what effects it will have on other tasks and project groups. After accounting for all the necessary changes we will look and see what is the latest point in the project we can start over from, so that way we will not have to waste time repeating unnecessary steps and tasks. When a change like this happens there will have to be changes to the staff to accommodate for extra work. I suggest that the company will keep the work internal unless the change is so severe that we need to bring in a team of 3-4 people to carry out work that will take a couple months to complete. In order to save money though for the company it may be cheaper to pay a couple workers internally a couple hours overtime a week and push the project back a week or two if necessary. If we bring on more people then it is just more people that have to managed and paid and it can cause confusion for other areas of the project. As these outsourced workers are new they will have to get adjusted to the project and scope, which can take come time and increase the risk of problem. If this occurs at the beginning I would say that the whole project genesis procedure be started over. It is important to take time in planning and make sure everything is outlined and to not rush through. If you try to just pick up where you left off and try to go back and make changes you may miss important areas of tasks that need changes and then these can cause complications later on in the project.
Hopefully the project does not have to start over (maybe the reason why the PM had to leave), in which case the new PM would start from the beginning like every other time - as long as they know the content. If the PM shifted during the middle of the project, I would agree with the "kick off" meeting that was previously mentioned by a few. I think this would be the best way to get to the new PM up to speed. I also think it would be beneficial if the old PM would "show [me] the ropes". Hopefully the old PM is amicable about leaving and willing to share information and strategies that will help the new PM.
If the PM is changing near the end of the project, I actually think it would be good for the person to stay on for as long as they can (except when fired). If leaving on their own terms, I think there is still some level of responsibility that the PM has to take to ensure the completion of the project. Whether that be work side by side with the new PM, or prevent the change until after the project.
I also think its important to identify what the new PM considers the error in the Scope to be. I agree with the above posts, but I think if the key Stakeholders had signed off on the scope of the project-they would need to be included and determine if there indeed is an error with originally laid out scope and if they want to use the resources to address this error in scope. I think on the business side this comes down to time and money and the idea of risk vs reward. Is it worth changing the scope or will that require more resources and time that were not originally contemplated. I think if key Stakeholders are ok with changing this error in the scope, they would most likely choose to the cheapest option which would be to not hire more staff or contract out, because that would be costly.
I agree with most of the posts above. however, at the end of the day, the company sign agreement and must be responsible to deliver on time. Customers don't care what happens internally, They care about the results at the end from my experience. The last couple weeks, we have been studying different methods and documents that help to manage the project. It is very important to keep these docs up to date. Also, It is part of risk management. when there is a transition of project form one PM to another person. It doesn't happen overnight and most likely there is a transition period when the transfer the task and other people take ownership so that the project doesn't full apart. As well as management always planing for people backups just in case anything happens. It's also management responsibility to help to solve such problems
I have also experienced this in the industry in one of the projects I have been a part of. There was a change in PM due to resource constraints. We had a kick off meeting to introduce the new project manager with the existing manager present. Within the following weeks, both managers were in the program meetings and were working together offline to prepare the new PM for the transition. This involved extensive conversations around budgeting and scheduling, as well as anticipated tasks for where the project was in its lifecycle. I noticed that it took the project team (quality, R&D, operations, commercial, medical, and regulatory) a few weeks after that to function as a team once again adjusting to the new management style. I found a brief blog post that lists 6 of the biggest factors that need to be considered during project management changes. I am having issues uploaded the link. The blog post is from Tech Republic: 6 tips for a successful project transition.
If a problem in the planning is identified mid-scope it should be reassessed with the entire team present, taking into account resources and timing. Pushing forward with flaws in the scope can cause bigger issues down the line. Using a Gantt chart or a similar planning mechanism, the critical path can be identified and certain tasks can be chosen to be run in parallel in order to adjust time frames to account for changes that are necessary. Project managers have different managing styles and them making the adjustments they see fit and tweaking the scope could turn out to be advantageous. There may be certain unnecessary or wrongly planned stages that need some revamping. However, I think it is important for the whole team to take part in this decision making discussion and process to keep everyone on board and cohesive. Moreover, the team knows things about the project that the new project manager may not yet know so their voices and opinions are important.
Changes can happen at any point of the project management lifecycle.
The easiest way to make managing change on projects less of a headache is to know that it is going to happen and to plan for it. Having strategies in place to deal with changes before they happen is the fastest way to get everyone on board with what is going to be different.
A defined, structured change management process is the best place to start. It tells you what to do if someone suggests that the project should be doing something different to what is currently planned and a good way to avoid project failure.
Look at the change request in detail. You’ll be assessing the impact on:
Schedule
Documentation
Work done to date and work still to do
Budget
Quality measures
Scope
Resource availability.
Change Management Tools
There are a number of change management tools that you can use to make this process easier and more streamlined. I’d recommend:
A checklist or process map that walks people through exactly what they have to do to raise a change to your project scope.
A template change request form. This could be online via an automated workflow.
Let’s look at what goes into a project change request next.
We learned a lot about scheduling and task delegation this week and one major question arose. If the PM changes at different phases of a project (beginning, mid, near conclusion), and the an error in the scope is identified in the mid-phase, what do you suggest doing? More specifically, because the tasks delegated are based on the understanding of the scope and what needs to be accomplished for a project to be completed, if an unaccounted for task is needed to be added to the hierarchy of tasks and then to the schedule, how do you suggest a PM go about managing the existing staff to accomplish this? Do they get more staff, outsource, or just move the schedule around reducing the room for errors increasing risk of failure in the event of delays?
(Assuming that the current staff have the skill sets needed)
If its the beginning, should the whole project genesis procedure be repeated by the new PM but using the information collected by the previous PM?
If an error occurs with a new PM during mid-phase of a project, this new PM needs to fix it. With this being said, before entering into this new position, they need to know as much information on the project as possible. Things such as the sole purpose of the project, the budget, the staff, contractors, any previous and/or possible errors that can occur etc. The is no one precise rule to fixing the error on hand simply because it can big a large error or a minute one. A large error would be having three clinical trials fail. In this case, if a last minute PM still had faith in continuing the project, you would not have to get a new staff, you would simply have to go back to the developing stage and either find more stakeholders or negotiate with the current stakeholders you have to invest more with knowledge that you will not meet the desired deadline. A small error would be running low on supplies due to not monitoring inventory in which the budget would be affected. Although this is fixable it is still considered a minor error. If it is the beginning of the project, I feel that the entire project should have a new plan established using the information collected by the previous PM. There are many strategic ways towards implementing a successful project. Whatever the current PM feels is the best route to take, being that they are in charge they should stick with it. Having previous information would also help ensure if thy are making the best decision.
When an employee leaves a company, there is always some sort of disruption, minimizing this disruption is key to keeping the project on tack. Ideally, the project manager will put in notice of their departure early enough so that there can be multiple debriefing meetings on the current status of the project. Even more ideal would be for the new project manager to be scheduled to onboard close to the departing project managers last day. Meetings should then occur with the team leads to discuss timelines and the different aspects of the project. Once this has occurred, the new project manager can keep the same blueprint or carve out a new blueprint based on observations of the current status to optimize on what direction the project should now proceed.
