You're correct, hard coding dates is not a best practice. I believe we've all debated this before here and everyone will have their own styles and opinions. For me, and project management "is my bag" (MSc in Project Management, PMP, and 18 years' experience), I avoid hard coding dates as much as possible (including the Completion Date). It's not a best practice because as Doug mentioned in another post, reality has other plans for your project and you want to be able to adjust accordingly and know what's happening to your plan and project at all times. When you hard code dates, as you stated you start having to manually change every task and understand it's relationship to others when the date changes. Thus there's risk you miss something and it's time consuming. If you have a predecessor laden plan (with little to no hard coded dates), the tool does that work for you, thus reducing the risk you missed something. There's still the risk something is wrong in the plan (as there always is), but less likely. A common fallacy is that people think a project plan should be written in stone and then not budge and you follow it as-is until the project is complete. That would be great. But that's simply not feasible. A project plan should be fluid. Every project, without exception, has changes (issues, missed deadlines, poor estimates, resource constraints, scope changes, etc.). It's just the nature of the beast. I can cite countless examples where people have said, "this date WILL NOT change" [fist banging on the desk – this was a personal favorite �� ]. You can guess what happened. As such, a PM's job is to anticipate and plan for changes (contingencies in their estimates etc.) as much as possible and keep their project plan accurate to reflect reality so they can adjust when necessary. This involves updating their plan at least weekly. This will then tell you where you're at and you and the Sponsors can make informed decisions when you have to adjust. This is not to say the end date always changes. This is to say task dates will always vary (they're estimates after all). So you want to be able to reflect reality and see what it does to your end date. If it doesn't move, cool. If it does, now you have an early warning and can more easily adjust some tasks in order to make your final end date. I'd also reconsider the whole working the project from the Completion Date method. I never personally found it productive to run the project from the completion date backwards. I've tried it twice and found it much more difficult, time consuming and mind numbing, with no payoff. Honestly I never heard someone say they loved doing that either (unless they had a manifesto in their closet). It's just more confusion and work than it's worth. Even if someone said they use it to determine when we should start the project. I still find it much easier and saner to just create the plan in a forward direction. If I use today as a start date (can't go further back than that �� ) I can then craft a plan to know the end date. If it's later than the desired end date, we can discuss and negotiate from there (which you would also have to do if you work it backwards just to discover you should have started 2 months ago). Essentially I can obtain the same answers in a much easier fashion by working it forward. I'll stop there as I could talk PM forever. I know. Some of you are saying, too late ��
