 Good morning everyone. Welcome to the fourth lecture in the systems dynamics course. Before we start, as usual, a few announcements. Now, on Monday I went to the dentist and, no, I mean, I still suffer. So, actually, I cannot open my mouth so much. That's as much as I can open it. So, if at some point you don't understand what I'm talking about, just stop me and say something. That's one thing. Second thing, I would like to remind the presenting groups from last week to applaud their student solutions. At least I didn't see them yesterday, I think, in the evening. Is there anybody from these groups who presented last Tuesday? Have you applauded your solutions? Because, I mean, there may also be a problem with the Moodle system, because I may have set up the wrong things. So, I want to know if you have problems applauding it, or you just didn't, didn't bother. But I hope you will applaud it by the end of this week. Another administrative thing, this is the fourth lecture. So, after the fourth lecture, we'll have an online test. I already talked about these online tests. The online test will probably be prepared tomorrow, and you will have maybe from four to six hours to complete it, which is plenty of time anyway. In addition to that, there will be more about the online test. I will send an email around. In addition to that, there would be an online survey, which is the other quality control that we're doing this course, where you kind of evaluate me. And it will also probably become available tomorrow, or maybe on Saturday, I don't know. And then you'll have one week to complete this online survey. It's going to be a mixture of multiple choice questions, and kind of a manual text input, where you can write comments and stuff like that. And then we all discuss, so of course it's anonymous. Even to me, it will be anonymous. This is the point. But then we'll all discuss the aggregate results. And I'll show you what the majority thinks. All right. Are there any questions? Yeah. The online test, you will have, let's say, four to six hours after you start it, but the whole online test would be available for maybe a week. So you will have one week to start it. But then once you start it, you have, yeah, four to six hours. If you don't think, if you try to find everything on the slides, it would take you maybe about 30 minutes, I think. About 30 minutes, 20 to 30 minutes. But, yeah, the point of these online tests is not to make it possible to fail them, unless, of course, you don't want to do them, which is, there is nothing we can do about it. The point of the online test is to simply make you go through the slides. And just by going through the slides and finding information, you automatically remember something. All right. Are there any questions regarding the previous lectures or self-studies? Because today we kind of start a new topic. You can ask questions later and also you can ask any questions during the self-studies regarding the lectures. So let me start. Today I'm going to be using a fancy presenter because those of you who have seen the slides, you saw that there are diagrams and kind of drawings that I simply need to navigate through. And if I use this laser pointer, you can see, but the people watching the recording cannot see. So this kind of makes it very difficult for people to follow these lectures only with the podcast. So with this thing, I can do a lot of fancy things. For example, I can do like a spotlight thing, right? So for example, this is lecture four. I can, what was it? I can zoom in. This is the professor. Yeah. And this is the email that you should send all your questions to. So yeah, lots of cool things. It kind of makes it difficult to navigate because when I move it, the cursor moves, but anyway, these are petty concerns. All right. Let's start. Again, as I will do in every lecture until the end, and as you should expect from me in every lecture until the end, a summary of what we've done so far. We've looked at mostly finding solutions to problems that we already discussed, their nature. These are complex problems, non-trivial problems, multiple criteria problems. And we looked at ways to analyze the situation, to analyze the problem and find solutions for it, and then select what we hope to be the better solution finally implemented. We looked at the problem-solving cycle as a framework for coming up with solution approaches and selecting solution approaches. We started with project management last lecture. Today we're going to finish project management. It's mostly about implementing solutions. We looked at how projects can be scheduled from time perspective, so the critical path method. Today we're going to be talking about some deficiencies of the critical path method and how we can address them. Hopefully you know the critical path method is the thing which determines your project duration and we can also deal artificially, of course, with uncertainty in the critical path method by using these kind of buffers and floats. So if you have uncertainty you can just allocate more buffers, which is kind of artificial because the nature of uncertainty is something that you cannot really predict, so the question is kind of paradoxal. How can you allocate buffer for something that you can't really predict? But this is one deficiency of the critical path method. What buffers are good for, however, is to shuffle resources around. So if you have a critical activity with no buffers, or critical with zero buffers, then you can shift some of the resources from tasks with a lot of float to it and then hopefully speed up the whole process. We saw an example in the last lecture and probably there would be a similar task required in the exam. The rest of the course is basically going to be about studying our solution. This should be just one question mark. This is not like a super existential question, but this is what the rest of the course is going to be about. Does the solution work? And if not, who is to blame? And I particularly like this lecture, today's lecture, because there's going to be an example precisely of this situation. The solution doesn't work. And two parties argue whom to blame. And they actually argue and settle this in court. And they use systems dynamics to do this, which is pretty amazing. They use modeling and stuff like this, which reminds me that today we're also going to be introduced to modeling. The system dynamics model that I talked about. You will not have to do any models for the self-study, not yet, but this is just the flavor of the models we're talking about, the so-called system level models. We model the whole system, not the individual elements within it. All right. As I promised you last week, we're going to focus a little bit more on quality management. So quality. Last week we saw how time constraints can influence our project. Today we're going to see how quality constraints are going to influence our projects. And the quality, I mean, what is quality control? In simple terms. Kind of intuitive notion. What do you understand when somebody tells you, yeah, our project needs quality control? Yeah. Yes. That's true. And then what do you do after you measure the outcome? And if expectations don't match reality? What if it's something that is needed? You need to deliver it, but it doesn't work as you expected. Fix it is good enough. I was looking for the term go back and fix it. Because quality control is nothing more than a feedback loop. And today we're also going to be introduced to feedback loops, which is going to be expanded in next lectures, but quality control is simply a feedback loop. So at some point in your project, and what these points are, is also going to be introduced, you check your expectations in terms of quality. If something doesn't work, you just go back and fix it. It's not as simple as that, of course. Sometimes you can't fix it. Sometimes you need to account for propagating changes along your project. But this is what quality control represents. A feedback loop. Nothing more. So today what we saw already is kind of a sequential approach to project scheduling. We saw the critical path method. We saw how you can break a project into subtasks. And these subtasks were either sequential completely or fully concurrent, fully parallel. If you remember the critical path, you can have a whole chain of tasks which are fully sequential, or you can have two tasks which are completely concurrent, completely parallel, but nowhere in between. What this lecture is going to be about is the so-called multi-phase projects. Because you see in every big project, you can't just split things into subtasks and blindly going through all the subtasks. If you build a garage, like we saw the example in last lecture, maybe you can do this. But if you have to build a tunnel which spans 15, 20 years, or if you have to produce some software product or microchip, you need to do more than just splitting into activities and tasks, and you need to do these kind of phases. And here we're going to be talking about the project life cycle, which is nothing more than the human life cycle. As humans, you're born, you grow up, you're mature. Eventually, you decline. Well, you decline. Eventually, you die. And it's the same with the project. It's conceptualized. This is one phase. Then it's designed. Another phase. It's implemented. And then it's finally decommissioned. So these are the multi-phase projects, and we're going to see that things get complicated. We have multiple phases, each with a different task. And this picture, hopefully, illustrates the idea. So here we have a project which starts from here and then finishes here. And we have multiple phases within this project. It's up to you to define the phases. Different industries have different standards for defining project phases. And within each phase, okay, I shouldn't use the point. Within each phase, we have a number of activities. So these are the activities that we talked about. For example, design phase. What do I need to do to design my product? The production phase, the same thing. And you can use the critical path or this kind of scheduling approaches within each phase. And let me introduce some terminology. We have the so-called upstream and downstream directions. It's similar to supply chain. When you go upstream, you go to the producers of raw materials. When you go downstream, you go to the customers. And here's the same thing. When you go upstream, you go to the beginning phases of the project. When you go downstream, you basically go to the commissioning or getting the project out of the market. And here, quality control, these kind of feedback loops can happen between phases. So let's say your production can spot some kind of design flaws, which are only available, which are only known at production stage. And then you feedback these inputs back to design. Or you can have quality control within each phase. It's pretty intuitive. There are going to be examples on this. However, these are what we call kind of unwanted feedbacks. Nobody wants to realize that at some point, your quality or your project is delayed and then you have to go back and fix something. And what people normally do, since this is kind of an unwanted thing, they fall into certain mental traps. We're going to be talking about these mental traps. But in essence, it's the idea that you don't want to spend too much resources going back. So basically, you settle for something suboptimal. What you said, do we really need this thing? If we don't really need it, then we just don't care about it, which is already a problem because if you didn't really need it, then you shouldn't have put it in your milestone. But the point of this slide is that we can have feedback loops between phases and within a phase. All right. So how do we control for the success in terms of quality, in terms of time, between different phases, and also within a phase? And probably the MAI students or also the master students with work experience already know that people like to use this idea of milestones. You can have milestones or checkpoints as many as you want, basically. Of course, there is again a fine balance between having too many milestones, too much paperwork, too much administrative overhead, and too few milestones, which would basically leave a lot of deficiencies unspotted on time. But the milestone is simply a decision point. It's simply a checkpoint. And you can, for now, let's imagine we put the milestones between each phase, although this does not have to be the case. Two things happen at a milestone. You produce some report outlining what this milestone has achieved, and then you make a decision based on this report or deliverable. Here it's called deliverable, yes. And the decision, of course, maybe, do I go back and fix something? Do I stop the project? Or do I just continue because my milestone is okay? And I think this idea is pretty intuitive. It's each deliverable or each report that you present to your managers or to your stakeholders in the project would either consist of results, tangible results, like you've managed to implement some piece of software, you've managed to create a prototype of something, it works, or it consists of some intangible results, depending on what your milestone is. It could be some, you come up with an idea, how to approach a problem, you come up with a concept with a model, things like this. But the important thing is, again, you have to be able to evaluate your milestones, just like you have to be able to evaluate your solutions. How we do this? Of course, objectives. Objectives are very important. You can only, you can be as precise as your objectives are, not more. All right. So there are two ways, well, we're going to be looking at two ways to define milestones and to keep track of how each, the performance at each milestone. The first way is a very kind of visually appealing and intuitive way. It's this milestone trend diagram. So has somebody ever worked with the milestone trend diagram? Have you ever seen this? No one, good. All right. The idea is pretty simple. Let's, let's try to explain it with this thing now. So on the x-axis, right, so this here is the big, or let's say this thing is, this here is the beginning of a project. This is time zero or time one, however you want to, to index that. This is the beginning of the project. And the x-axis are the reporting dates. Reporting date, dates meaning at each of these dates, so these are relative dates compared to the beginning of a project. So this is, let's say, two months after the beginning, three months after the beginning of the project, four, five and so on. So at each reporting date, you ask yourself, how much is it going, how long is it going to take me to complete some milestone? Let's look at the green milestone, right? So in the beginning of your project you ask the team, let's say the project team, how long is it going to take you to complete the green milestone? And then they say, well it's going to take me eight months after the beginning of the project. So if this is January, then eight months would be August. Then you say, okay fine, you record that thing as a point. One month later you ask the project team again, how long is it going to take you now? You've been already one month into the project. And they tell you again, well it's going to take me eight months. I will finish again in August. The estimate holds. And then so on, three months, seven or six months. After six months you ask them, how long is it going to take you to complete the project? They tell you, well eight months, everything is fine. Right? You see already that this is a good thing. The estimate never changed. So you are always on schedule. You didn't uncover or you didn't discover some kind of quality problems, time delays, unexpected consequences, things like this. So this is a good thing. Now let's look here. You can already see that the revision of the estimated time needed to complete the black milestone increases as the project continues. So basically when you ask the project team, how long is it going to take in the fourth month? How long is it going to take you? Well it's going to take me now four months, almost five months. Even though in the beginning I told you it's going to take me three months. So this is an example where a project is being delayed, has quality problems, and things like this which cause this shift in time. And the good case here is, well we're going to see if that's really a good case, but basically this is the opposite thing. So you ask the team and they constantly revise their schedule in a way that now your project takes less time. Is that clear? It's pretty intuitive, right? If it's clear then can you tell me why there can never be any points in this half, in the lower half? Only after day three, yes. Basically that's the reason. If at some point you find a point here, this means that either for you time is going backwards somehow or your project is out of date. So you ask let's say in the eighth month you ask some team and they tell you well it's going to take me five months after the start of the project to continue to finish that milestone. Which means that this estimation is out of date. All right. This was the milestone trend diagram. It's pretty intuitive. It's very simple. You can really spot delays as they appear. Of course this depends on the granularity of your milestones which brings me back to the point that two fine milestones can allow you to spot delays or quality problems almost in real time, but it will generate way too much administrative overhead. So you have to find a trade-off. If you just have two milestones in the beginning and then at the end of the project you will probably never spot any problems. It forces people to be disciplined which may be or may not be a good thing depending on the culture of your company of course. I would imagine I think that's similar to this scrum methodology in software development where you kind of force people to come up with exact well not exact but quite reasonable estimates on how long they're going to need to complete a certain piece of work. Well this is the same thing basically. You ask them constantly to revise their estimations and it kind of forces people and project teams to be more disciplined in their time management. But of course again this could be a negative thing. You need to yourself like the person doing this or the manager doing this you need to be disciplined yourself because you have to collect all these data somehow. You have to constantly update it. So I find this or maybe that's that's the reason why this approach is not used so much because it really requires a lot of discipline from all the parties involved. But again if you have experiences please bring them forward. Another thing that you need to do in order for this trend diagram to work is you have to be aware that if there is a delay in the project you spot a delay. You know that you have to go back and fix something but this is much easier said than done because going back and fixing something involves feedback loops. So maybe the fix that you need to do is contingent on on something else that needs to be changed more upstream. So you need to have an idea of how different feedback loops influence each other in your project. We're going to see how this is modeled. But the conventional project management approaches tend to ignore this kind of simultaneously operating feedback loops. All right another way to keep track of our success or the milestone success is this so-called integrated cost and date control. The idea is also simple. You have a kind of a in this case it's a two-dimensional space with your important dimensions that you care about. For example here we care about time and costs but of course you can add as many dimensions as you want. This basically defines what success means to you what successful milestone means for you and of course you put each milestone in this space right. For example here we have a milestone which took more time to complete and it cost more to complete so that you can clearly say well that's a negative thing. Depending on how you wait the different dimensions you can have you can basically have positive or negative effects attributed to tasks which violate one of these two dimensions. Here we wait date or we wait time and costs equally so if you have a task which fell short on one of the dimensions but made up for it in another dimension we kind of say that this is neutral right. It took more time to complete in this case but it cost us less so all in all it's a neutral case. Of course this depends entirely on how you wait time and cost and in most cases this is not true. The same thing for here right you needed more money to complete your milestone but it took you less time. Here we have the positive case where it took you less money and less time than planned. Is this really positive though? Yes I wouldn't call it a mistake although this may be the case but I wouldn't like to call it a mistake. Yes positive meaning can you define that? So would you say this would we put such a milestone would we say it's a positive negative neutral what would you say? I agree. It is negative not because not only because you maybe made a mistake which of course can happen but it can also be negative on a different level. It could be imagine you talk to your customer and then your customer after you deliver your customer sees that you deliver earlier and it took you less money than planned so what would the customer think? They would think well do you really know how to schedule your projects? This time it took you a lot less in both dimensions but next time maybe it would take you a lot more. Furthermore did you do it intentionally? You know did you just try to sell success later on right by estimating more time more money and then sell me this success which was actually not a success really it was just kind of an overestimation from your site in the beginning. So I find this is a kind of a negative thing to have even though you may not deliver to an outside customer even though you may deliver only within your own organization this is still I think a bad case. When you intentionally or unintentionally underestimate or overestimate the requirements yes that's true that is true but the thing is normally when you have a multiple-phase project so let's say your customer wants a microchip from your side right of course you kind of constantly revise the schedule but at some point at the end let's say shipping right just the shipping needs to be done this is kind of a self-sufficient phase so you can even think that this is the end phase of your contract with the customer. Shipping is something that you can more or less estimate the costs and the time needed to ship the product. For instance I can give you an example I recently well actually not recently and that's the problem I ordered the laptop from Neptune it's probably many of you have done so but now it's been one month I haven't got this laptop and it's probably going to be at least half a month until I get it because they have problems with the shipping so in that case you can say that there are somewhere here right so this is actually an example going to not to this point but to the point that you can still estimate the end phase with your customer all right so I wouldn't say this is a positive thing at all maybe yeah then your assumption may not be so right after all you agree that this is positive yes of course I agree this is actually a good point and and you are part you're right in the sense that if this is an end phase of your project like the very end thing that you do then this this reasoning applies right but if it's the beginning obviously it's not you can make up for this or you can revise your project scheduling so at the end it may be it may even be positive thing but I I do think that if that's the only face in your project it's a very simple project let's say can you can you write a simple program for me and I'll pay you something and then you you say well I'm going to need one month then it's going to cost me 1000 francs and then it takes your week and it costs you 100 francs then of course that's what people do exactly true yes I would say the positive is here but of course you can never well no it's not binary things can never be either completely positive or completely negative right so this could be even if it's slightly here it may be positive you know it contextual completely of course all right but I just wanted to bring up this point with project scheduling that sometimes going doing or let's say performing much better than what you projected also needs attention so you need to revise the way you estimate things finally the the final thing with with the project management approach is these control gates so basically at the milestone you take a decision should I continue or should I stop with the project I did not I did not fulfill my milestone the quality is bad I will not fit in the total project estimated time so what do I do do we stop the project or for instance you suddenly realize that your project has lost its market its target market like the chip your manufacturing cannot be sold now because it would be too big for the market and you only find this out after the production phase for instance so what do you do you stop the project or you go back and you change something and it really has to do with resources lots of time you don't have enough resources to go back and to change your project so what normally happens what ideally should happen is you should kind of stop the project but what normally happens people just go with it anyway right and hope that the laptop they've produced will still sell somehow even though it's much heavier than everybody else's laptops right however if you have enough resources in terms of let's say time in terms of money mostly to go back in to change something then there is this is the kind of a mental trap that I'm going to what happens is remember the problem-solving cycle you had a you had a diff numerous solution approaches let's say you selected some of the better ones the best one whatever that means now when you go back you need to you need to make a choice do I explore new alternatives so do I find new ways to produce this microchip so that it's smaller or less power more power efficient or do I settle for kind of a suboptimal design right so if you have to explore new alternatives that would cost even more money however if you don't if you just say well let's go back in and take one of the solution candidates that we had before this would actually cost you less money compared to what you've already invested but you would end up with a suboptimal solution and in these situations people tend to attribute extra credit to these suboptimal solutions in retrospect right so they go back and they think well this solution was not that bad after all maybe we should have chosen it the first time so you know it's cheaper and it's going to take us less time to implement and you know maybe maybe the problem with more power or less less more DPM defects per million is not such a big thing we didn't estimate correctly the negative parts of this solution so probably it will work out fine so you settle for you don't really settle actually you you convince yourself that this suboptimal solution is good is better at least better than than you originally thought and you do it and then you end up with with a with something which is actually even more disastrous than than if you had just stopped the project initially so this is the the way we call it here a mental trap in a sense it's something that you have to be aware of if you ever go back and you try to change something in your project and you find yourself attributing more weight or more credit to these solutions that initially you disregarded then you're falling into this trap and it's kind of dangerous and due to this I mean why is this the case obviously you've invested a lot of resources in your project so far and your ability this graph shows is your ability to change the project is a lot less than in the beginning so your freedom is a lot less what you can do is you can either invest a lot to change the whole project or you just invest a little bit and you settle with a suboptimal solution what this shows you is kind of a abstract way of the relationship between your freedom of change and the progress of your project so we have as time goes okay this is just one phase the development phase but of course it could be any phase as time goes your knowledge about the system increases right here you have only basic assumptions basic cost estimates basic resource estimates and then your knowledge about the system increases now it's gonna cost you more it's going to take you more time maybe I'll be late at the end but your freedom at the end to change something is a lot less because you've already invested a lot in the project and this is called this what we call path dependence more on this in the coming lectures but you know this is I think it's pretty intuitive right it's only conceptual for instance if at the end of your if during the writing of your master thesis you suddenly realize that you didn't want to study physics you wanted to study French literature right it's it's too difficult it's it's too hard to change the freedom that you can do is yeah maybe you can read a few French books but you have to complete your master thesis again the other option is to invest a lot of resources ditch completely everything you've done so far and start studying French literature and people do that actually they just suddenly realized that they wanted to do something else completely actually a former professor of mine used to kind of bring to our attention this potential conflict so hopefully he mentioned this in the beginning right so if you don't want to study if you're not sure you want to study this maybe you should change which is a good advice actually but not a good advice if it's at the end all right so I mentioned that quality control and also checking your milestones going back and changing something is nothing more than a feedback loop this is the the technical the technical term okay I have to speed up a little bit and what is the feedback loop I think most of you especially the engineers around you are painfully familiar with with feedback loops especially the electrical engineers but what feedback loop is something it's a very simple concept you have a certain input which goes to your system you take some of the output say you take your milestone and you compare it to something that you expected if this is not what you expected you change your input right and an example could be with this heating heating a room right you expect you want 21 degrees for instance obviously now I want a little bit less but if you want 21 degrees and you measure let's say 30 degrees then you have to decrease your heating system next time you measure maybe it's 19 degrees it's too few it's too little so you have to increase all right so let's continue after the break yes all right let's continue let me just set my timer here so I told you about the feedback loops what the feedback loop actually is in in our course let's say in judging how this kind of going back and fixing attitude how it affects your system will distinguish between negative feedback loops and positive feedback loops without going into technicalities in engineering for instance a negative feedback loop is something is going back in fixing something is what brings you to a balance to an equilibrium kind of state right so you go back and you balance your input in a way that your output that in a way that your output goes to to the value or to the milestone that you expected right for instance you set a quality standard a negative feedback loop would be go back you fix something in your process so that this quality standard can be achieved right a simple example again is the is the heating system where you constantly try to bring the output to the desired temperature this is a negative feedback loop and different other examples are let's say the standard supply and demand idea or the interrelationship between supply and demand in economics for instance right if for some reason supply increases then the price would go down and demand would increase as well there would be a new equilibrium point so this is this kind of a negative feedback idea the by the way the human homeostasis works in the same way right the way that your body regulates its temperature it works in exactly the same way you have a question okay right if you get too hot then your body emits sweat if you get too cold then blood vessels close and temperatures preserved in your system which is actually pretty good now positive feedback loops it's kind of a terminology mix up because in reality negative feedback is good it's positive in a sense but positive feedback loops are bad positive feedback loops lead to exploding behavior in your system this explosion can go you know you can explode a certain value or you can decrease it to zero but it's basically driving you away from equilibrium okay all the bubbles are positive feedback loops self-fulfilling expectations are positive feedback loops right you expect the house prices to go up therefore you buy houses so that you can sell them at the high price later on but buying houses causes the price to go up again and then it goes up and up and up eventually people realize this this inflation and everything crashes right so these are positive feedback loops but also I mean it doesn't have to be as abstract as this if you take a if you take a microphone and you go next to a loudspeaker even if you don't talk you would get this squeaking noise right because the random noise which is like not perceived by you gets amplified by the microphone comes out amplified from the speaker gets picked up by the microphone again gets amplified even more gets picked up again and then in couple of milliseconds you have this explosion so these are the positive feedback loops and I would say unfortunately in big projects each negative feedback loop that you want to establish in order to fix something is accompanied by a positive feedback loop which destabilizes your system we're going to see an example of this but keep it in mind because what managers want to do is they constantly try to implement these negative feedback loops but they sometimes don't know or they miss the overlook the positive feedback loops which actually can more than offset the gains from the negative feedback and going back to this idea feedback in general I just want to show you the different kind of let's say the span of different feedbacks that you can have here we talk about quality feedback loops again but imagine the following right let's say this is our okay this is our typical problem-solving cycle sorry yes it's basically problem-solving cycle so you set your objective you come up with solution approaches and then you implement this whatever solution this is the end of the project right so this could be just one little face of your project it could be just one little task in your project like produce whatever software library so what happens is at the end or some point at some point of your project you make you have a milestone defined right and then you compare you control in a sense is the current output in this current time of the project face or activity is it what I expected no if it's not well then maybe this one is a bit better this is the blue feedback loop if not then we need to change something project the project management task is to to to change something to take corresponding measures for instance you see that you're going to be delayed your project is going to be delayed so measures could be you make people work over time for instance or you hire more people to do the job faster so at the end you can you can be on time but something so this is changes feedback loops within your project within your whatever the project may be it may be an activity or whatever right so within your project but they're also feedback loops that go out of the project and the the the idea is the following so here again you do your controlling you see that something is wrong but now what is wrong is not project specific maybe what is wrong is the feasibility of your whole project you know this is the idea does it make sense to continue with that project anymore maybe it will be outdated by the time I finished with it and I won't be able to sell it for instance so what you need to do there's nothing you can do in project management there's there's no overtime or more workers than you can hire you need to go back to your planning stage and and you need to to ask yourself the question well does this project make sense now if yes what can we what do we change in the goals in the goals of the project in the aims of the project so you go back to the very very beginning right you realize you cannot sell this microchip because it's going to be too big there's nothing you can do about it you go back to the beginning and you design a smaller microchip and then you go again in implementing this smaller microchip so these are these two different scopes of your feedback loops within the project itself so incremental improvements you might say and those that span let's say the environment right you estimate the feasibility of your project or the aims of the project whether they still make sense and now as I promised in the first lecture we'll deal with these kind of small changes here right you need to constantly change something due to various reasons your your customer wants you to change something you realize that you need to change something so in other words in other words this one in large-scale project management for instance yes the tunnel the gothart rail tunnel right it's a huge project I think it's going to be completed 2015 or 2016 or something it's going to be open for for use I think it's spent it started 1991 or something so it's a huge project and you can imagine that in these big projects even if everything goes according to plan in your customer doesn't want any changes to be done there are still things happening that you cannot control new technology is being developed new regulation standards are being established so suddenly your project needs to be let's say more environmental friendly and you only realize this when you're in the middle of that of that project or let's say your customer wants wants to incorporate the new technology like in the example we're going to see so this kind of small I mean if you compare to the scope and to the resources of the project this kind of small changes what is the effect of these small changes on the project and the example that we're going to see is is going to illustrate perfectly these small changes in court so the question is these small changes that you do and sometimes there is no other way but you have to do them right even though everything is fine new technology comes available and so on do they add up and result linearly do they add up linearly and result in small impact overall small impact or do they end up add up through these feedback loops and do they propagate and add up in a complicated nonlinear way that eventually results in in the project cancellation right so what is the impact of these small changes given these large-scale projects and what is important also to realize is that these small changes are unavoidable in large scale projects they're simply things that you can't control in in life yes so this is really a scientific question at the end of the day it's not it's not just a minor concern we really need to know the role of small changes and the example the running example for this lecture one of the yes one of the two running examples is the case with the shipbuilding company in-goal shipbuilding so basically what happened is and just in your notes you have a reference to a book where this example is taken from I will post the chapter of the book that deals with this so there's a lot more information legal information all this kind of stuff about the settings but what happened is that this company they won a contract from the US Navy and in the seventh in the beginning of the 70s to build these ships like 30 destroyers and nine carriers and that was a big deal at the time you know that in the US a lot of money are spent on defense and there was a lot of money involved in this project in fact these these were the only two projects I think two of the four projects that this company was working on and all of the projects were from the US Navy right so this was a big thing for them and the scope of this project was so huge that they had to double their workforce at the end they had 20,000 people working on building 30 destroyers and nine carriers I mean 20,000 people it's a huge amount of workers and what happened when I don't remember exactly the time but I think the estimated time was about 15 years or something to build these things what happened is the US Navy being the customer they constantly requested new technologies to be incorporated they always wanted to have the latest GPS tracking ability and and whatnot in in their ships so as new technology became available they went back to the to the Ingle manufacturer to the Ingle shipbuilding and they requested these changes at the end of the day what happened is that the projected cost overrun was in the scope of 500 million US dollars and just to put this number into perspective the turnover the annual turnover of this company was in about the same range in the same ballpark right so basically they would need just to cover this project they would need and let's say the same amount of money as their total turnover for one year not profit but turnover so it was a big big big cost overrun which of course generated the conflict between the shipbuilding company and and the US Navy as you may imagine the shipbuilders they claimed that all these small changes cost a lot of feedback loops in upstream they cost a lot of you know unexpected delays and eventually resulted in this 500 million dollars cost overrun the US Navy on the other hand they took the opposite position they said well these are just small changes within a given task so we're willing to pay whatever this kind of overwork for employees might have cost the direct costs but this in no way can be in the in the range of 500 million right these were just small changes and basically the company is at fault because they have bad project management they don't allow enough buffers for their tasks so if there is some delay they cannot handle this so it's bad project management on their side and what happened is actually the shipbuilder the shipbuilding company they sued the US Navy and since there the the plaintiff they had to prove actually in court that these small changes were the result resulted in this huge cost overrun so they had to prove this they hired a consulting company to develop to model this whole process of building a ship right and the basically there is this conventional model the way that the shipbuilding company was estimating this the effect of these small changes and all this kind of stuff was done without taking into consideration any feedback loops any propagating or rippling effects from a small change and this consulting company they developed a system dynamics model it's here they develop a system dynamics model which takes into account all these all these interrelationships between different tasks especially feedback loops right and what happened at the end was they had this model they could prove that these kind of small changes could result in a big overall impact then the shipbuilding company went to the US Navy presented the model and basically this was as a proof that the US Navy was at fault the US Navy in fact inspected this model and I mean scrutinized the model really they came up with some criticism for the methodology for the estimations of the costs of the different changes different tasks and so on and they expected that these modifications would greatly reduce the impact of the small changes but when the shipbuilding company implemented these criticism these critics the overall impact was actually higher right so the US Navy did not expect that by decreasing the cost of some of the tasks they will actually get a higher impact and at the end actually I just noticed yesterday that somewhere in your notes it says that the shipbuilding company won a lawsuit there was no lawsuit at the end they settled outside of court and they settled for 450 million dollars out of 500 which is almost everything right so there was a I found this out because I wanted to find the court cases you know they're public so I wanted to find them but I couldn't find them at the end it turns out that they settled outside of court okay so I will introduce the system dynamics model that these consultants consultants developed before doing that there are a few kind of entities that exist in that model or structures as you might call them we distinguish between the following kind of activities not activities but entities entities I guess is the right word we have work to be done right so this is the work that needs to be done you can estimate it in different ways that's not so important but there is an entity called work to be done for instance if I'm an important bureaucrat and I have to put stamps on a paper right the work to be done maybe this pile of paper here that I need to stamp the work being done here the work being done is the actual paper that I'm putting a stamp on so this is the work that is currently in process the work really done is the the completed work which has passed quality standards yeah so this is where quality comes into play right you can imagine you can immediately see that this model incorporates this kind of quality concerns at every unit of work and it turns out I mean these consultants also did some empirical empirical work later on they found out that the the work really done the first time in in commercial in the commercial in the industry is 68% so 70% of all the work is really done in a quality way the first time no no need for feedback but in the military projects it's appalling it's 35% so it's a huge I mean as you might expect I guess it's a huge you know deficiency in in in this kind of military project and so what happens once once you realize that your work done does not conform to quality standards then the question is okay what needs to be changed and the thing that needs to be changed is the work it's referred here as the undiscovered rework so you now you know that you have to do something which you didn't know before before the quality check again before going into the details of the model let me introduce in a more kind of system dynamics perspective how these models look like in general what the entities that we're going to be working with and eventually you'll have to simulate this in yourself studies are called basically stocks and flows stocks this is a stock right stock is something is basically an entity or quantity which accumulates value over time right the work to be done is a stock because it accumulates over time as more work becomes available it's a stock variable or its stock quantity the rate of change of this stock quantity is called a flow so if you have the work to be done as a stock variable the work which is currently being done so the work which is taken out of this stock variable and currently being processed like the sheet of paper that I take to put a stamp on is called a flow because it reduces your stock variable in the same way the work which goes for example I put my sheet of paper on the work done stock variable this would be called also flow because it increases the corresponding stock variable so we work with stock and flows and this is called inflow and outflow it's pretty intuitive right so for example the flow of materials like the flow of papers that I get is a flow variable this could be the pile of processed papers or let's say this could be the this is the work to be done this is the papers that come to me for stamping and this is you know somebody's giving is constantly replenishing this pile of papers that I have to work on right so like citizens giving me bureaucratic things to do all right we can put this whole model into equations I mean that's how they they express them in system dynamics the stock variable here the change of the value of the stock variable at any point of time is simply the total sum of all the inflows and all the outflows up to this time right so this is a don't be intimidated by this kind of this kind of equations you will not have to produce these kind of equations in the exam although it will help yes the work really done it depends on on how you structure a project if you have the work really done what do you do with it that's the question maybe you you give it to somebody else for further processing maybe you send you send these pieces of paper by email by by mail to people so it depends what what your project is yes yes for sure if you have an stock variable which is called work done but not checked for quality and if you discover a mistake in this when you check for quality discover something some task was done wrong then of course this outflow you take this task you put it to another stock variable which may be called work to be redone right because it's a it's a faulty thing so this would also be an outflow so yes mistakes discovered mistakes could also be an outflow it's all conceptual I mean it's all up to you how you define your stocks and your flows but this is the idea if something accumulates over time it's a stock if it's just the temporal instantaneous flow layer it's kind of a double definition but you got the point so the stock is simply the the net sum of the or the the net difference between the everything that goes into a stock and that goes out of the stock and you sum this basically integrals just some you sum this over all the preceding time and of course we have some starting value for the stock right in some cases your stock variable your work to be done already exists when you got the project if you're that unfortunate project manager alright we can so this is the integral way to describe this by a sum you can also describe it in a differential way and the question here is how does my stock change with time you know before the question was what is the total value of the stock it is given time now the question is how does it change with time well it's it's much simpler there are no integrals at any given point of time the change in your stock would be the difference between what goes in and what comes out okay alright so with this in mind that is a the basic concept of the system dynamics model that these consultants developed of course the whole model is it's completely out of scope of this lecture and even in the book you can't find the the whole model I have uploaded the paper in the literature section today which is written by one of the consultants working on this project there you can find more details about the model in terms of you know more real life examples for not real-life examples but more yeah kind of quantitative details regarding all the entities here if you want to read it of course you're welcome to do so but the important point is to understand the the concept and the concept is the following as I mentioned these guys said the following well let's model the work to be done is a stock variable right so this is stock we have a work to be done in any project we also have the work really done so what is the difference between work to be done and work to be work really done well that's the quality check that you do right this is the basic feedback loop you have something that needs to be done you do it right you do it here work being done I put a stamp on the paper and then somebody checks whether this stamp was aligned correctly for instance if that's the case then my other stock variable work really done increases by whatever amount if that's not the case however if something doesn't work then you put it in a stock variable which is called you know doesn't work you don't know why it just doesn't work you take this talk variable then maybe somebody else takes this talk variable some other team and they discover what is the problem with this thing what needs to be changed and they put it in a stock variable called known rework so this is work which does not conform to quality standards and you know how to fix it right this is work which does not conform you don't know how to fix it and then again the known rework goes back to the process of work being done so it's kind of a another inflow to that goes to the quality check later on right this is clear so you see the feedback loop this is the feedback loop the quality feedback loop that we talked about here but now what is interesting to see is that you have work which is really being done you have built one or let's say 10 meters of your tunnel or you've produced five libraries of your software product and then suddenly a customer comes and says well I want you to to change this you know I want now my product to have this latest GPS tracking capabilities for instance which what happens is you take some of the work which is really done and you need to change that right to incorporate the customer changes which goes back to the stock variable known rework so it's not defect per se but it still needs to be changed in some way and then it goes here so this is the the second feedback loop this one which is entirely due to customer changes here all right and basically the bullet points are everything everything that I said so far therefore I think it would be easier so basically this slide explains that diagram and I think it would be easier to just start with that diagram and only later on for your own reference you can refer to you can refer to this slide but this is a more detailed example of the system dynamics model that they developed and at this point let me let me just remind you what the system dynamics model is you model the whole system right you don't model the individual interactions between you know people or between project managers you model your whole system from from kind of a bird's-eye perspective so here we have the typical other the familiar stock variables work to be done on rework and so on now what happens I think it would be easier to remove this what happens if your customer comes and requests small changes from you or some changes let's say I wanted to incorporate this new new functionality because this is getting popular nowadays it will be important in 15 years so what happens is well you try to create the so-called negative feedback loops and in other words you try to to fulfill these these requests right so what happens is well you hire more people right this is one thing that managers can do you have more people so they can work more and they will kind of finish they will be able to do this additional work at the same time so we hire more people here this would affect it's don't worry about the technical term for people you will see this but for now just remember stock flows and we have people here so we hire more people and this will obviously increase the work being done right this intuitive what you can also do however is you can make the current people or the current workforce workforce to work more to do some overtime all right it again well you know the 90-hour week mentality in one of the companies in Silicon Valley when it was being established right so you all but you ask your people to work more and again this would affect the work currently being done another thing that you can do as a manager well you can accelerate the schedule which would hopefully increase the productivity of your people and then again it increases the work being done so you try to of course these are just examples the in the real model they had different things but you see how you try to make some project management changes which bring you closer to the goal that you want to achieve these are the negative feedback loops but as I told you each negative feedback loop is accompanied by positive feedback loop which destabilize the whole system for instance you hire more people maybe in your vicinity of your company the skilled workforce is not that prevalent so you end up hiring less quality people right the average employee skill goes down which so these are the dotted lines this is the positive feedback loops which would affect your productivity in the mid to long term I mean what do you do with these people if they're not as skilled as your hiring standards what do you do with them maybe their work that they're actually doing is not as good so you need you would increase that feedback here the quality feedback so this is one example you ask people to work overtime what may happen is they get tired they burn out suddenly some of your best people start to leave the company they go to the competitor so this again this would affect your productivity right another example is you accelerate the schedule basically you ask people to to do more things in parallel for instance which causes congestion people piling people waiting for to use the same machine for instance coordination problems obviously if things now need to be done in parallel then they have to be coordinated all this kind of stuff and it causes also moral problems like obviously people get demotivated so you see these are just an examples of a positive feedback loop which accompanies each negative feedback loop and in the system dynamics model that these guys develop they they had these things incorporated so by doing this as I told you they were able to prove to the to you to the US Navy that these small changes resulted in unexpected unintended consequences which is one of the characteristics of complex systems when we try to influence a complex system there are unintended consequences that sometimes even with the best efforts we we cannot predict but there is still a lot we can do there is still a lot we can we can predict by trying to think about these kind of feedback loops positive and negative feedback loops lessons learned from these examples is that small changes can ripple down or ripple across your whole project all the phases and result in big delays yes so basically I've said all this we tend to neglect the indirect effects we tend to neglect them because first of all obviously they're more difficult to spot they take more time to spot so we just simply tend to to ignore them these were the effect of small changes now I need to speed up a bit now we we come up to another optimization kind of technique so far we've dealt primarily with either fully sequential tasks fully sequential also in the project phases we saw one phase follows another phase another phase from upstream to downstream the critical path method assumes sequentiality or full concurrency but what if all these different phases conceptualization design development and decommissioning of a project for instance all these phases they I mean they don't need to be sequential and in fact this goes into the direction of concurrent development some of you may be familiar with this so you do part of the design phase at the same time with with let's say part of the the production work needed right so these different phases do not need to happen sequentially and this is the this idea of cross-function or concurrent development where you basically try to study the network of your phases so the phases the different actually I should go like this the different phases in your project are not sequential but they're kind of assembled in a network so they can some of them can be done in concurrency in a concurrent way in parallel so imagine yes we have the product definition the design and the product testing quality control phases for instance and these guys I think yes you can find the paper of these guys in the literature section but they propose the following thing maybe that would be easier to see they said well no matter how many phases so this was the goal remember we need to study how the different phases in your project can be done concurrently and to what extent they can be done concurrently and also which projects in types of industries and stuff like this can be done concurrently so they said well no matter how many project phases we have of course it's up to you as a project manager it's up to your industry to define different phases that you need to do but within each phase within each phase we have more or less the following they call them subsystems or let's say different categories of tasks that you need to do within each subsystem within each phase and here they've talked about they name this process process structure phase so this is a phase where you basically think about what work needs to be done in this phase like if it's a design phase you think about well what do designers need to do if that's a production phase what do the manufacturing guys need to do then you have a kind of a category or a subsystem which is called resources so these are the available resources you have the scope of that phase what is the scope of your design you just want to design whatever product and you have your quality target mostly quality targets but also of course time time targets and budget targets and all of these different subsystems affect the actual performance of that phase the actual performance in terms of cycle time defect rate and cost cycle time is basically how many times you have to go back ignore the feedbacks for now the point is here that each of these subsystems affect the performance in a direct way for instance the available resources affect your performance because of course the resources are limited so you can only do your project or you can only accomplish that phase in that time you cannot do it any faster because you just don't have enough resources like for instance so you have each of these subsystems affect the performance in a direct way but also the different subsystems affect each other for instance the work that needs to be done in that phase generates demand generates demand for resources right this is how you affect the resources if you if you need to to design let's say DRAM memory the resources you need a lot less than if you need to design a GPU latest generation for instance right so different subsystems affect each other and yeah that's that's the most important thing let's see do I need to go through that yes quickly actually so these are the different phases that you can have in your project for instance you can have product definition design prototype testing and quality control and as a this is basically the multi-phase projects each phase influence each other directly and by influence I mean depend on each other for example product prototyping of course you need to have a design already in place and of course you need to have some kind of product definition sometimes even without design you can do some testing or you can do some prototypes only with having the product definition but also the quality loop comes into play if something doesn't work here then you need to go back and you need change something in your design and so on so this is this is the this feedback actually this feedback is what we don't like right we'd never like to go back in to change something and this is what it's called the feedback corruption in a sense all right let's see now so this guys they focused only on the work that needs to be done in a given phase they focused only on this work and they tried to model it in a system dynamics way and they did this so what we have here are all the tasks which are not completed that needs to be done so all the design work that you need to do they're completed at some rate and they go to another stock variable which is called tasks completed but not checked then you check the tasks for quality this is the quality loop here if the quality is fine then they move to the tasks which are approved and then finally you release the tasks for the next phases or for the next yeah for the next phases most likely right so this is the idea we already saw now I will move to the important stuff this is this is just that picture put in a different way I will skip that because we're running out of time but back to the original question how much of your different phases can be done concurrently and not only can different phases be done concurrently but the work within each phase so the design work for instance in the design phase it can be done so different activities there can be done concurrently as well and these guys came up with the following way to visualize that here we have percent of the work which is done and it passes quality control here here we have percent which is done and passes quality control plus what is available for completion for instance if you have a let's say a software product and this is in fact this curve is an example if you have a software product in fact this is an example from a software product in that particular example it was split in different blocks you know normally you don't do the big software projects at one time they're split in different blocks and ideally all the blocks can be done concurrently in parallel right this is the design phase or the implementation phase all of them could be done concurrently this is the ideal phase the most non-ideal cases when they have to be done in sequence in that particular case they need to do 20% of the blocks of the software blocks 20% before they can parallelize all the others right so unless you complete 20% of the work you cannot do anything else all the others have to wait all the other 80% have to wait this is what is illustrated here unless you do 20% of the work this is 20% the work which is available for you to do is so the work which is available for you to do plus the work which is already being done is just again 20% right you understand that you start at zero for instance you haven't done anything what is the work available for you to do it's not 100% it's just 20% I just want to finish with that slide which is one of the last slides and we'll talk about these slides in the self-study actually I will explain them in more details but this is actually a very very nice slide what it shows you is now these are different phases of your project and you know the different phases can be done concurrently let's say the design phase can be done some of it can be done concurrently with the production phase so what they these guys did they asked they asked the designer in the design phase they asked the design manager again in design phase they asked the product architect and a strategic marketing guy which is part of the product definition phase what in their opinion is the level of concurrency between product definition and design so they asked for instance the marketing guys which are responsible for product definition what do you think the concurrency between your phase and the design phase is in other words how much work do you think you need to complete before the design guys can start working what this means is that the marketing guy really thought that he or she needed to do only a little bit of work let's say only 1% or let's say this is 10% if they only do 10% of their work then the design guys should be able to do 40% of their available work so they thought that they only need to do a little for the design people to start working a lot this is what basically thought and you saw you see actually and the same with the product architect but you see the design people actually had a completely different opinion they thought that the product definition guys should do a lot of work before the design people can start doing just a little bit right so this is a very nice conflict of interest you may say a conflict of perception which was made made known by this approach now yeah this is not so important and the summary so we didn't have so much time this time this lecture there were a lot of things to explain I will come back to slides which are not clear and I mean even if you understand everything I would still address some of the slides on Tuesday in the self-study and basically if you just look at the figures in the papers that are available all these lights are there but in principle you shouldn't be able to do it you shouldn't have to do it thank you