|
This Guest paper, originally published at the 2012 PMI Global Congress Proceedings in Vancouver, Canada, was submitted for publication in February 2021
It is copyright to Eric Uyttewaal, 2021.
Published here May 2021
|
|
When Can You Call a Program "In Control?"
The amount of data in the SanDisk program schedule is mind-boggling. To help you imagine how big it is: If you were to write all 5,000 task names on its walls of the Empire State building starting at the top, you would end up in its basement. You can then travel by elevator from floor to floor to analyze the schedule. This is how it feels when you look with your 22‑inch monitor at the program schedule; you can always see only a fraction of it. How are you going to prevent drowning in the data? When can you proclaim the program to be "in control?"
In each client engagement at ProjectPro, we first try to gain an understanding of when the client regards the program to be "in control." At the SanDisk engagement, we agreed to consider the program "in control" when:
- We created at least ten major milestones in the program schedule.
The ten major milestones divide the network of dependencies into ten sub networks.
- All subproject schedules were dynamic models that forecast the subprojects.
Too many schedulers create very static, rigid schedules that merely reflect how a project should unfold rather than how it is unfolding. You will need to know how the program is unfolding if you want to gain control over the program. It is our experience that schedules only reflect how the project is unfolding if they are set up as dynamic models; see the book Forecast Scheduling with Microsoft Project 2010/2013/2018 for a checklist.
- We had a detailed critical path to the next two major milestones.
A detailed critical path is a path that consists of activities rather than deliverables. This critical path can and will run across more than a subproject schedule.
- We had a 90% confidence level that the next two major milestones would be completed when promised.
The detailed critical path to each milestone should have enough buffer time to make it probable. The tasks on the critical path should be resourced and the likelihood that the resources are available when needed must be high.
We had a high-level critical path to the last major milestone (program finish)
The program often has only high-level deliverables in the back end (no activities), so the critical path for the entire program will only show deliverables rather than activities.
|
|
Introduction
