Home › Forums › Discussion › MS Project Schedule Design Implications (Various Project Life Cycles) › Reply To: MS Project Schedule Design Implications (Various Project Life Cycles)
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.