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

Introduction | When Can You Call a Program "In Control?" 
Why Break a Program Down into Subprojects? | Work Breakdown Orientations: Good and Bad
Consequences of Breaking a Program into Subprojects | Hunting for the Critical Path in an IMS
Dealing with Sharing Resources across Programs | Simulating the Critical Path
In Summary: Our Recommendations and References

In Summary: Our Recommendations and References

From the experiences, we gained from this program and engagement, we would like to make the following recommendations:

  • Achieve agreement among stakeholders on when the program is "in control".
    SanDisk considers their program in control when they have at least ten major milestones with time buffers, a detailed critical path into the next major milestone, and a high level of confidence the major milestone date can be met.
     
  • Protect unity of data.
    We see too many program managers fall prey to schedulers who split the schedule in a high-level schedule and detailed schedule and save these in two different files or databases. This requires double bookkeeping and a lot of extra, unnecessary effort to synchronize them. Always extract the high-level views in reports from the low-level detailed schedules. Otherwise, you may become a victim of the two-versions-of-the-truth problem.
     
  • Create autonomous subproject teams (minimize cross-project dependencies)
    Autonomous teams will proceed at their own pace and compete with other teams to stay off the critical path or be on the critical path for as little time as possible. This will benefit the entire program.
     
  • Use the right tools.
    SanDisk looked long and hard before committing to the toolset that could meet all their requirements. The challenging requirements were: Many cross-project dependencies, resource-constrained critical path across multiple projects, simulating the resource-constrained critical path, and producing buffer charts to monitor progress and to forecast delays.

Finally,

  • When you are in a time-to-market organization, use generic resources first to optimize the program to balance the resource needs, and then you will be able to communicate to management the exact resource needs for the whole program.

References

DCMA (2009). DCMA 14 Point Assessment materials, DCMA, USA http://guidebook.dcma.mil/79/Online_Version_IMP-IMS_11_21_09.pptx

National Defense and Industry Association (2012). Planning and Scheduling Excellence Guide (PASEG), NDIA, USA.

Project Management Institute (2011). Practice standard for scheduling — Second edition. Newtown Square, PA: Author.

U.S Government Accountability Office (2012). General best practices for project schedules — exposure draft, GAO, USA. Retrieved from http://www.gao.gov/products/GAO-12-120G

Uyttewaal, E. (2010). Forecast scheduling with Microsoft Project 2010, Canada: ProjectPro. This book has been republished for the 2013 release of Microsoft Project and for Project Online in 2018.

Simulating the Critical Path  Simulating the Critical Path
  

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page