Home › Forums › Discussion › MS Project Schedule Design Implications (Various Project Life Cycles) › Reply To: MS Project Schedule Design Implications (Various Project Life Cycles)
Let me use an analogy – you are asking if Subaru publishes driving technique guidance for evasive maneuvers in crowded situations during bad weather. No, they do not. Can you do evasive driving in a Subaru during crowded bad conditions? Sure, but you would have learned how in a special driving class or you may have been taught these skills by a mentor from the CIA, but that instruction did not come from Subaru at any point.
Microsoft has built the car and we have to learn to drive it. The manual will tell you some things, but it will not teach you how to be an excellent driver under different conditions. Microsoft is not the final word on how to schedule.
I would point you to the PMI scheduling standard as a citable source of scheduling frameworks. The PMBOK is just the entry point, but it is not everything to know. PMI publishes many supplementary pieces that go deeper into a specific topic. You will find more details about the nuances in each kind of schedule – – Rolling Wave, Iterative, Incremental, Sequential, Spiral, Incremental Design/Iterative Development, and many other not-famous frameworks unique to building construction.
There are two core scheduling concepts that are the crux of every project schedule regardless of the framework or model: Task Dependencies and Task Type.
If you can learn to master dependencies – start to finish, finish to finish, finish to start (aka Waterfall), start to start – you will be able to setup a schedule using any kind of technique. There are reasons to use each dependency type and serious implications by doing so. Microsoft has implemented constraints that must be well understood and that information is in Project help files (the driver’s manual).
Task type is the second lynchpin. Fixed duration creates a timebox and leaves the worked hours free to increase as much as it takes. Fixed effort units creates a cap on worked hours and leaves the end date free to go out as much as it takes. Doing either one has impact on how the schedule unfolds as work occurs and how resources are consumed. Microsoft also publishes their implementation rules in Project help files.