This is my first question as a relative new user of project 2013 and appreciate some guidance.
I’m working on a country by country roll-out of a new application.
There are many activities which need to be done in sequence:
– configuration / test
– user testing and sign-off
– data cleanse
– migration / prepare production
The problem is, the go-live is known… Eg 20-Nov. all the preceding activities need to be completed (with their own interdependencies) before the go-live. Some of these activities have unknwown lead-times which doesn’t really help with overall end-to-end planning.
From a planning perspective, I was wondering if I should turn the mpp around a bit so that go-live is a fixed date,
Then all other tasks are linked to the go-live with negative lag values?
I suppose the picture that I’d like to get to is a “standard implementation activity list per country”, so that by setting the go-live date into the project, all preceding activities are populated with Must-Finish-By-Dates… In order to get to a “Must Start on” date… Just a thought if this makes sense, or if I should stick with the standard start to end approach and keep tweaking until the dates fit….
Thanks for your advice
Mark, a somewhat common challenge and great question. There actually is a way to have Project schedule backwards (Project tab / Project Information / Schedule from: Project Finish Date. I wouldn’t recommend it especially with such a large program and it is a big change from scheduling forward. I personally don’t like the process of figuring out a start date as you now just created a time dependent schedule in which your critical path cannot be delayed.
So if it were me I would try to create a schedule that included a set of primary milestones. Each section/milestone would have at least a minimal about of contingency to mitigate the risk. Each milestone could be fixed or better yet have a deadline to let you know how you are progressing. I have a blog entry on using milestones and contingency if you want to give it a try: http://www.epmsolutionpartners.com/2012/04/managing-schedule-contingency.html.
In short, make sure your schedule will deliver on time and manage to at least some contingency. I can do that better scheduling from the start date than from the finish date. Hope that helps…
Many Thanks for your reply.
I’ll have a look at your blog and try your suggestions.
I have this problem a lot in my projects. I tend to run a hybrid of what you and Larry are talking about, because Larry is right backwards scheduling can (is) a nightmare. I tend to get all my task in place and as Larry mentioned create a good set of milestones. Then I try to fill in any times I know or can estimate 90% or better. Set your go live date as a must finish by and then link all your task as you want to. If you know the majority of your times this will almost set the timing for the ones you do not know. I use it a lot in motivating my engineers with tool runoffs. Customer SOP is set tooling complete date is known, whats left in between there is tool runoff and PPAp timing. When you set it this way once a task exceeds your end date Project will turn it read and let you know you have issues. Then you start Program manager wheeling and dealing to make up the time.
Hope this helps. I am sure Larry will agree this is one of those things where there is 10 ways to skin a cat, you just have to try a cuple and see what works for you.
I definitely agree with Darren. He did a good job of walking through a scenario. I might add one addition. Instead of just one hard milestone at the finish of the project, think about setting a handful of hard milestones through the project…either by phase or major deliverable. That way you can maintain some sort of contingency through the project. If you exceed your project end date when you are only 25% through the project, it will be more difficult to replan. If you timebox each phase/deliverable and you see that you are over on design, then it might be easier to cut scope. Otherwise you might be cutting scope later on that you already invested in design effort. Just a thought.
Darren is right, there are as many variations as there are Project Managers (OK, well maybe not that many). The best approach has as much to do with your specific project than a single best practice. Good luck…