Planning for Change One thing that will never change is the constancy and speed of change. This seems like an obvious truth. Why do we plan as though change will never happen? People are generally quite good at managing change, although abilities vary between individuals. Therefore, I believe that most people assume that they will “figure out it when it happens” when planning. I don’t advocate that we plan for every possible scenario. I’m talking about systems and structures that can be scaled by design and flexible enough not to create excessive overhead when dealing with changes during execution. Some examples:

• Consider how you will build your application. Administrators can easily modify and customize it. This is something that many companies don’t do. Any minor modification will require a new project to create a new release. Make a list of the most popular items that users will be able to customize and make it so.
• You can either hard-code task and resource names when setting up a schedule or performance measurement system. Or you can use a scheme that allows you to assign histories to identifiers in your plan. Although Resource R23 may start as Joe Smith, you can replace him with Amber Jones if he leaves the project or is promoted. You can update the attributes without having to change the schedule by creating a separate history for R23. Your schedule does not need to be updated.

These things will work if you invest more time at the beginning. It takes more planning and programming for the first example. The second example requires a bit more planning and allows you to combine the resource attributes with the schedule information on the fly. The data must still be useful and presentable. You can probably imagine objections to what I just said. Heck, I already have objections. But what if ….is it worth the cost ….? I hope you find this helpful. It will encourage you to think about how to plan for changes in your project to make them less painful. What can you do to prepare for change?