For years, the PMI has teased me with mentions of a Schedule Management Plan in the PMBOK. It obviously existed, and even was listed as an input to one of the Time Management processes, but it never got called out as its own separate artifact with its own planning process. Obviously, this implied some sort of bias against the scheduler caste. Didn’t Risk, HR, Communications, Quality and Procurement have their own planning processes in the 3rd Edition? Even Scope had its own Scope Management Planning process in the 3rd Edition which provided hundreds if not thousands of PMP instructors around the world the opportunity to expound on issues of scope metaplanning, i.e. on the plan of how you will develop the plan. Some of the best “aha!” moments I got in class were around that section of the program.
I welcomed the fact that Scope had its own planning process, and was looking forward to the 4th Edition of the PMBOK including separate planning processes for both Time and Cost – thereby forcing training curriculums to call out each one as a unique artifact. Imagine my surprise when I opened my fresh new copy of the 4th Edition a couple months back, and found that Scope, Time and Cost Planning were once again relegated to the catch-all process of Develop Project Management Plan.
The Schedule Management Plan is a key artifact of any EPM implementation cycle. Whether the organization is just beginning it’s EPM journey, or has been on it for some years, there is always a strong need to develop a clear, centralized policy on how schedules should be created, tracked, and updated in an environment with shared project resources, and eventually, centralized tracking.
Arguably, any EPM implementation starts and ends with the development of a Schedule Management Plan. From the early stages of Envisioning to the final stages of Training, the process involves understanding the myriad of factors that go into a schedule, configuring the system to enable those policies, and then getting acceptance from the end users of the system as to whether or not they’re willing to work with the schedule framework. The schedule templates that are a standard part of any deployment are typically a small part of what should be in a Schedule Management Plan. The tool then is the technical framework to support the process, i.e. the tail on the dog from an ITSM perspective.
Unfortunately, many companies end their metaplanning process with the development of schedule templates, and neglect to consider how they plan to update their projects. They look at an EPM tool implementation as just that, a tool implementation, and not a process development and reinforcement exercise.
At a minimum, a Schedule Management Plan should include answers to the following questions:
- Who develops the schedule?
- Who signs off on the schedule?
- What’s the workflow around developing a schedule and saving a baseline?
- What are the phase gate review criteria that must be met in terms of schedule quality?
- How will the schedule be reported on?
- How will changes to the schedule be incorporated?
- What will the update process be? Will it use Physical % Complete, % Complete, or % Work Complete? What about EVMS?
- Will the organization track effort? Cost?
- How will external contractors update their tasks?
- How will the tasks track to completion criteria?
- How are schedule and cost contingencies tracked?
- What risk management techniques will be incorporate into the schedule? How will target dates be communicated: deterministically or probabilistically?
- How do lessons learned become incorporated into revised schedule management plans?
- What level of variance is considered acceptable, and what level should automatically trigger a change request?
I would contend that most of the companies that I work with have never developed such a metaplan before I show up, but typically develop one in the course of the EPM tool deployment, which perhaps provides us with another argument for the magic stone deployment archetype for EPM deployments.
If you ever want to demonstrate the need for a schedule management plan in an organization, get a large group of about 20-40 project managers and schedulers, then sit them down in a Microsoft Project training session for two days, and have the instructor walk through the entire generic project lifecycle in Project, allowing adequate time for discussion of key procedural points. See if you don’t come out of that with a solid understanding of the process gaps that need to be ironed out.
But who should develop this plan? Always the implementing business, and not the external consultant. The consultant can facilitate, and provide options based on broad industry knowledge (or specific niche experience – apparently the jury is still out on that according to the IIBA panel I attended last week). But, at the end of the day, it’s up to the business to develop and therefore own the plan.