One thing that never changes is the constancy of change. That seems like a self-evident truth, doesn’t it? So why do we plan as if change will not happen?People in general are fairly good at managing change, but of course we vary widely in those abilities among individuals. As a result, I believe most of the time when in the planning process, we assume that we will “figure it out when it happens”.I’m not advocating that we try to cover every scenario in our planning. I am talking about setting up systems and structures which are able to scale by design and flexible enough to not create massive overhead when dealing with change during execution. Some examples:- When planning an application, consider building it in such a way that customization and modifications are easy, and can be performed by administrators. Many companies do not do this. Instead, any little modification requires a new project for a new release. At least make a list of the most likely items users will want to customize, and make the structure conducive to those changes without an enormous amount of effort.
- When setting up a schedule and/or performance measurement system, you can hard-code resource and task names, or you can use a scheme whereby identifiers in the plan have histories. Resource R23 might start out as Joe Smith, but if he is promoted or leaves the project, you may replace him with Amber Jones. With a separate history for R23, you just update the attributes outside of the schedule. Your schedule requires no update.
Now, for these things to work, you must invest more time in the beginning. With the first example, it requires more planning and programming. With the second, it’s a little more planning and a way to mesh the schedule information with the resource attributes on the fly. The data still needs to be as useful and presentable.
You can probably think of objections to what I said above. Heck, I have objections in my head already. But what if….is the cost justified….
My hope here is just to get you to think about what can be done during project planning to anticipate likely changes and make them less painless when they happen.
What do you do to plan for change?
About the author
Josh Nankivel is a Project Planning & Controls Control Account Manager and contractor for the ground system of the Landsat Data Continuity Mission, a joint project between the USGS and NASA. His academic background includes a BS in Project Management, summa cum laude. He can be found writing and contributing in many places within the project management community, and his primary project management website is located at pmstudent.com.
