Does Microsoft publish any guidance, good or best practices on schedule development and design using MS Project—as it relates to a particular project life cycle? Also, can anyone suggest a reputable/trustworthy white-paper on the subject where I can learn more?
Project Life Cycles (aka approaches or development life cycles) can be Predictive (plan-driven/waterfall), Adaptive (agile), Iterative, Incremental, or a hybrid.
Source: “The Continuum of Project Life Cycles” found in the current Project Management Body of Knowledge (PMBOK) 6th Ed.’s APPENDIX X3.
Having managed projects since the 1980s and with many different scheduling tools, I can honestly say I’ve only had one project that followed a single pure life cycle model. I’ve also spent many years in a large organization with 250+ PMs consulting with them on questions such as this.
With that said, I have not seen any Microsoft Published guidelines or recommendations. Not to say that it doesn’t exist somewhere. What I have seen has been MS and third party techniques, how-to, and approaches, to using MS Project to support the different life cycle models. And while there are lots of theories on how to structure your schedule, I found (my opinion) that applying “bits and pieces” from different approaches as it makes sense for my current project work to be the best approach. Keep in mind that my approach takes into account a LOT of variables. Some of which include;
* How skilled is the team? Have they done this 50 times or has this never been done? Do we need more detailed planning to support their skill sets or can I trust the team to manage the details in their own checklists/tools outside the schedule, which allows me to then use more generic, higher level tasks in the schedule?
* How complicated is the project? Are you producing an Android phone app with little/no external interfaces in which many small incremental roll outs can be easily performed or is this a large complex business project requiring coordinated resource management across many business groups/departments and/or managed/coordinated upgrades across multiple different systems?
* What makes sense for the type of work being done within the project? Meaning, development work may lend itself to an agile like approach while technical infrastructure work demands more of a planned or waterfall approach.
* What do you need to get out of the schedule for reporting/tracking purposes? In a predictive model, the schedule is the primary source of reporting progress forecasting when resources are needed, and forecast target dates. In an agile model, the schedule may be more of a generic time reporting function while project progress is being managed within some form of an agile story card management tool.
As far as white papers, I’d suggest looking into Product Based Planning, which is a subset of the Prince2 model originating from the UK. Its not a MS Project white paper. Product Based Planning is a planning approach to lend structure and organization to how the work will be delivered (releases, scope, sequence, etc.). It is an excellent approach geared to understanding what (the products) is to be delivered. It forces the business and IT to define the final end product and the subsequent Product Breakdown Structure (scope and release structures) that will get you there.
The key is that its product oriented meaning that to build this product/deliverable, we need to perform this amount of work and produce this set of sub-deliverables. For example, to build a car (end product), we need a frame, and drive train, and interior, and a body. The scope of each is defined and then each of those is then deconstructed so we know the drive train includes the engine, transmission, front/rear axles, etc. Subsequently, each of those can be broken down to smaller deliverables. Prince2 Product Based Planning also includes Product Flow which directly drives work scheduling sequence. Meaning, the engine and frame can be developed in parallel, but I need the frame completed before I can add the engine. This enables business to see background work (so to speak) that is required to roll out the releases. Meaning, at a high level, the business sees application screen changes for the next release, but may not understand that background database and interface changes also have to happen for the next release to be functional.
Regardless of how the project will be developed, this type of structure and analysis allows both business and IT to define and agree upon the specific scope, release structures, and so on. It also lays the foundation for iterative development teams to help them within their release/iteration planning meetings.
Once the deliverables, scope, and sequence is known, structuring the schedule to support the project should be based on the type or work and other factors such as those noted earlier. For more predictive schedules, the Product Breakdown Structure becomes the project schedule WBS. For iterative/agile models, the the sequence developed identifies and helps sequence the story cards.
MS Project can support both waterfall and agile models. One consideration should also be the amount of work you as the PM will need to perform to maintain and support that schedule. Not to say that your level of schedule work overrides or mandates how you setup the schedule. But saying that you need to set up the schedule so that it fulfills what you to get out of the schedule in terms of reporting, tracking, forecasting, etc. For example, if your story cards are managed in an external tool, why setup the project schedule with detailed tasks for each card and then constantly have to be shifting those tasks (story cards) around the schedule as they are planned for an iteration but then later moved to another iteration. In cases like this it may be sufficient enough to construct the schedule with 2 week iteration tasks and use the story card management tool for detailed story card management/reporting. But if no story card tool is available, you may need to build and manage the schedule at the story card level.
One final thought. I’ve seen many PMs struggle/fail because they attempted to force all project work into a single pure model such as Agile only. Utilize the schedule model that makes the most sense for the type of project work being done.
I know, lots of theory and high level thoughts on your question, but I hope this helps move you in the right direction.
Thank you very much for your timely and thoughtful response.
The intent of my post is to identify Microsoft Authored resources that provide insight on how MS Project’s user interface helps users to adapt their schedule to the various project lifecycles along the continuum of possibilities.
For example, a user identifies a project life cycle (from the continuum of possibilities) that is a best fit for their project. Does Microsoft provide guidance, good and best practice tips to help their MS Project Users to navigate the design and development of their project schedule—based on the Users needs and wants?
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.
Referring me to PMI for white-papers is great. Thx!
“You will find more details about the nuances in each kind of schedule – – Rolling Wave, Iterative, Incremental, Sequential, Spiral, Incremental Design/Iterative Development…”
Work Breakdown Structure (WBS) in Traditional and Agile Life Cycles with MS Project | MPUG
– Practice Standard for Work Breakdown Structures – Third Edition (2019)
– Practice Standard for Scheduling – Third Edition (2019)
#projectmanagement #projectscheduling #wbs #agileprojectmanagement #waterfallprojectmanagement
Using Sprint Projects in Microsoft Project | MPUG
Adaptive project management (Agile)?
Until recently, I had forgotten about this informative ~50 minute webcast sponsored by the International Institute for Learning (IIL).
Microsoft Project Goes Agile! Webcast