 Okay, good morning everyone. Sorry for this delay, there was something with the resolution was not right on the recording. So, yeah, good morning. Before we start, I'd like to make a few announcements, as usual. I'd like to remind you to vote on the course forum. For those of you who are not aware, we had the following idea during the last self-study, or before the last self-study, namely to allow students to upload their solutions to the self-studies. Originally, I didn't plan to have sample solutions posted for various reasons. I already told you there are no best sample solutions for the things we're doing, and it would be also motivated to solve things on your own if there are no sample solutions. But student solutions sounded like a good idea, so we decided to have a poll. Please go on the forum and vote. It's completely anonymous, and you have time until next Tuesday to do it. So there was one week from Tuesday to Tuesday. Second thing about the group schedule, or the presentation schedules, I will make the complete schedule of all the groups, all the presentations, until the end, so that everybody knows when they have to present and how many groups have to present at any given time. I will do that probably today in the afternoon or the latest tomorrow morning. Before we start the lecture, are there any questions regarding the previous two lectures or the previous two self-studies? Because now we start kind of a different topic. Any questions? Good. Let me remind you that there will be an online quiz or an online test after the fourth lecture. And together with this online test, there's going to be a survey where you can evaluate how the course is going so far. I still have to come up with the questions for the survey, but it shouldn't take you more than five minutes at most. Multiple choice things. So what have we done so far? Before that, let me remind you again what the course is about. I will try to repeat this with the beginning of every lecture, because if you really can tell in two sentences what this course is about, you will have a much better idea what the purpose was, and you will be able to tell how each lecture fits into the grand scheme of things. So the course is about three things. It's about finding solutions, implementing solutions, and controlling solutions. Finding solutions again, topic of systems engineering, implementing solutions, topics of project management, and controlling solutions is a topic of system dynamics and non-linear dynamics. So far we looked at finding solutions, and there was a part of the self-study, the airport case, was about finding solutions and selecting solutions basically. And hopefully by now you appreciate the fact that there is no one best solution, no perfect solution to the problems that we're dealing with. We also looked at non-trivial versus complex problems, and why are there complex problems in the world. And hopefully this somehow in a way changes the way you perceive the world. It sounds like a trivial thing, no perfect solution, so obviously it's an obvious thing, but every time I think about it and I see how people jump to conclusions in judging, let's say, political doctrines or financial systems or society organizations, they just jump into saying, this is right and this is wrong, and I think it's much more complicated than that. So there is no best solution possible, and we can only hope to find some of the better ones. This is what we're trying to do. Also hopefully I managed to convey the message that it's good, this is a good situation. The fact that we have undefined, non-trivial problems with no clear solutions, this is a good thing because this kind of complexity is actually what leads to diversity, and diversity is a good thing. We like to have different products on the market, we like to have different choices. If you remember in the previous lecture there was a, or maybe the first lecture, there was this kind of a Mickey Mouse example of what will happen if everybody had the same preferences and they married the same person, went into the same apartment and stuff like that. So this is good. It's not something bad that we're trying to deal with in this course, but we're trying to see it as a good thing and see how we can make use of it. Alright, we looked at the problem-solving cycle as a tool or as a framework to find solutions and to evaluate and finally select solutions. Today's, let's say next week's self-study is still part of the problem-solving cycle. It's kind of a long framework to fit in just one self-study. So we've emphasized a lot on these iterations in the problem-solving cycle. This is not a sequential approach where you first do one, two, three and so on. There are a lot of iterations. If you come up with objectives and later on you find out that there is new information available, for example, which may change your situation analysis that you've done or task analysis, then of course you go back and you adjust your objectives. So in all steps of the problem-solving cycle there are iterations. And the problem-solving cycle basically consists of these three things, setting the objective, which as you remember consists of, first of all, before you set your objective you need to do your task analysis. You need to scrutinize the problem to know what exactly you're solving and then only you can set your objectives, search for solutions. You generate as many solution candidates as possible and then you narrow down in the selection phase. All right. An important thing also is that there is no algorithm that will do this for you. There is no algorithm that will go talk to the government, talk to the environmentalists about the airport, talk to the common public. There is no program that can do this for you. It's the task of the problem-solver. And this is also good because now your social skills, your mediation skills, your negotiation skills, they really count. And then there is nobody can teach you actually what to say and what to do in these situations. It's all up to you if you want to solve these kind of problems. And this is good for, let's say, it's an important thing for, let's say, engineers, strict engineers because sometimes it takes more than just pure technical competence to even analyze a problem. All right. Today we're moving away from this. We're going to the next step or next part of the course, which is implementing solutions. And this is in the task or in the domain of project management. Before we start with this, can I see who are the MIS students or MIS students? Okay. So probably you would be familiar with this kind of project management techniques. Have you been involved in project management? Probably. Okay. Almost all of you. So this is one of the things that is the challenge of this course to provide something new to everyone. I mean, I hope you would get something from this and that you can also actually contribute some insights from your own experience. So feel free to join in at any time. All right. So what we have so far or what we had so far are a bunch of a basket of possible solutions. You know, this is one of the last phases of the problem-solving cycle. And out of this basket, we have selected some of the better ones, these one here. So how we selected these better ones is part of the problem-solving cycle. It's actually part of the self-study for next week. It's a non-privileged thing to select solutions, but in general you need to have very good objectives on which to evaluate solutions and imagine that these better ones have been ranked and they're ranking as well. It's actually the last part of the problem-solving cycle. The ranking can only happen if you have good objectives. If you have, you remember probably the objectives should be measurable, quantifiable. They should not hint into any solution approach. And only if you have these kind of objectives, for instance, building a new airport is not an objective. You cannot measure success. You cannot evaluate solutions. So only if you have these kind of objectives, you can rank your better solutions. And now, once you have this, we need to implement it, obviously. But as you might imagine, a solution does not define the way to implement it. And basically, how can we go about this? We are going to follow the following kind of framework or procedure. First, we're going to try to break the whole problem, the problem of implementing a solution into subtasks. So your big task, building a new airport, for example, if that's the solution you ended up with, will be broken up into different subtasks. And we're going to use the term activity or steps, but these are little sub-problems that are individually manageable and that somehow are related to each other. We'll have a more detailed example coming up. But then once you've broken up your problem or decomposed your problem, provided you can do this. But if you really can't do this, then probably your problem can be handled in one go. I am very... I really cannot think of a situation where you have a big complex problem and you cannot break it into subtasks. So once you've done this, we need to evaluate which are the most important tasks or the mission critical tasks. For us, mission critical or critical simply would mean tasks that cannot be delayed without affecting the whole project length, right? So if you delay this task, your whole project is going to suffer. These are the mission critical tasks. Also, if you don't do them at all, your project is basically not going to be realized. We have this, but then the question is what is the right sequence of implementing these tasks? So should we start with the first one, second, third, fourth in a sequential manner or can we do some things in parallel? And the method we're going to see today, the critical path method, is going to allow you to kind of structure the interdependences between the tasks and do some in parallel if you can. And obviously during this whole time, we need to keep track of our constraints. The constraints could be anything. You might imagine time, costs, resources. We're going to focus only on time. Time is going to be our constraint today. But next week we're going to see quality as a constraint. We need to have a sufficient quality, for example. So a good example for such a decomposition of a problem is, for example, your master thesis. I think it's a perfect case when you can really define sub-tasks, which I mean you don't start writing your master thesis in one go, in one night. You have to kind of divide it into sub-problems. And then once you have this, you can start thinking, can I do everything in parallel? Can I do some things in parallel? For instance, in some cases you may do section one of your master thesis, which is literature research. You can do it in parallel with, let's say, section four, which is some experiments. So your experiments can be running at the same time you're doing literature research. But in some other cases, you need to do your literature research before you can even start thinking about your approach or your problem. So you see, this is the kind of projects or problems we're going to be concerned with. And there is a difference between a project and a process, which will become clear here. We're using the term project not in the sense that probably most of you are used to. A project for us is going to be a one-time endeavor, one-time task, something that has not been done often enough and you don't know what the optimal way of splitting the problem is. You don't know what it is. You don't know what is the best way to go about implementing these different sub-tasks. And this is opposed to the notion of process or business process. Business processes are highly structured sequences of activities and you can even have them automated. That's why information systems exist. But business processes are clearly defined. You know what you hope your ERP vendor knows, what the best decomposability of the whole process is, what the best granularity is for each sub-task. And then you just really go about without thinking too much. I mean, you still have to think, but not as much. But a project for us is, for example, Olympic Games, for instance. If you do the Olympic Games every year, then maybe it becomes a process. If you do, let's say, world championships every year, then maybe this will become a process. You will know exactly what to do at each single step. But for us, a project is a one-time endeavor and we don't know what the optimal decomposability is. Yeah, for our course, yes. Well, as close as unique as possible. So it's an implementation that you haven't done before. Okay, so yeah, that's actually good. So this definition of project seems to be universal. Okay, that's good. I thought that the difference between project and process in an industrial environment is somehow a little bit vague. In practice, yeah. All right, so this is a universal definition. I take this. It's not for us, it's for everybody. Thank you. All right, what I've shown you here is kind of the juggling act or the balancing act that you have to do. Quality is going to be, it's important, it's going to be a subject of next week's lecture. But you need to balance or let's say to respect your constraints and in most cases your constraints are cost and time and you need to fit in your scope. This is what we want from our implementation. To fit in the costs, not to take too long or to take actually as the time that we said in the beginning and to fit in the scope. The scope is somehow defined with the client. Normally you don't define your scope by yourself. The time and the costs, however, are things that you communicate to your client and in fact this is the most important thing that you will be asked. How much is it going to cost and how long is it going to take? You had a question? Scope would be, yeah, your expectation is too general. Scope would be, let's say, no, scope in that sense is before you define your project, basically what does this solution want to do? For example, if you build a new airport, the scope is building an airport. It's not making the environment around the airport a lot better or it's not about renovating the houses around the airport. It's just building a new airport. If you want to build a garage, for example, there would be an example about this. You want to build a garage. You don't want to paint your neighbor's garage. This is basically what you want to do with Scope. In general, in situations where you have clients, then you define this with your client. As I mentioned, we're going to focus on time. This is our constraint, not so much on costs. For us, costs would be implied somehow indirectly in time. If you can do the project in less time, then we assume that this also means less costs. But in general, this may not be the case. For us, it's going to be time. In that sense, we're going to focus on project scheduling. Basically, here it says focus on time. Next week, we focus on quality. What do we have to do? We need to calculate before you start the project. You need to calculate what is the minimum time that you need to realize this project. This is the most important question you will be asked. How long would it take you? A master thesis takes six months, so you can take this for granted, for instance. But in real life, let's say for a PhD thesis, this somehow is not always defined as rigid as that. In addition, as I said, we need to decompose this complex project. If I use problem, then today I mean project, in most cases. So if you have a complex project, you need to be able to decompose it into, as I said, manageable parts. This is a very fine balancing act, because if you define your tasks, your sub-tasks, to be too fine-grained, you will generate too much overhead in synchronizing the tasks, too much bottlenecks. For instance, if in your company you need to have some kind of paperwork done after the completion of each task, and this paperwork needs to be approved, and somebody has to say, yes, this task is now complete, if you have a lot of these very, very small tasks, you will generate a lot of red tape, a lot of bottlenecks. On the other hand, if you have too coarse-grained of a picture, you will basically not be able to calculate how much it's going to take you to do this big thing, how much it's going to cost you, and you will not be able to schedule anything. So it's a very fine balancing act between the granularity of your sub-tasks. It sounds like a trivial thing, but in fact it takes a lot of time. And then at the end, after we've done this, we've decomposed the problem, we've calculated how much it's going to take, we need to identify which are the critical, mission-critical activities, which are activities that cannot be delayed without affecting the whole project. What do we do? Yes, I saw a hand. No, okay. What do we do? We break the problem, the project, and then we somehow shuffle these sub-tasks together in a way that implementing them would be, let's say, the fastest. So we can do some things in parallel, we need to do some things in sequence, and we're going to have a running example with a big project today, and you're going to see how just shuffling the tasks around can save you time, which is not so... I mean, this shuffling is not so obvious in the beginning, but if you think about it and you come up with a way to do it, you can really save yourself some time. All right. Now, to do all this, we need to make a few assumptions. Here, in this course, we do these assumptions, but in real life you actually have to do this. What we need is the time. We need to know how much time it's going to take us to do each activity. All right? And this is just one bullet point, but in fact it takes a lot of time. There is uncertainty. You're not sure how long it's going to take, for instance, to do a literature review for your master thesis. Does it take you one week? Does it take you five days? Three days? There is uncertainty. So this is a non-trivial thing, as I mentioned. There is uncertainty. Then again, for complex projects, sometimes you're not aware of all the dependencies that can arise between the different activities. And this can only be found exposed. And then you need to go back. You need to change your project scheduling and then see what the new time is, what the new project length is. And with the method today, you're going to see how we can do this. You know, go back and change your initial plan and see how it affects your whole project. Before we start with the critical path method, is anybody familiar with the critical path method? Have you done anything like this? How are you familiar? Okay, you do the critical path method. Nice. Everybody else with work experience? Or a course? Which course? Oh, yeah. It's a no-brainer, yes. All right. Before we start with the critical path method, so you probably know all about the critical path method. You can do these calculations. Yeah. You give it a try. I'm sure you can do it. So before we start, just to give you an idea, project scheduling, I mean, it's such an important activity that it's no wonder you can find it in all of these application areas. R&D. In R&D, you can also think about your master thesis. It's one of them in construction. I would imagine it's heavily used if there's anybody from construction. You can say, if you plan a political campaign, for example, you also need to do this project as long as it's going to take you. As I mentioned, these big one-time events or almost one-time events like Olympic Games, they're different every time. They're done in different countries every time, World Championships and so on. And again, project is not equal to process. Process is a much more structured thing. You're going to learn a lot about processes in, let's say, managing information systems. For instance, buying a product, if your company or customer buys a product from you, the process of the customer buying a product until the customer gets the product is basically a process, sales or the purchasing. There is a mock-up example of what we mean by all this decomposing project and then identifying dependencies. I don't know who came up with this example, but this light has been used at least in the last three years. I guess for historical reasons nobody wants to change it, but it's a very simple and kind of easily digestible case where we need to build a garage. So this is our project. We've come up. This is our solution. For instance, the problem may have been how to protect our car, and then the solution is build a new garage, and then we need to build it. Of course, for all of these bullet points, you can come up with a lot more. For instance, for breaking down the project into sub-activities, here you see what is it about? About 11, 10, 11 activities mentioned, but the important thing to realize is that the number of these activities is unlimited. You can basically fine-grain as much as you want, but keep in mind this balancing that you have to do between fine-grainness and coarse-grainness. And then, again, we have dependencies. Again, you can probably come up with a lot more. Some of the dependencies you will not realize until it's too late. Then you have to go back and reschedule. For instance, some of the dependencies would be that you can only put the walls once you have the foundation sorted out, things like this. So it's a very simple example of having sub-tasks in their dependencies. That's what we need to do. And the first technique, which is a very simple visual technique, is the Gunt diagrams, invented by probably someone named Gunt. In your notes, you have the original paper from Henry Gunt in the early 20th century. So this is almost a little bit more than 100 years old. This technique. The idea is very simple. So this is in German, but all you need to know is that these are your activities like order materials and calculate delivery times and so on. So these are your sub-tasks. And here you put their duration. So who is using Gunt diagrams from the MIS students? Oh, in general, in industry. All right, do you find it useful? But you're probably using some specialized software like Microsoft Gunt diagram or something. All right, so let me ask you one question in a few more minutes. So what you basically do, you take a sub-task and you just put its length like this, right? The start and the end, and this is the amount of days it takes you to do this task. And it's a very simple visual technique. You immediately see how long each task is going to take. But there are two major problems with this. And basically my question would be about whether you've come across these problems. One is it's difficult to interpret or to understand all the dependencies between the activities. This very simple example, maybe you can do it. But if you have a project which has 50 or 60 sub-tasks and then you see a Gunt diagram which goes maybe for a whole page, it's difficult to see that maybe, for instance, task 4 can only be started after you've completed task 1. And then task 8 can only be started if you've completed task 4. So if you have like 50 tasks like this, it's not immediately visible which task depends on what. And related to this is evaluating the impact actually of a delay. So if you delay this task, then task 4 is going to suffer, task 8 is going to suffer. And if you have 50 tasks, you really need to do some work to understand how the whole project is affected from these delays. So have you experienced problems like that? It's feasible. But this resource allocation and this kind of complex decision-making is normally done in software. It's facilitated a lot by software. It's not that one person, as you said, one person sits and calculates everything by hand. So I would think that by using software you can make this work for most cases. And you can handle these kind of problems. But it's somehow, I don't see it built in into this approach. The technique you're going to see is CPM and the PERT at the end incorporate by design this kind of uncertainty in the duration of the tasks and dependencies between the tasks. All right. Let's start with the critical path method. I came across yesterday an article. Now, before I say what the article is about, let me say that it's not a journal article. It was just a kind of a presentation. So I cannot testify to the validity of what it says. But it said something really interesting. Probably you all remember what J.F. Kennedy said in 1961. For instance, I think it was 1961. Something like, I believe this nation should devote itself while landing a man on the moon. And then only, I think, nine years later or eight years later landed on the moon. So it seemed that NASA was using the critical path method to schedule this project. So this was a, I did not, I was pleasantly surprised by that. So what is the critical path method? The purpose or the idea is very simple. We represent the project as a network. And each node in this network is an activity or a sub-task. And each edge or each connection between two nodes is the dependency between these two nodes. So we have a network nodes and links between nodes, nodes or activities, edges or links or dependencies. And what we're interested in is the critical path. The critical path is simply the longest path through the whole project, through the whole network. And it basically tells you how much time we're concerned with time today, how much time your project is going to take. And all the activities that fall on the critical path, on this path through the network are activities that are mission critical and that cannot be delayed without affecting the whole project length. So this will, if you know these activities it will, you'll see how it's useful to actually do some resource allocation and compress the critical path. Yes, we'll be talking about schedule compression. So once you know your critical path, you can do some resource allocation and compress it. And we'll see with a running example how to do this. The critical path by design allows for dealing with interdependences in an easily manageable way and dealing with time schedules or uncertainty in your time duration. All right. And in your notes you can find a few references. I will put these references in the forum or in the literature section for this lecture today. So if you want you can read them. Now what do we need to do? The first part that I talked about, decomposing the project into sub-tasks, identifying the dependencies of each sub-task, we'll assume that it's already been done for us. Somebody did it. We're not going to do it, but please keep in mind that all these three activities, breaking down the project into sub-tasks, assigning duration and then coming up with their interdependences requires a lot of effort by itself. So it's not that this should be disregarded completely. You cannot do the CPM without having done this. You pretty much cannot do any project scheduling technique without having done this. But for us it's given. Somebody gave it to us. And then what we do is the following. Once you know the duration of each activity, you can calculate the start and the end dates of each activity and the so-called float, or in other words the buffer for each activity. So how much you can delay that activity without affecting the total project length. We'll distinguish between two types of buffers, but they're actually, in principle, they're slightly more, but these two types of buffers are the most important ones, the so-called free float and total float. We'll see that. So this is it. We do these two things. Start and end times of each activity and the buffers. Calculate the buffers. After that, once you've done all this, you have your network and you can see on your network what depends on what and how long it takes, then you can start optimizing things or drawing conclusions, but it's mostly about optimizing things. You can relocate resources. You can really see which task can be delayed without affecting the total project length. So you can probably take some resources from that task, assign them to a mission critical task. So the mission critical task would be accomplished earlier, and since your original task had a buffer, the total project length may actually become shorter. So we'll see a very nice example of that later on. All right. Now, those of you who went through the whole handout, you probably saw that there is one slide with a very messed up network. Did you see that? So, I mean, now you will have to go through it as I go through the slides. This is normal. It's not a printing mistake. It simply happens when you try to print this kind of latex overlay slides. You can find the whole network that I'm going to show you with all the slides, all the animation. Again, in the forum, I've uploaded it. Probably when you downloaded this, you also saw the other file. Did you download this other file? Not yet. All right. So those of you who downloaded it, you can just go through it. Okay. We have the following project. This is the project that we're going to be working on for the rest of the lecture. And the preparation phase has already been done for us. And probably the result of the preparation phase is this. Did you hear a bell, by the way? No. All right. Because we started a bit later. We have these activities, 13 activities. The names don't matter. Each activity has its time duration calculated, and we see the dependencies. And probably they look something like this. The first three activities do not depend on anything. So we can do them in the beginning. Let's say activity E is very short, but it depends on the completion of these two activities and so on. So this is your project that you need to implement. Now, the critical path method builds the so-called network. In fact, it's called precedence network. What this means is very simple. Each note... Okay. We'll continue after the break. So a quick reminder, this is our project. And the critical path method is basically building the so-called precedence network. Presented network is very simple. It basically means, as opposed to what you have in your notes, this arrow method, it means that each note is an activity. This is simply precedence network. It's a very simple notion. Before some previous versions of the critical path method, they used the arrows between two of these notes, the arrows to indicate activity. But for us, the arrows indicate interdependency and the activity is actually the note. All right. And just for completeness, each activity has a name, which we write on top of this rectangular box. It has a duration, which we write below the rectangular box here. And it has an ID number, which is probably mostly used if you want to put this in a computer. We're not going to be dealing with ID numbers, just names and duration. What is the procedure? You calculate the start activity, or you don't really calculate it. You create a dummy activity, which is called the start activity. It has a duration zero, so that every activity in your network is derived from the start activity. It's simply an artificial construct to make the network more or less contained. For example, this activity A, it will depend on your start activity, which is a dummy activity. And then you simply go through your list of dependencies, and you add notes, and you create dependencies between the notes. It's nothing more complicated than this. The important thing is, for us, the time would fly from left to right, right? So when you start building or creating your activities and linking them among each other, activities which come later in time should be to the right. Therefore, your arrows would be using directed graphs, so they would be arrows. Your arrows should always face right direction. They could go up or down, but never to the left. So you can't have a future activity depending on something that was completed in the past, not unless you want to start thinking about parallel universes and things like this. And this is actually a good way to find out if you've made a mistake, because I can guarantee you on the exam, I can tell you right now, on the exam there is going to be a question of a critical path method, and it's going to bring substantial points, 10 points out of 60 maybe. It's not enough to pass, though, so... I mean, you need to... I think, 40 maybe? 40 points. So when you calculate a critical path method and you draw the arrows, if you see an arrow which goes to the left, that's a mistake. I want you to pay attention to this because maybe in some people are used to actually reading from right to left, and then for them it would be slightly counterintuitive to start drawing things from left to right. I don't know. All right, and then we create, just with the start activity, we create an end activity or finish activity where all the... which is basically executed after everything else. It's a dummy activity again with duration zero. It's just for consistency reasons. You'll see exactly what I mean by that. All right, so if you take this graph, if you take this project and you draw this graph, or this network, you get this, all right? We have our dummy. We have our dummy start activity here. If you remember these three activities, A, B, and C, they do not depend on anything. We can do them in the beginning. So probably this is a kickoff meeting, for instance, and B is something related to that. So basically all these activities depend on the start, on the dummy, but since this is dummy, it's really not a problem. And we can do them in parallel, right? There is no dependency between A, B, or C. So we can do them in parallel. You can see the duration here, four, two, and three. And you do this with all the other activities. So for example, D depends on A. It has a duration two. E depends on B and on D, right? Let's see. E depends on B and D. D and B, and it has duration one, and so on. So this is simply the network constructed from our table. From our preparation phase. Yeah. So for example, K depends on H and on E, and you see all the arrows go to the right. They can go down vertically down, vertically up. There is no arrow here vertically up, but you can imagine if J was here, then this arrow would be like that. But never to the left. All right. So this was the first step. Calculate the duration of each activity and their interdependences. Now we need to calculate having this. We need to calculate end times and start times. And we'll distinguish between two types of start and end times. We'll distinguish between earliest starting date. So this is, as the name suggests, the earliest that you can start to give an activity, ESD, and the earliest finish date. So when you start the activity, you add the duration, you get the earliest finish date. What is the soonest that we can finish that activity? In addition to that, we'll look at the latest started date, and this only makes sense having latest started date. If you allow for delays, right? If you have no delays, you don't need this. But since we're going to have buffers and we're going to have delays, we'll use the latest start date, LSD, not in the psychedelic sense, but in the sense of latest starting date. And this is basically what is the latest that you can start to give an activity. It's self-explanatory, and we have the latest finish date related to this. And just as an example, we have the activity A. Imagine that the earliest starting date for activity A is here. You add the duration of this activity, which was 4, and you get the earliest finish date. And since activity D depends on activity A, the earliest that you can start activity D is when activity A finishes. So it's here. And then plus duration of activity D, you get the earliest finish date of activity D. Now, if you delay activity A by this much, you get the latest starting date of activity A comes here. So if A has a big enough buffer, you can probably delay it without affecting the total project length. Latest starting date is here. You add the duration, latest finishing date. And now this line here, there should be a line here. For D, so latest finish date. The latest starting date of D is then here. So just add a line on your handout. But it's, yeah, there would be a... No, I mean, this is the latest finish date of A, if you delay it. And that's when you can actually start D, because it's finished. So this is the latest starting date of D. It might, it might. But for us, D only depends on A. It doesn't depend on any other activities. I mean, I don't know, is it? Yes. Yes, D only depends on A. For example, with this guy here, it's not the case. All right. So how do we calculate these times? Early starting date and earliest finishing date? Well, we do it in the following way. We have these two passes, forward pass and backward pass. Forward pass calculates the earliest times and backward pass calculates the latest times. So let's have a look. We go from left to right. This is the forward pass. They give us the ESD and the EFD. So what is the earliest finish date of an activity? Well, it's simply the earliest starting date plus a duration. Right? It's activity J, early starting date of J plus duration. But what is the earliest starting date of an activity? Well, if the activity does not depend on anything else, then the earliest starting date is zero. So you can start this activity in the beginning. But if it depends on something else, then you look at all the activities that your activity J depends on, and out of all these activities, you take the one which finishes the latest. All right? So out of all the activities, I, all the I, so J depends on all these activities I, you take the maximum of their finishing times. All right? So let me see if there is an example here. We'll come to this example later on. But this is the idea. Out of all the preceding activities, you take the one which finishes the latest. And that's your earliest starting date. Yes, so I is a predecessor. Now, we've calculated the ESD, EFD. We'll do that in a running example. We do the backward pass to calculate the LSD and the LFD. The latest starting date is obviously the latest finishing date minus the duration of the activity. If your activity is the last one in your project, then obviously the latest finishing date is the total length of the project. Right? This is the last activity that you do. However, if it's not the last activity, then you look in all activities K that follow your activity J, you look at all these activities, and you take the one which starts the soonest. All right? So out of all the activities that follow, that succeed I, J, sorry, you take the one with the minimum latest starting date. All right. This is a kind of a, it may be difficult thing to remember, but when you see a running example, it would be very easy. So now having the ESD and the EFD and LSD and LFD, we can update our notation a little bit. This is the activity. Its duration is written below. The earliest starting date and earliest finishing date are on top, and the LSD and LFD are below them. And here we have the two floats. Don't worry about these floats too much right now. We'll calculate them. And obviously, when you, so what is, well, the answer is given, but the critical activity now that we have these times would be those activities that cannot be delayed. This is by definition. Right? So if you delay them, your whole project is going to be delayed. In that sense, the earliest starting date equals the latest starting date for these activities. They cannot be delayed. Same for EFD and LFD. So again, during the exam, if you see activity on the critical path for which either of these conditions holds, so the earliest starting date equals the LSD, but not the end dates and vice versa, then there is a mistake somewhere. So it's a very easy way to check these things, because as you might imagine, you won't have infinite time during the exam to calculate the same thing over and over again. Yes? I don't know if it's a standard, but this is the notation we're going to be using in this course. Yes? No. Well, kind of yes, but it allows for modifications. Let's say if... Yeah, indirectly, yes. Indirectly, it allows delays through the use of these buffers, but you're right. The uncertainty concept is not inherent by design in the critical path method. You'll see the pert in the last slide, this approach has uncertainty incorporated somehow. But with this method, what you can only do is to allocate big enough buffers if you're uncertain. So let's go. Now, this is the point where you see a slide which looks like this. It's messed up. Don't look at it right now. If you've printed the additional PDF that I uploaded, you can look at it now, otherwise just look at the slides. What is that? Yes. Who was doing the critical path method? You were doing it, but there was somebody else? Yes. So what is the earliest starting date and earliest finishing date of the activities A, B, and C? These are the first activities. Yes. What is zero? The earliest starting date. What is the earliest finishing date? Yes. Yes. So it's very easy. Zero, four, zero, two, zero, three. It's a free float and total float. I'll come to this. Free float. Free float. Yes. After this example, we'll look at this. There should be here. Free float, total float. But for now, it's zero. All right. So what is... Now, a question. What, for which activities, with calculated A, B, and C, for which activities can we calculate the earliest starting date and the earliest finishing date now? I agree for D and I agree for F, but why E? After F, D. Yes. So... DNF. Exactly. DNF. And what is the DNF? Yes. Does everybody agree with this? This is right. Four, six, and three, seven. And now we can calculate G, right? We can calculate G. We can calculate H. And we can calculate E. And now the question is what is the ESD, the earliest starting date and latest, earliest finishing date for E? Yes. What is six? The earliest starting date of E is six and earliest finishing date would be? Seven. Seven. Yes. Seven. Seven. Oh. Yeah, okay. This is slightly misplaced. Six and seven. Seven and ten. Right? We can only start H after this one finishes. Six and ten as well. You know, so this is the concept. This is what I told you before. If... So you take all the preceding activities, all the preceding activities, and you take the one which finishes the latest. It's this one. Right? But basically this equation means you take all the ones that finish the latest. Sorry? Yeah. Not all the ones but the one. The earliest finishing date, yes. No, we haven't calculated the latest things now. No. These are zero because they're not calculated. We're doing the forward pass and then we go with the backward pass. Just like on the exam. All right. Yes, I mean I'm trying to give you hints for the exam. Right. So we can calculate now J, K and I. Hopefully it's clear. This is 10, 15. Now J. This is seven but this is 10. So this one finishes the latest. 10, 13. It makes sense, right? You can't start this activity at time eight because this one has finished but not this one. It makes sense. And then L, 15, 24, 16, 21 and M. And finally the last activity, you just do the same calculation. Out of all preceding activities, you take the one which finishes the latest, 24. So your whole project length is 24 time units. It's important that your time units are consistent across the different activities. So if this is days, this shouldn't be minutes. Something like that. But these are time units. Now we do the backward pass. What do we calculate with the backward pass? Latest starting date and latest finishing date. So what is the latest finishing date for, let's say for activity L and for activity M? Yes. What was the algorithm? Out of all activities which follow our activities, we take the one which finishes the earliest. So 24, 24, latest starting date. And obviously the latest, sorry, latest finishing date. And obviously the latest starting date would be 15 minus the duration and 19. This is the procedure. So now we can calculate i, the latest finishing date and starting date for i, for j and for, no, that's all. No, for k2. So can somebody give it a try? Latest finishing date for i, j and k. Yes. This one would be 15 and this one would be 19, right? 10, 15, 12, 15, 13, 9. And now we go with the backward pass. We calculate the latest finish, the latest start. We do this like that. And now, well, yeah, I already showed you the answer to my next question, but now we have the earliest starting dates. Yeah. We have the earliest starting dates for example, this one. And remember the critical path was a sequence of activities which cannot be delayed. So early starting dates and early finishing dates for these activities would be the same. And you can identify these activities, a, d, g, i and l, right? 0, 4, 4, 6, 6, 10, 10, 15, 15, 24. This is a critical path. Nothing can be delayed here without affecting the total project length. But this activity, for example, e, right? It can be delayed, for example, by five units, right? Five units of time without affecting anything else, right? So on e, on activity e, we have j and k which depend on it, right? j and k. This starts at 12, this starts at 13. We have a huge buffer here. And now this is where this uncertainty comes into play. If you're not sure whether you can really fit into these schedules, well, you can take some resources from here. Since you have such a high buffer, you can allocate them to one of these activities, you know, just in case. You cannot accomplish them. Now, this was a simple example how we calculate the critical path, not the complete one, because we still need to calculate the exact buffers. What I've just calculated now, five, is the so-called free float. Free float because we, or free buffer. Why free? Because we get it for free. If we delay this activity by this amount, nothing is affected, right? So no delays on any activities would be, would be as a consequence. So we get it for free. That's why it's called free float. On the other hand, the total float, and the free float we write, if you remember, we write here. It's just a convention. The total float now is, we can delay, so the total float would, would mean that the subsequent activities would be delayed, but within their respective buffers, right? So you would not violate the latest starting dates of any activity. You can violate the early starting dates, but not the latest starting dates. In other words, the buffers of all subsequent activities will be, will have to be used. But the total project length may or may not be affected. This is not, with the total float, it's not always the case that the total project length is unaffected. With the free float is the case, but not with the total float. So this is how you can think about these things. The free float, we get for free. Nothing is affected. The total float, we need to use the buffers of the subsequent activities. Okay. Yes, and this is exactly what I said. Exploiting the total float can result in delay for the whole project. We can use the buffers for the variety of things that I mentioned. You can deal with uncertainty by just preemptively allocating buffers to activities, or you can reshuffle resources. And we'll use that example to see, to see how resources can be reshuffled. Now for instance, let's calculate the total floats and the free floats. We have activity K, we'll deal with activity K and J. K follows J. If you look at the network, I think that's the case. No. Well, just imagine that K follows J. All right. And we have activity J starts at 6. Early starting date of activity J is 6. Early finishing date is 10. Obviously duration is 4. Latest starting date and latest finishing date for J is 11 and 15. And we have for activity K, E is the E of D here, 12, 17. Now, and the latest starting date for activity K would be here and so on. So what is the free float? With the free float, no other activity, no subsequent activities are affected. In other words, the earliest starting dates of any subsequent activities are not affected. So what is the early starting date of K? Well, it's 12. So this is where the activity K starts. This is where activity J ends. So we can delay our activity J by this amount without affecting anything. So this is the free float. We get it for free. And now you can already see, and this is what it says here, but now you can already see another check that you can do during the exam. If you calculate the earliest finishing date and you add the free float that you've calculated, hopefully correctly, you should get the earliest starting date of the activity that starts the earliest. So let's have an example here. Okay, well, we can only have this example after we've calculated all the floats for the network. So I'll come back to this. But if, yeah, it's a check you can do in the same way, what was the total float? It's the amount of delay that will affect the subsequent activities and you have to use their buffers. In other words, you can affect the earliest starting date but not the latest starting date of the activity that follows. So this is the amount of delay that we can have, the total float. And another check you can do is EFD plus total float should equal to the latest starting date of the activity that starts the earliest. And this is the formula. This is basically my thematic notation for the previous calculation. The free float of an activity J, if the activity doesn't have any other preceding activities, right, then it's simply the critical path minus the earliest finishing date. If it does, then we take the activity which starts the earliest and we subtract the earliest finishing date. And the total float in the same way. And now by comparing these two equations, you can see they're almost the same, right? This one is almost the same as this one with the exception that here we have ESD and here we have LSD. By definition, the earliest starting date of an activity, K, cannot be larger than the latest starting date of this activity, right? They're only equal if that's on a critical path. In all other cases, it's smaller. So what you can conclude now is that the free float is always smaller or equal than the total float, right? Just by comparing these two things. And then we have interfering float but you don't need to concern yourselves with this. We're going to be using only free float and total float. So let's go about calculating things. I think first, yes. So first activity E. What is the free float? Free float is here. And what is the total float of activity E? I myself, I don't know. I have to calculate it but I trust that you will calculate it correctly. Let me see. Yes. Right? So what was the free float? It's the amount of delay that will not affect any succeeding activity. This is the succeeding activities, J and K. This activity starts at 10. This one also starts at 10. Therefore we can delay that thing with 3. Right? We can delay the 7 plus 3 would be 10. So we have a free float of 3. And in the same way, the total float should not affect the latest starting date of any subsequent activities. So we should not affect 12. And therefore we can delay that thing by 5. 7 plus 5. So that's 3 and 5. And now we can make our calculation that I showed you here at this little check. EFD plus free float should be equal to ESD and EFD plus total float LSD. And that's the case. 7 plus 5 is equal to 12 and 7 plus 3 equals to 10. So very, very easy calculation. Very easy check. And then following this whole procedure now we can calculate what is that. We can calculate activity B. Right? What is the free float? We don't want to violate 6. So 2 plus 6 is 4. And then we also don't want to violate 11. 2 plus 11 is 9. In the same way. Right. So what is the free float of H? Well, we don't want to violate 10. We don't want to violate 10 and 10. But this one finishes at 10. The earliest. So there is actually no free float. We don't get anything for free here. And then in the same way we calculate everything else. And now this is the solution that would give you all the points in the exam. Right? So if you produce something like that. Yeah, so obviously for the critical activities we don't have any floats. They're all zero. You don't have to write them. But for all the other activities we have floats. 3.5 and so on. What do you mean the final lines? Which final lines? These ones? No, on the exam if you don't draw this or this that's still okay. No, you don't have to do dotted lines or stuff like this in the exam. Aha, no, no. Even if you draw this without, I mean, most likely what I've seen so far. Is that it never looks like this on the exam. It looks more like this. So you have like arrows going like that. But the important thing is that you say something like this. This is the critical path. And sometimes by chance I think you manage to get the right critical path. But not the right values for the durations or the buffers. You need to do that to get full points though. All right. Now we come to the topic of kind of shocking this approach by uncertainty or by delays. First of all, how can changes affect the schedule? In other words, imagine now that activity J is replaced by a more efficient activity, which takes one time unit to complete. Remember, J takes four time units to complete. So we kind of have a saving of three time units. What do you think the impact on the overall project will be? So we just saved three. Would it be more than three? Would it be less than three? Would it be three? In that case, no, but it could be less. It could be less. I would be very surprised if it could be more. I think it cannot be. But it could be at most three. And in that particular case, it's less than three. The reason is, we'll calculate it, but the reason is that the savings that you do, some of them, one time unit in general, is somehow lost in the buffer. You'll see how it looks like. So let's make the calculation now. Well, it's already made, but I highly recommend that you do it at home by yourself, because this is not a complicated thing to do. It's very easy calculation. But if you have to do it fast, you need to have practice. And all the practice that you need is basically doing this. It's no additional books or textbooks or stuff like that. So if you just calculate the new critical path, the new buffers of this network now, you get that. Okay, and now your critical path looks differently. Your critical path is here. C, F, H, J, L, and that's the end. And if you calculate, the total project length is now 22. 22, so we save two time units instead of three. So this is a non-intuitive result. Why it happened like that? But this is the effect of changes in the duration of the activities. And now, as I mentioned in the beginning, we can use this, so after we have this, what do we do? We start analyzing it. How can we compress the whole schedule? How can we take some buffers and take resources from an activity, so use its buffers, but take these resources and use them for critical activities that could be accelerated. And this is exactly the following situation in the slide. The situation is the following. B and C are independent. So the current situation, B and C are independent, it could be performed in parallel. Let's see if that's the case, yes. They could be performed in parallel. C, however, is a critical activity and falls on the critical path. So let's somehow try to optimize things a bit. What you can do, see, B has a huge buffer, B has a buffer of four that we get for free. So we can take all these resources and put them into C. And this is the example here. Maybe the duration, so you take, how much you take? Well, yeah, you take all the four resources, all the buffer, you put it into C and now maybe your activity C will not take three time units to complete, it will take one time unit to complete, as in this example. But now we change the sequence of activities in the sense that B now can start only after C is completed. Before they went in parallel, but now we just impose this restriction, B can only start after C. Well, this is, for the purposes of this example, that's the number. But obviously in a real-life situation, it's context-dependent. Yeah. What you need to do now is again go to the first stage where you evaluate the duration of each activities. But in general, if you can do the original project preparation, you can calculate the duration of the activities. Chances are that you can also calculate what happens if you increase the resources or decrease the resources. But yeah, for our example, it's given. So what happens now? On first glance, we've created the bottleneck, right? Before we could do two things in parallel, but now we have to do them in sequence. Yes. Okay. The new network now looks like this. C would take only one time unit to complete because we put a lot of resources there. B can only start after C now. See, there is this dependency here. And A is again the same A. Again, for your own benefit, you can calculate the new floats, the new timings for this network. And you will reach the conclusion that this is your critical path now, and we gained a further reduction of one. So 22 to 21. So just by using the free flow that we get from the nature of the project, we got an additional one. So this was the schedule compression that I talked about. All right. Why is there what? Nice. I didn't know that. It's a mistake. Let me write that down. Is everything else right? A, D, G prime, I, L, yeah. So there shouldn't be an F here. A little hint how to deal with uncertainty with the CPM. You can try to identify the so-called almost critical activities, or how are they called? Like near critical activities. These are activities with very low buffers. So any unexpected delay would completely use these buffers, and your whole project is going to be delayed. If you identify these activities, what you can do is to treat them like critical activities, which means you try to put more resources there. You try to make sure that they're never delayed. Basically, treat them like critical activities to somehow try to deal with uncertainty. In the same way, you can artificially allocate buffers for critical activities. By definition, critical activities don't have any buffers, but if you think about uncertainty, then you can be a bit more flexible with evaluating the duration of these critical activities. So this is kind of artificially incorporating a buffer into the duration of this activity. If it's a critical activity, very important for the project, instead of duration five days, maybe you put seven days, just in case something happens. So this is how you can try to deal with uncertainty, but this is one of the big deficiencies of this method. It doesn't deal with uncertainty. And this concept or this framework that we're not going to be using in this course is just for... It's going to be in the self-study, but not in... Yeah, so let me just finish that slide. It deals with uncertainty in the following way, the project evaluation and review technique. The concept is very simple. You create three types of timing evaluations for your project, for all the activities. Optimistic case, pessimistic case, and what was it called? Most likely case. Right? It's kind of a... Yeah, it's a no-brainer, but that's what you do. In the optimistic case, in the pessimistic case, and then some realistic case. You do three different networks, three different critical paths. There would be maybe completely different networks with completely different duration of the whole project. So you end up with three different durations. And then by this formula, which honestly, I don't know how it was derived, you calculate the estimated time for the whole project based on the optimistic, pessimistic, realistic case divided by six. And then you get the most... What is it? The estimated time. So this is how you can deal with uncertainty, but again, it's up to you as a problem solver to define the right level of uncertainty. What is the optimistic? What is the difference between optimistic and pessimistic? You don't know. And these are the questions. Please do this. It's going to help you a lot for the exam. Calculate the CPM for that project. And vote. I'll see you next Tuesday. Thank you.