CLD Casual Loop Diagram
I have to study the project of developing a new product, the main goal for the organization is to make a profit, but the product life cycle is short. Only three years after the start of the product development project, the product is obsolete and no customer will buy the product anymore. This means that the number of weeks that the product is actually sold to customers is equal to 3 years minus the development time. I must therefore be able to balance the right number of employees to be taken in order to maximize profits by reducing the development time to have more time to sell the product, but taking account of development costs.
In the book of Business Dynamic the five steps of the modeling process are given. I have already the first step (problem articulation).
-Scheduled Development Time (SDT) = 60 weeks
-Planned Team Size (PTS) = 10 persons
- Planned Product Performance (PP) = 1.45 (in which 0.5 ≤ PP ≤ 2)
PP = 1 means that the product is similar to products that are already on the market. So the higher the PP, the better the product is compared to products of the competition, and the more potential customers (PC) the company can interest in buying the product. This relationship is reflected in the following equation:
Initial Potential Customers = PC(0) = 10000*PP
-Besides PC, also the sales price (sp) is dependent on the PP. The higher PP, the higher the sales price customers will be willing to pay for the product. This is reflected in the following equation: sp = 41.72 * PP [euro/product]
-The labor costs of Rookie Engineers is 750 [euro/person/week]
-The labor costs of Experienced Engineers is 950 [euro/person/week]
-The time that an experienced engineer requires on average to develop 1 task is 4.18 [weeks/task/person]
- A rookie engineer needs on average 67% more time to do a task.
-Each rookie needs to be supervised by one experienced engineer. This supervision costs the experienced engineer 20% of his time (for each rookie). So, 1 experienced engineer can supervise a maximum of 5 rookies.
-The project uncertainty (pu) is 33%. This means that at the start of the project 33% of the final workload is not yet discovered. The number of tasks that are discovered (Project Tasks in Execution (TE) in the beginning is: TE(0) = (1-pu) * 100 * PP. The number of project tasks that are undiscovered (UT) in the beginning is: UT(0) = pu * 100 * PP. These undiscovered tasks are gradually discovered during the project. The average discovery delay of these undiscovered tasks is 12 weeks.
-When project tasks are executed, they flow to the state Project Tasks Finished (TF). As soon as > 99% of all tasks (= 100 * PP) are finished, the project is considered to be complete and the developed product can be sold to customers that are ready to buy the product.
Someone can help me to make a causal loop diagram! Because I've tried, but I would like to compare my work with that of some expert in the field!
Thank you all for your cooperation
NB:If you need I can attach my job ....
CLD Casual Loop Diagram
CLD causal loop diagram
Hi
The best thing is to start first with a much simpler definition that will lead to a diagram of no more than 3 or 4 elements first, then transform that diagram into a highly simple quantitative model, use and analyse that simple model until you consider that there is nothing more to learn out of it, and this time is much more long than you can imagine. Then add some slightly more material to your first diagram, and repeat the process etc.. If you have a doubt about what material to add, then you did not use enough the first model or it is not useful to develop the model further.
These steps may be reconducted many times depending on the complexity of the model.
I personnaly do not even build a CLD and build directly a quantitative model from reality check equations defined before the model as explained in the chapter of the user guide explaining reality checks. I have not yet used this method long enough to really appreciate its efficiency but until now, it looks very promising and I have not yet found any drawbacks. The only one is that it needs a close, continuous and knowledgable participation of the person who knows the problem and who is supposed to use the model and takes the decisions. It is not a problem for me as I am at the same time the modeller and the client but it will be for most of the modellers who have to cope with different circumstances. I suspect that it is the main reason why the method seems to be rarely used. I have never seen so far a published model with reality checks. Too bad because it really seems to change the life.
If you are interested by the method, I can send you directly a paper from the SD review from David Peterson and Bob Eberlein that complements very well the explanations of the user guide.
The file is too big to be uploadable to the forum, so I need you e-mail adress.
Regards.
JJ
[Edited on 19-11-2010 by LAUJJL]
[Edited on 19-11-2010 by LAUJJL]
The best thing is to start first with a much simpler definition that will lead to a diagram of no more than 3 or 4 elements first, then transform that diagram into a highly simple quantitative model, use and analyse that simple model until you consider that there is nothing more to learn out of it, and this time is much more long than you can imagine. Then add some slightly more material to your first diagram, and repeat the process etc.. If you have a doubt about what material to add, then you did not use enough the first model or it is not useful to develop the model further.
These steps may be reconducted many times depending on the complexity of the model.
I personnaly do not even build a CLD and build directly a quantitative model from reality check equations defined before the model as explained in the chapter of the user guide explaining reality checks. I have not yet used this method long enough to really appreciate its efficiency but until now, it looks very promising and I have not yet found any drawbacks. The only one is that it needs a close, continuous and knowledgable participation of the person who knows the problem and who is supposed to use the model and takes the decisions. It is not a problem for me as I am at the same time the modeller and the client but it will be for most of the modellers who have to cope with different circumstances. I suspect that it is the main reason why the method seems to be rarely used. I have never seen so far a published model with reality checks. Too bad because it really seems to change the life.
If you are interested by the method, I can send you directly a paper from the SD review from David Peterson and Bob Eberlein that complements very well the explanations of the user guide.
The file is too big to be uploadable to the forum, so I need you e-mail adress.
Regards.
JJ
[Edited on 19-11-2010 by LAUJJL]
[Edited on 19-11-2010 by LAUJJL]