Hi: Changing dates is nothing new, it is an essential part of every project, of every time. The fact that as the project goes on, people learn things, and things out of the project team’s control happen, drive the change. Knowing how to develop a project plan so that it can be easily changed is a critical skill. Here are some of the things I do: 1) I assume the project plan is an elastic model of what we thing the future holds. I believe a PM is a Project Psychic, not a Project Historian. 2) The project plan has to be built in a way that a change in one aspect will roll through all downstream aspects. That means, tactically, that I rarely ever force dates - I don’t use task constraints of Must Start, Must Finish, or Fixed Dates. Those remove the elasticity. 3) I am a big advocate of using predecessors. If you start with a WBS, and get the advice people who do the work, figuring out the tasks and sequence of tasks is pretty straight forward. The predecessors make the plan elastic; 4) If you use Predecessors, then all you need to do is enter a duration for each task; 5) I do force dates on things that the project team has no control over. If the contract start or expiration date is fixed, we can’t change that, so I force that date. If something has to be done by a fixed time, because of contractual or regulatory requirements, I force that date. When I fix dates, however, I create a section at the top of the project plan called “Dates We Can’t Change” or whatever. I create milestones and force the date. Then, down in the plan, any task that is dependent on the forced date has a predecessor to that line item in the “Dates We Can’t Change” section. I put them at the top because it is easy to see. 6) I create a custom attribute on every task called “Promise Date”. If someone has promised, usually without any basis in fact, that a particular task or deliverable will be done on a specific date, I enter that arbitrary date in the Promise Date attribute. I have a report that shows me those tasks where the Planned Completion Date is later than the Promise Date. If something appears on that report, it means we are going to miss a promise. That helps focus the PM on what needs attention and changed; 7) If there are key dates when we need something from someone, like requirements from the business or client, signoffs, contracts approved by legal, and so on, I put them at the top of the project plan in a section called “Key External Deliverables and Stuff”. These are the things that are most likely to change. Like the “Dates We Can’t Change”, I use these line items as predecessors down in the plan. When these dates change, the change is automatically rippled through the project plan. Then I look at the Promises Missed report to see if we’re going to miss promises as a result. 8) I also make use of milestones (a custom attribute, not WorkFront Milestones) to tag tasks that are of interest to the customer/client/end user. I have a report that shows the schedule of deliverables and events that are of interest to a larger audience. That report is automatically sent to people. Automating communication is something WorkFront does well, and so I use it a lot. The sooner someone sees a problem in the schedule, the sooner we can fix it. Don’t put off changes tomorrow that we must implement today; The key idea is to determine what the fixed and variable external dependencies are and model them in a section all by themselves at the top of the project plan. That way, when things change, you can easily change the dates of the external dependency (if the change is externally driven) or change the duration of a task (if the change is internally driven). That assumes that the essential deliverables and plan doesn’t change. What if the client says - hey, we now need another deliverable/artifact/piece/something? If you create a WBS and iteratively decompose it into concise deliverables, then it is easy to add new high level deliverables to the project plan. You just add a new level one parent to the plan and describe the deliverable underneath. If you use a phase-centric structure to your WBS, well, you’re screwed. It takes a lot of work to interleave the work to produce the new deliverable into the existing Phase centric structure. Phase centric WBS structures have always been a pain, but for some reason, appear to be the most common WBS structuring approach. I don’ know why that is, but I digress. BTW, I use WBS in the classic sense - namely a hierarchy diagram that shows the decomposition of a high level deliverable into smaller deliverables. A WBS in this context is not the task plan in WorkFront. Many people use WBS to mean the detailed task plan, but the WBS and the task plan are actually different things. If you have a proper WBS, it makes it easy to create a task plan and that task plan will definitely align with the WBS. The task plan information starts at the bottom level of abstraction in the WBS and proceeds downward into Work Packages. I also have a Friday Morning Process (described elsewhere in the Global Forum) that I ask PMs to run - every Friday, without fail. One of the biggest reasons project plans are a pain to deal with is because they are not adjusted in small increments as change occurs. If the PM puts off making changes, then the degree of change is large, and likely overwhelming. I’ve had PMs create a new Project Plan when they’ve held off making changes to a plan. Sometimes it is faster just to create a new plan than it is to go back to a weeks-old plan and try to update it. The key idea here is that a PM is like a gardener - the work doesn’t get done all at once in batches, a little work every day pulling weeds, strengthening stakes, watering, and worrying goes a long way. A good PM cannot be a batch processor saving changes for that one day when changes will be made to the plan, they need to be made on an ongoing frequent basis. Its also like taking the rubbish out of your house. If you wait long enough, it is an unpleasant job. Does that help at all? Thanks, Eric
