September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
I would look at the definition of closed loops. The "closing" path of a diagram is often the feedback returned into the initial step for adjustment or modification.
For example, if a car is set to cruise control.
Step 1: Controller sends command to increase throttle
Step 2: Controller measures current speed of car.
- If current speed of car = target speed of car, restart Step 2
- If current speed of car is more than target speed, reduce throttle and return to Step 2
- If current speed of car is less than target speed, return to Step 1
This set of steps is ideal in an operations scenario, or a going-concern scenario. Something which needs constant correction and readjustments. Project tasks, I would say, as specific to achieving the project objectives.
Any project feedback mechanisms (issue review, risk review, defects correction, etc.) are usually sequential (e.g., after identifying defects, we would not revert back in time to the earlier build task - but we would have a new build task to make necessary corrections).
The two quoted relationships in the original post are not analogous. The former states that I will close the book only when I complete reading. It is a FS relationship between [Complete Reading] and [Close Book] tasks.
The latter, I'd say, is pretty much how lazy students behave; "I have read two chapters and have closed the book. Therefore I have completed my reading on this subject". It does not follow.
"Closed loops" in PDM networks are accidents - typically called "circular logic" in the software. E.g. A-B-C-D-A; or in your example, "complete reading" - "close book" - "complete reading." To say closed loops are "not recommended" is an understatement, as their existence prevents completion of the schedule calculations. Closed loops are made more likely by certain scheduling habits, like non-unique activity names or logic on summary tasks, that are discouraged. Practical examples: none.
Real projects do include some feedback loops, especially with respect to inspection and testing, but these cannot be modeled directly using PDM.
Thanks for replies.
Can anyone explain in a better way?
Thomas provided a good example above, but a closed loop is just a circular relationship between dependent activities.
A simple example:
Activity A: Exercising more
Activity B: Eating more
One could say that if we exercise more, we feel the need to eat more, but that in turns makes us feel guilty so we exercise more and the cycle continues.
While there can be circular relationships in normal life, we don't want to see these in project schedules as it would be impossible to forecast or monitor things.
Where a circular relationship might emerge (e.g. test a software module, find bugs, fix bugs, test it again) we need to put some constraints around that such as only allow for two test cycles.
Closed loops happen in bureaucracies, when rules establish that e.g. approvals can only be given when certain conditions apply that in turn require the approvals.
A process flow chart can help in identifying these.
Typical for sequential tasks, you may call it waterfall, which are used for efficiency gains e.g. thru automation. Have seen many closed loops appear in SW development…
As always my recomendation is going to the theory but here comes something practical. Closer loops belongs to GERT (graphical evaluation and review technique). People like me that started working when no PCs and software to support the creation of surelly knows about it. GERT is an "ancient" technique that allows loops, because they are needed in some activities. For example, when you work with iterative life cycles. Usually the problem with closed loops is when the acitivty relation is on itself, that´s the point. View in other way is when an activity iterates on itself. Graphically is not easy to see when the loop will be broken in this cases.
Thank you all!
Please login or join to reply