Hi Guys,
I have a project which the initial Project end date on the Project Plan will end next week but we haven’t been able to complete the project due to a lot of external forces beyond everyone’s control, So do I update the new plan and resubmit a new version of the project plan or do I create a new project plan with just the outstanding items from the previous plan and call it a “Remedial Plan”? Which is best? Saving Changes...
I guess it depends on circumstances.
If what you have already done is functional and can be used in production, then you could go with closing the project, deliver what you have, and set up a new project to deliver the rest at a later date.
But if what you already have cannot work as a stand-alone, then it makes little sense to deliver it - you're better off updating the Project Plan and live with the delay. Saving Changes...
Russell GeakeProject Management Consultant| Deciduous Partners LtdLostwithiel, Cornwall, United Kingdom
I'll differ here. No - the project is not complete. Just because the original plan said it should have ended by now, the project is most definitely not complete. If you have been tracking the project (e.g. in MS Project) and regularly adding actual progress, then you will be able to identify the remaining effort required.
You can use the baseline feature to update only those tasks which remain outstanding. (just remember to save versions before and after the project baseline was updated)
Details of any changes should be retained along with the rationale for doing so. e.g. if a delivery was delayed by a supplier, and this coincided with unsuitable weather. Make sure that Issue register is updated and ALL stakeholders are made aware of the changes, and get approvals from the Project Board. Remember also to ensure any additional authority which may have been bestowed for the duration of the project is also extended in accordance with the re-baselined plan.
Most importantly - hold a review of circumstances at this point, and conduct a thorough review of project risks. It sounds like this needs to be a bit more tightly controlled, even if the risks themselves can't be.
Good luck. Saving Changes...
Barry SmithePMO Project/Program Manager| Taylor CorporationCedarville, Oh, United States
I have done both. From a project reporting standpoint the orignal go-live date is still the benchmark any schedule variances need to be evaluated against. As long as you keep track of that in a way that is visiable to your project sponsors, I think it is OK to build a new plan in what ever tool you are using. At the end of the day, it is what works best for your team. Saving Changes...
Hi Oluwole,
I wonder dis-regarding current plan & creating new one, will only help you disguising facts. Why not track the delay & be transparent with project stakeholders? I agree with Russell that you can use base-lining to benchmark changes to current plan with respect to what was proposed originally.
Even if project delayed was to be attributed to internal reasons, I strongly believe recording delays/changes in plan, base-lining and learning from this exercise can be useful in next project. In your case, you mentioned elements outside your control have delayed the project completion; if I were in you place, I would communicate clearly to project stakeholders about reasons of delay, changes in the plan, implication thereof and seek approval.
Russell, I agree with your differing, in the sense that (and perhaps I wasn't sufficently clear in my previous post) you can't just close a project early just to stick to the deadline and call it a win. That's not what I'm suggesting. I'm proposing that, if you have a working piece of software available, you give that to your client as a first step, with a clear explanation of why the product is NOT complete, what works and what doesn't, and the outline of your plan to deliver the rest of the agreed-upon functionalities within a reasonable timeframe.
By no means such a contingency measure should be considered as an overwrite to the original plan - just a reasonable amendment. Saving Changes...
Hans RobbersSenior Director| SalesforceVlissingen, Netherlands
Oluwole
Eveyrthing depends on where you are and what is remainign. However the best thing based on the information available is to baseline the plan in MSP and create the update plan. In this way you keep the old version and can compare afterwards on hwat has happened. Especially if some closed tasks have to be re opened it can become rather awkward
ALos helps you to provide reports on total hours spent overrun on phases etc in the close down sessions
hopes this helps
Hans Saving Changes...
Sonya CalefSenior Project Manager| Hennepin CountyMinneapolis, Mn, United States
The project schedule should evolve as more information about the work comes to light. Nobody can create a perfect long-range plan that never needs revision. (This is a common project management myth I run into often. If we were psychic, would we not be on a large yacht docked at Monte Carlo, raking in money from the high-stakes bacarat tables?)
If you are like me, and not psychic, plan to adjust your plan.
If you don't true-up the current plan, and just start a new one, you lose the ability to take measurements against original estimates and timelines. If the original plan was not setup correctly to start with, then I might say start fresh. In this case, I say do the housekeeping to update the current plan and just accept the severity of the corrections needed.
Going forward, here is my advice:
Recognizing what could impact you at the beginning gives the team knowledge about what risks need to be controlled. If weather is a serious risk, then alternate plans could be created to use in the event of a weather event, insurance purchased, or unplanned delays accepted. If suppliers are uncertain, do risk planning for that.
Recognizing what has activated and is now impacting the project gives the team knowledge about what issues require control. Often these bring change orders about. File change orders so you have a record of what caused specific impacts to your project, particularly the schedule in this case. An approved change order will let you adjust the project schedule as you go (and budget too), so it should never become "expired". With each adjustment, rebaseline.
I would also suggest that you go back and look for places that change could have really been prevented, controlled, or at least foreseen with better planning. This observation can go in lessons learned. If the team had time to do more risk planning or requirements gathering or vendor research (for example), XYZ would have been avoided that cost us XX weeks and XX money.
Another suggestion is to look at how the plan became "expired". Not to blame anyone, but to improve project management practices. If you (or any other PMs) were so busy managing other details for other people, or doing other people's work, that you could not attend to the plan properly, this is an important lesson to document. If the PM takes their eye off the plan because of daily fires, something is wrong on the team. Roles are out of alignment. Resources may not be assigned properly. Sponsorship might be weak. Your job is not to do the project, but to manage it. If you are not managing the information about the work, then who is? Maybe you need better support to do your job.
I hope this is helpful! Saving Changes...
Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
I would go with updating the original plan. This will at least give you something that you can compare to the original original plan (if you know what I mean) and is a truer reflection on reality than a remedial plan. Saving Changes...
Wayne MackRetired| RetiredSouth Riding, Va, United States
This will primarily be a client/sponsor/stakeholder decision. I am assuming that the client has been kept informed of the project delays and is not due a surprise that it will not be delivered on time. Depending upon the situation, either approach may be used.
If the project is late due to lack of resources, but the costs are in line with what has been completed, it may make sense to keep the original schedule and primarily track costs. Unless the resource issue has been fully resolved, it is worth the effort to project a new date that will be missed to replace an old date that has been missed.
If, on the other hand, the underlying issues have been resolved and there is enough information to make a knowledgeable new plan, then rebaselining may be warrented.
Remember, rebaseling does nothing to change the reality of a late or over budget project. If rebaselining provides the client with useful information for ongoing business planning, then it may be justified. If rebaselining is just intended to save the project manager the embarrassment of reporting on a "red" project, it isn't needed.
