Please find a transcription of the audio portion of Eric Uyttewaal’s Forecast Scheduling for Real-World Projects webinar being provided by MPUG for the convenience of our members. You may wish to use this transcript for the purposes of self-paced learning, searching for specific information, and/or performing a quick review of webinar content. There may be exclusions such as those steps included in product demonstrations. Watch the complete webinar on-demand at your convenience.
Forecast Scheduling for Real-World Projects (Project Online 2018)
Presenter: Eric Uyttewaal
So we’re going to talk about my new book Forecast Scheduling 2018. Of course 2018 is not an official release but since Project Online is regularly refreshing, updated, we also have to publish our books more regularly and that’s why I decided to write a version for 2018.
So I can skip the intro slide. This is what we’re going to talk about in more detail. It all comes from the textbook “Forecast Scheduling”. I’m basically going to give you an executive overview of the book and a highlight some nuggets, lift them out of the book and present them to you. And this is the agenda: just two principles led to 86 best practices for which we created a checklist in the summary chapter of the book. Some of the things that we did based on those principles of dynamic scheduling and forecast scheduling, we looked through all the features of the tool and we identified the features that are important. So, how to capture promised dates without killing the model. We’re going to use constraints there, see a better feature for that. Minimize your effort on scheduling…of course creating a huge monster of a schedule that is very maintenance hungry is not such a great idea. Then we’re going to talk a little about critical path and how to make it easy in Microsoft Project. Then updating the schedule.
What is a project schedule? Really back to the basics of for a bit. People understand the schedule as a list of things to deliver and their due dates. So essentially this is kind of like the target schedule and people will to want to keep your schedule static. Technically speaking, this is kind of like the baseline because it captures the target dates of the schedule. This of course, this type of schedule, does not require an advanced scheduling application like Microsoft Project. This type of schedule could easily be created in Microsoft Word or Excel. So what do we really need Microsoft Project for? We need Microsoft Project for this particular reason. To explain that properly, we’re going to compare what we do to what doctors do. Doctors have a patient, we have a project. They have a target body temperature, 37 degrees Celsius or 98 degrees Fahrenheit. We have this list of things and their due date. But now what we need is a measuring instrument, thermometer basically that gives us constant feedback. This blue dynamic model here is really what we’re creating here with Microsoft Project. So, I often say that in Microsoft Project, we really create the thermometer. To constantly measure the health of the project. So what is a great schedule? A great schedule is basically a valid, dynamic, and robust model of the project to forecast the project. Of course it needs to create valid and accurate forecast. The schedule needs to be dynamic. It needs to be a schedule that updates itself as much as possible. It also needs to be a robust model and it’s only robust if it responds to a variety of changes. We’ll talk more about what you need to pay attention to when you want to create a robust model. And of course a model is not a model if it’s not a deliberate and smart simplification of the reality. And really the main benefit from scheduling is getting forecasts. Forecasts in terms of duration or finish date of the project. But perhaps forecast in terms of workloads and forecast in terms of cost. And of course we’re supposed to do that continuously. That would make a perfect project thermometer. These are the two principles that I dreamt up a long time ago. That’s basically led my thinking ever since. First, the principle of dynamic scheduling. It makes the schedule very easy to maintain because as the principle says, if one thing changes in your project, ideally you should only have to update only single cell in your schedule. Your scheduling engine should do the all the hard work for you…should recalculate the rest of your schedule automatically and show, again, a feasible way for your project.
The second principle is the principal of forecast scheduling. Why don’t we try to forecast with the schedule itself instead of coming up with all kinds of interesting performance measurement metrics and forecasting algorithms. If you basically keep the remaining work in the future, then the schedule will forecast most of this by itself. So visually, this is how the principle of dynamic scheduling would look like…one thing changes and the scheduling updates the rest of the schedule and this is how visually the principle of forecasting would look. As you can see, there is some light blue to the left of the status date. It shouldn’t be there, that’s work that still needs to be done. It should be brought to the future. I’ll run the animations a few times. So light blue to the left of the status date is not a forecast schedule. And dark blue, by the way, to the right of the status line is not a forecast schedule. If there’s dark blue here, it needs to be brought back to the task and then through the dependencies of the forecast would be pulled back as well. Basically, with these two principles, I started looking at all the features in Microsoft Project online…specifically for this edition of the book. And the book now has a checklist in the summary chapter, 86 checks. Here you see just a subset of them. Here is 5.3, are all the “starts” linked up. So, we even automated that checklist and our forecast scheduling application that basically sets itself up as a checklist on the right hand side of the screen. And it can start highlighting violators in the schedule so you could easily repair those. I’ll do a little demo with this a little later on and that has also led to a certificate of competency because if people will submit a schedule to us that meets those criteria, meets the checklist, then they get this certificate of competency. Once they prove to us that they’re really applying those learned skills in their own projects then they can earn an additional 20 PDUs for PMI with this certificate of competency. Let’s step back for a second. When we get involved with clients, the first question we ask a client is “what are you really trying to model with Microsoft Project?” Is it the time (i.e. duration) of the project? That just requires a very simple model of the project. We call it a “4D-1D” project. It needs to have all the deliverables, durations, dependencies and deadlines but you shouldn’t enter the start and finish dates. That’s what 4D-1D is. Or a client would like to model the workloads. In order to do that, you need to add more detail to your 4D-1D model. You need to add the so called “5A’ items. So you need to flesh out all the deliverables into activities. Model the availability of the resources, efforts on the assignments and or the units on the assignments…that would create an accurate world model. Now you can also say “hey, is the schedule that we dreamt up, given the limited resources that we have, is it also realistic?” That’s the main benefits you get from a workload model. The cost model can be created from the workload model by adding the “6C”s. You can even add a budget, charge accounts but at least what you should do is add the charge rates. The cost and material resources. When the costs are accrued and if their rates escalate, increase over the years. So these are the three main purposes that you can have in terms of forecasting…out of forecasting the time for a project, forecasting the workload and the time because if you built the workload model, you can do both. And the highest level which has forecasting the cost, workload and time of your project. Now of course the highest level has the most detailed schedule. Let me show you how these schedules look. So here you see a time a model. Actually, as you can see it has all the “D”s, it has all the deliverables for the renovation of a family home. And with these things that you would need to create, perhaps you even need to have water and a septic system. And tear the roof out. As you can see, all the components of the renovations are there. That’s what you need to have, you need to have the deadlines, durations and you need to have the dependencies. As you can see, this is a 4D minus 1D model. I’ve made it even a little prettier here, by entering the deadlines and calculating the time contingency to each deadline date. What’s the deadline here? You can see it’s 10 days, 50 days and 74 days. For the project, as a whole, that number needs to be large enough. As you go down, that number should increase in a healthy schedule. Because of course, with Project as a whole, you get the most unforeseen events. So this is a very tiny model, as you can see and you can start updating it now. You just need to update these durations. You get feedback from the model if you’re still meeting the deadline. If I increase this one to 65 days and it’s still meeting the deadline but if I increase it to 80, you can see the deadline is missed. You would see it in the timescale very clearly but also in the indicators column because a red flag is raised there. You can see the deadline is not met any longer. So this simple time model would do the trick for you. Let me pull up the workload model. Basically for the same type of renovation project. Here you can see the same deliverables but now the activities added to it. So I added the 5A. As you can see, the assignments and all the resources are there. The resource availabilities, the assignment units and very carefully I’ve assigned the resources to the task. In order to get 3 quotes, I just need to meet with 3 vendors for one hour over a 2-week timespan, or so. So that’s why you only need 3 hours of effort and that’s why the assignment units has been set to a very low percentage. But this is as you can see is a very accurate model of total workloads. Now with this model, I want to see if the workloads are reasonable. So you can see that in the resource usage view on the month-by-month basis, for generic group resources, you want the total workload to be within their capacity. For individuals, you want the workloads on a month-by-month basis not to be greater than 160 or so hours. You can see 230 hours, that is too much. That definitely should be addressed and that could lead to some delay in the project when you start addressing that. So that’s the workload model. As you can see, you get great feedback on that. Then, the cost model would look like this. Now we added the 6Cs…all the costs, all the different types of resources. As you can see now in the workload model, you only need these work resources but of course in a renovation project, you will use a lot of materials. They need to be in the resource sheet as well as any other types of costs; building permits and other things and here you even put the budget cost in there. So that all needs to be there in order to get total cost on the project. This cost is now dynamically modeled. If I change the rates or if I change the amount of effort on a task with an hourly rate, then you would see that cost increases immediately. So you can see the main benefit of a cost model is “are we still within the budget, yes or no?” So this view will show you that. If I roll it up to its highest level, you can see that the budget for labor vendors is 105,000. You can see that I’m already going over it because this is a current tally of all the efforts currently assigned. The materials are within their budget, that’s pretty good. You can see that the fixed cost are going over. You get feedback from this model very clearly if you’re staying within the costs of the project.
All right so that’s a cost model and that brings us to the next agenda point: “Should you capture the promised dates?” It’s all too easy to actually kill the dynamic nature of the model and it will stop forecasting. Basically, we’re saying you should only enter the 4D minus 1D. You should always have the start and finish dates being calculated by Microsoft Project. That’s really the best thing it can do because then it really is a project thermometer that gives you constant feedback on if you’re still on time, yes or no. Let me show you what a lot of people do. A lot of people do this…they have this milestone, it’s currently forecast on the 19th of December. A lot of people capture the dates that they promise with a feature that they seem to find quicker than the feature that they should be using. So they create a no-later-than-constraint on the 24th. It may very well cause a schedule conflict and that’s exactly what schedule constraints do because constraints really constraint the scheduling engine and will therefore be able to create a schedule conflict. Now you can see here that this calendar icon appears in the indicator column. A Finish-No-Later-Than constraint has been set. Now this is how many people do it but this is what they get. If I push out the schedule now and I continue to update it in this very simple way, then you can see that dependencies get bent out of whack by these hard constraints. So this milestone is now constrained to the 24th. Of course we want to be done by Christmas. But the rest of the project forecast, probably still forecasts that you’re going to be done the 28th. Of course you can see very clearly, that will never happen because even just this future task will barely make that 28th. As you can see, this second part of the schedule is not scheduled and forecasting properly anymore. So what should you use? You should not be using these constraints. We strongly recommend against them and you should use another feature instead that’s right above it which is the deadline feature. If you use the deadline feature instead, you can see the backend of the schedule starts the forecast again and properly forecast it. And now forecasts that it’s going to be well into January before this project is done. All right so use deadlines rather than constraints. This allows you to keep the model alive. Summarize here on this slide…deadlines don’t kill the forecast but constraints typically tend to. Constraints also tend to make your schedule a lot more maintenance hungry and that’s what I’m going to talk about now. You don’t want your schedule to be maintenance hungry, you don’t want to use constraints, you don’t want to use manually scheduled tasks and you definitely don’t want to use Excel because then you create a schedule that is very, very maintenance hungry. You cannot expect continuous forecast from a schedule in Excel or that’s entirely manually scheduled. So how can you minimize your effort on your schedule? Well, first of all, you should pick the right things to add to your model while still keeping it lean and mean. And typically most people have the choice to capture phases or deliverables in their schedule. I’ve added a code to this, A and B. Or some people try to do both, capture phases and deliverables in the schedule and that would be answer C. What I would like you all to do is enter in the text chat what you typically enter in your schedule. Phases, A, deliverables, B or both enter a letter C into the text chat. I cannot see the results of the text chat but Kyle would summarize what he sees coming through the pipe. So if you typically put phases in your schedule, enter A into the text chat. If you typically enter deliverables into your schedule, enter B. So Kyle, you get some responses already?
Kyle: “We have very few A’s…I would say the majority is B’s and C’s. Probably the largest majority is B’s”
That is excellent, that is what we would like to see because deliverables are already creating the verifiability in the schedule because deliverables, as per the definition, are measurable, verifiable things that are of value to a client. So they have a client as well. Those are basically the 3 characteristics of a deliverable. They must be verifiable, they must have a client and they must be of value to the client. That’s what creates a lot of insight so you should have at least deliverables. Phases are kind of like a fuzzy and cozy concept to just group items under a summary task. But they do not have much added value in and of themselves. You can see in a small project, you really have to choose either phase or deliverable then we strongly recommend you choose deliverables. Now phases are typically formulated with the –ing ending: researching, selecting, contracting, remodeling and you just have to ask, what is the output, what is the thing of value that this phase has created? Well, that’s of course the list of requirements. That’s how you can convert a phase oriented into a deliverable oriented breakdown. So this is what we typically like to see in the WBS…component deliverables, whole set of component deliverables and a whole set of supporting deliverables. The component deliverables of an aircraft are of course all physical and tangible, things that the aircraft consists of…the airframe, the propulsion, the Nav./Communication versus supporting deliverables that do no travel with the airplane. Those are the test reports and the whole support infrastructure…spare tires need to be at the airport, so where the airline flies and of course there needs to be some trained staff. So this is typically how a deliverable oriented breakdown structure looks like. As you can see, very minimal and therefore a true mode. This is what minimizes the effort in their schedule, focusing on these deliverables. But then if you go to workload model and you add the activities to it, how do you know you’re going to the right level of detail with those activities? Some deliverables may need 2 or 3, perhaps even 4 levels extra. Some organizations have approached this question, what’s the right level of detail too simplistically because they say level 3 or level 4. What we do is we developed this relative measure of the 1%/10% rule where we basically say that the duration of the activities should be within 1% and 10% of the project duration. Specifically, the durations of the activities. So if you have…if you know in advance that you’re in a 3 month project, you have, give or take, 60 business days, that means basically that 1% is 0.6 days. In other words, the minimum duration for the activity should be half a day and the maximum duration would be 5 days. So while you’re creating activities, you know right up front already if you’re at the right level of detail. Now I can also show that in Microsoft Project because basically when you know you’re in a 67 day project, you can start counting these durations for the activities, not for the milestones so obviously not for the summary task. Just for the activities, to see if they’re at the right level of detail. But the book comes with a whole set of filters that is just a download file that accompanies the book. For this level of detail, there are some very useful filters ready to go. These checks…are checks 3.8, 3.9. So you can see that apart from these 3.8-3.9 filters, many other filters as well to do many of the other checks. So let’s apply check 3.8. So this asks, what is 10% of the project duration? That’s seven days and here you can see all the tasks are greater than 7 days. I’d probably let the 8 day task go but I would ask the scheduler to particularly break this one down. The 3.9 is of course 0.7 days and as you can see, it picks up just 2. We’re less critical on this minimum side because we just don’t want to see hundreds of violators here because then you’ve really gone overboard, you’ve added way too much detail to your schedule. So these filters are very useful for doing these checks. There is an alternative way of going and that’s using the forecast scheduling application. Something that I talked about already. So here is the forecast scheduling application. As you can see, it sets itself up here on the right hand side. 3.8 and 3.9 are right here. If I click on…showing the X for 3.8, that means there are violators, that the check failed. As you can see, there are 8 violators. I can see the same items appear here. And for 3.9, 2 violators. There they are. So, in this forecasting application, you can see that there are separate lists for time modeling, 48 checks. Workload modeling, 76 checks and cost modeling. This is of course the highest level of competency with the largest number of checks, 86 checks. DCMA with 14 checks and several checks from the GAO. GAO standard, General Accountability Office. I’m up to a total of 133 different checks. Alright so…let’s continue. Another way to minimize the effort is by using a very robust model and an important part of that is choosing the right type of dependency. If you are modeling a university exam, what would be the right modeling in your mind? Would it be this model A, where you create a finish-to-start dependency from the preparation to the exam or would it be model B, where you create a start-to-finish dependency from the exam to the finish of the preparation task? I’d like you to enter A’s or B’s, again, into the text chat. So if you think that model A is the best model, the most robust model because that’s really what we’re talking about then enter A in the text chat. If you think that model B is the best model, the most robust model, enter B into the text chat. All right Kyle, are some answers coming through already?
Kyle: “The overwhelming majority would be answer B”
That is good to see actually because not many people are using the start/finish dependency. But it’s obvious that the exam drives everything. What you’re basically telling the schedule engine, if you opted for model A, is that when the preparation takes longer then the exam will automatically be rescheduled. I don’t know about you, if you’ve tried to call your professor the evening before, if you didn’t get through your preparation and ask her to reschedule it to next week, they’ll probably tell you come back next year. Whereas this model wouldn’t do that. It would basically give you a scheduling conflict message. Another change that could happen is that the professor might reschedule the exam and in this case, in model A, the exam will just get disconnected from the preparation tasks. As you can see, the arrow goes from the preparation to the exam so there’s no signal from the exam to the preparation task at all. But you do get that signal here in model B and it will take the preparation with it basically. So, what a lot of people do is sequencing, simply sequencing tasks. And the terminology they use also implies this is sequencing. Predecessors and successors. Predecessor is supposed to precede and a successor is supposed to succeed but that does not create very robust models. In fact, we make people aware with this example, that really the successor is preceding so it gets very confusing, these terms. And the predecessor is actually succeeding. There are a lot of people who can’t figure this out until I share with them really that you should always make the arrow go from the driver to the dependent task. And in this case, it’s pretty obvious that the exam is the driver task, that’s to drive the preparation task. So it’s really important, when you want to create robust models, to keep the arrows pointed in the right direction from typically the driver to the driven or dependent task. So even there, we would suggest you start thinking in terms of…what is the driver between these 2 tasks? What is the driven task? That’s a much more helpful question to create robust models. Now, you’ll gain a fair bit of time if you start doing this. Really creating these impact relationships that are almost like cause and effect relationships. Even on a fairly small project, you would gain a fair bit of scheduling effort. Almost an hour a day because that’s what single static charts or manual schedules or Excel schedules do. They’re too hard to keep up to date. Creating each revision, you would have to update the start and finish date of 50 tasks, on average and that would take you a long time. This is also very error prone by the way.
So how can you check the completeness and the correctness of the network logic? Because that’s really what you’re after. Of course you could do that by looking at the predecessors and the successors column because basically what you want to see there is that the predecessor column and the successor column are filled in for activities. So basically what you want to see is, that the predecessor and successor fields are filled in. That would indicate that logic is complete. So that’s a fair bit of work. Now, you can make it a little bit easier if you take the summary task out. So that’s a neat little trick which would make that manual check a little bit easier. But here are perhaps better ways to go. You can apply filters that check on this. Check 5.3 and 5.4, detail tasks without predecessors, detail tasks without successors or of course you could run our forecast scheduling application. That shows here that…not all the starts are linked and here it shows the empty cells and not all the ends are linked. I’m going to repair that because this tool also has a highlight mode. You can clearly see that there is some logic missing here that should have gone from this milestone to the task. So you can see if you can start repairing that logic fairly easily. When you do that, you should also take these constraints off. So, I’ll repair a few and when I run this check again, it had 5 violators and now I repair 2 so it’s already down to 3. As you can see, it can start improving your schedule fairly easily and quickly. Same thing for the ends-linked. You can see several tasks with a missing successor. I had just repaired those ones so when I run it again, those should also disappear. And now I have only five left. I could ask here, okay what really should drive this task? And it’s not hard to see that it’s probably that task. So this is how you could create a complete and correct network logic.
That basically brings us to the next agenda point. Finding the real critical path. Basically as you know, Microsoft Project defines critical path “when total slack equals 0 or less days”. That sometimes leads to…particularly in this deadline, a challenge. When deadlines are really challenging, that will cause most tasks to become critical and that’s what you fear. As you can see, even though tasks 2 and 3 are on a shorter path, they’ll also turn critical. So that’s not very useful, we still want to see the most critical path which clearly runs through the outline and then the make graphics task, then through the format task. Even worse is that sometimes, Microsoft Project’s critical path shows too few critical tasks. And these are the causes of showing too few critical tasks. Constraints, everything that forces the schedule creates slack in Project. Elapsed durations, resource calendar, task calendars…Let me show you some of these things. Here’s a project that currently has a perfect critical path. And I will now start using some of the more advanced scheduling features. And what we’ll see is that it will start breaking the critical path. So, constrained dates. If I put this task on the 17th for example, you can now see that a constraint has created a little bit of total slack on these activities and has therefore taken them off the critical path. As you can see, the most critical path is the longest critical path. Perhaps now what we see in the 6th edition of the PMBOK is the notion of the longest path. That’s a useful notion. If I add a task calendar to this task, you can see that I’ve lost more of my critical path. Now these turn blue and more slack has been added. Elapsed durations do the same thing. If I change this duration to an “eday” duration, you can see that I’ve lost even more critical tasks and my critical path starts to look pretty flimsy and very fragmented. If I assign a resource calendar with very limited hours to work, for example, the movers work only on the weekend and of course move task will move to the weekends so that creates more total slack on the critical path. Now I have very little critical path left. So how can you repair this? Well, this notion of the longest path is very useful so we basically injected these advanced features into the schedule and saw that we lost more and more critical path. This is the current definition from PMBOK 6th, it now talks about the longest path. So how can we pry away the longest path from the schedule? You can do it manually. You could go to the file options and use a very useful feature that’s in the advanced…at the very bottom in the advanced tab. You could play with the threshold for criticality. I know that this schedule will work with 7 days and the reason why I know that…you can see that if I increase the threshold to 7 days, I get my longest path, my most critical path. And I know that 7 days works because in the front end of my schedule, I see total slack numbers. 6 and a half days. So if I increase the threshold of criticality to 7 days, I should see a complete critical path once again. So that’s the manual way of doing it. We’ve automated this. Our PathsPro tool can do a similar thing and also explain it to you.
Then there was the 6th factor. How does leveling effect the critical path? Well in the overall look of the schedule, I have very optimistic forecasts and of course the longest task is the most critical task. But in the leveled schedule, where there is not a logical dependency but a resource dependency, you’ll see that only this task will be marked as critical by Microsoft Project. You can see that there’s a resource dependency even though the current critical path algorithm doesn’t look at these resource dependencies, it only looks at logical dependencies. That’s why it thinks that it has two days of slack on this task. Some people say “well, why don’t we model these resource dependencies with creating more logical dependencies?” Well, they are fundamentally different. Logical dependency always imposes the sequence but a resource dependency does not impose the sequence and allow the two tasks to switch places. I would love to see Microsoft Project, for example, start indicating these resource dependencies on the critical path 2.0. Really, to find the real critical path and workload schedule, you need to be able to use all the scheduling features or constraints dates, resource calendars and task calendars and even workload leveling. And then still really find out what drives your schedule. To demonstrate that, I’ll open up this file. Here you can see a schedule that has a lot of red resources. These are over allocations. You can see they’re thoroughly overworked. If I level the workloads, the duration should jump from 70 days to 114 days. If I now ask for the critical path 1.0 definition, you get these few tasks with big gaps in it…there’s a gap that’s not explained, there’s a big gap. And here’s another big gap so that will not cut it. We need a better critical path, 2.0 and we can get that with this PathsPro tool that can pop up a resource-critical path. The PathsPro application found 26 resource-critical tasks. And once it’s done with creating the views you will actually see that. The entire a project duration as explained by this resource critical path in a workload leveled schedule. It will analyze the whole schedule and then explain the entire project duration. It’s found 26 resource critical tasks. Once it’s done, you’ll actually see that the entire project duration is explained by the resource critical path. So you can see that all these tasks ended up in the resource critical path because they are staggered (because of workload leveling). You can see that there are no gaps anymore, it explains the entire project duration.
So that brings me to the last agenda point, update the schedule to forecast. First of all, should we maintain the schedule baseline or should we not? There are several different objectives that would be met when maintaining the baseline. To improve estimating, you just need to set the first baseline only, you don’t need to maintain it. But of course if your KPI are driven from the baseline data or if you need to do earned value management then you also need to maintain the schedule baseline which requires a fair bit of discipline. So what data should you collect? Percentage complete? We’ve found that’s not very accurate data because really when a team member says “I’m at 90% complete”, you want it to mean I’m almost finished but we found that it’s not always the case. It could mean that if you gave your team member 100 hours and they’ve spent 90, they’ve spent 90% of their estimate and therefore they say they’re at 90% complete. In can also mean this, for programmers. They often mean this with it: I just figured out how to do it. And it gets more devious from here so what we actually recommend for people to collect is actual durations and remaining durations and then have the percentage complete be calculated through these formulas. And then you’ve just got to make sure that actual durations are in the past, no dark blue to the right of the status date…and this is now an appropriate finish date for the project. Remaining duration should be in the future, shown on this slide already. Light blue should go to the right of status date. There are really two options in Microsoft Project that help you do this. The options that I’m talking about are in the File, Options in the Advanced tab. Right here at the bottom under the calculations options, on the third point will help you accomplish this. These are the key takeaways from the forecast scheduling textbook. Creating the perfect project thermometer, that’s what we’re after. Use deadline dates, minimize your efforts, finding the right level of detail, use dependencies to model rather than sequence, maintain the schedule baseline only if you have to and then find the longest path, threshold for total slack and resource constrained schedule…you really need to go and find the resource critical path. Then update to forecast. Actual durations in the past and remaining durations in the future.
Thank you very much for attending this session and good luck in creating the perfect project thermometers!