September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
We use iterative, incremental and iterative-incremental (with Scrum) life cycles using MS Project (in the past, now we are migrating). My experience is you have to make a separation between the life cycle, the method and the representation of it. Think about what you need to show to your stakeholders and map it into the tool. That´s could be independient of the way you monitoring and control things.
In such projects where scope is very fluid, you may be better off locking down cost and time which will then define how many feedback loops can be run.
this is risk management case. Planning your project you shall model risk events. An example of risk event - the need for the development loop that can happen with some probability.
An example - probability of the first loop is 50%, probability of the second loop is 30% and probability of the third loop is 10%.
Simulating risks you will get the probability to finish project to any specific date.
This is classical project management and an example of such model is included in the Demo version of Spider Project that can be downloaded from http://www.spiderproject.com/index.php/spiderproject/spiderdemo
The classic Systems Engineering "V" development lifecycle of top-down decomposition and bottom-up verification is in fact an iterative life cycle with validation at each layer of decomposition. Similarly gated reviews are also iterative where at each gate the project must meet a higher level of maturity.
Early in the lifecycles, there are less released deliverables although there may be proof of concept activities and subjective assessments such as Preliminary Design Reviews with a set of pass/fail criteria, non-advocate reviews, etc. As the project definition matures, there is more formality in the deliverables such as firm architecture, long-lead design complete, firm interface definition milestones, and Critical Design Reviews. Final deliverables are scheduled individually in the later project phases.
When you plot the schedule events over time, you get an S-curve with fewer scheduled events in the early phases, steeply increasing deliverable releases towards the middle/later phases, tapering off in the product verification phase.
Sergio made good points.
Please login or join to reply