Scheduling is Not about Chronology; it s about

Transcription

1 Scheduling is Not about Chronology; it s about Logic! Table of Contents Intro 1 Current Issues in Scheduling 2 Activity Sequencing versus Determining Causality 3 Sequencing Relationships in the Wiki-Website Schedule 4 Cause-And-Effect Relationships in the Wiki-Website Schedule 5 What Future Scheduling Software Should Do in the Wiki-Website Schedule 6 All Our Current Dependencies are Later-Than Dependencies! 6 Why Are Causal Relationships Important? 7 Other Issues That Will Be Resolved With Causal Relationships 8 Integration of Critical Path and Critical Chain Scheduling 8 What Scheduling Terminology Can Stay For Causal Dependencies? 9 What Scheduling Terminology Should Change For Causal Dependencies? 9 Changes Needed in CPM and in Scheduling Software 10 Conclusion 12 Intro Definition of the terms: Scheduling is the act of determination of dates for project deliverables, activities and milestones. Note that the term itself is not defined in the PMBOK or the Practice Standard for Scheduling; I had to derive this definition from the definition of the term project schedule that is defined in those documents. Chronology is the arrangement of events in their occurrence order (Wikipedia). Logic is the study of the principles of valid demonstration (proof) and inference (deriving a conclusion from premises) (Wikipedia). In this article, we would like to discuss if scheduling is a matter of determining chronology or a matter of determining logic. Some terms used in scheduling imply scheduling is a matter of determining chronology, e.g. terms like activity sequencing, predecessor, successor, lag and lead. Other terms used in scheduling imply scheduling is a matter of logic, e.g. terms like network logic and modeling. It appears to me that the scheduling profession is at a cross-road where it needs to decide whether scheduling should be a matter of chronology or a matter of logic or both but each in their own school of thought. In this article, we will argue that scheduling should be a matter of logic; we think schedules will be better if they are logical models of projects. ProjectPro Corp Page 1

2 Current Issues in Scheduling A successor often does not succeed in time. For example, tasks involved in the following relationships do not succeed each other chronologically: start-to-start, finish-to-finish, finish-to-start with a lead time. Similarly, predecessors hardly ever precedes (entirely)! The terms are hard to understand and therefore hard to use. Activity sequences often change. Schedulers cannot rely blindly on their network logic to produce viable scenarios of their schedule when they enter progress. When schedulers use dependencies as activitysequencers, their dependencies are often arbitrary and will often change. Ideally, when schedule updates are entered, the network logic always produces a schedule that makes sense from a practical point of view. Current schedules are too maintenance hungry. Schedulers often create network logic that is very maintenance hungry. Ideally, you create the network of dependencies once and you don t need to change it (other than refining it). Current scheduling software does not allow dynamic due dates. Our schedule software does not allow us to create dynamic due dates. Have you ever been saved when a team member who works on a critical tasks announced (s)he will slip their deliverable? If programmers deliver the source code late, the documentation people suddenly also have more time to complete their deliverables and we will end up moving due dates often, spending a lot of time on maintaining our schedule. Current scheduling software does not allow dynamic windows of opportunity. Our schedule software does not allow us to create dynamic windows of opportunity for tasks. Many tasks of secondary importance have a window of opportunity that should shift when the Critical Path shifts. For example, software documenters can start when the software screens are finalized, but have to be finished when the software is implemented. This window of opportunity shifts constantly as progress is ahead or behind on the programming, testing or debugging tasks. Scheduling software does not allow you to schedule part of your schedule backward. Your entire schedule is scheduled forward or backward. Often a milestone is an event from which certain activities need to be scheduled backward. Often the chains of tasks that are of secondary importance need to be scheduled backwards from a critical milestone on the Critical Path. As one life-long scheduler, Ralph Kuhn PMP, puts it: Ten years ago, I had no Start-to-Finish dependencies to speak of in my schedules, now I sometimes set up to 5% of my dependencies as Start-to-Finish dependencies in my construction schedules! ProjectPro Corp Page 2

3 Activity Sequencing versus Determining Causality To introduce the issue with a simple example, consider you have two tasks: Prepare for exam and Take the exam. In which way would you schedule these two tasks; in way A or in way B as shown below: A Prepare for exam FS Dependency Take exam B Prepare for exam SF Dependency Take exam ProjectPro Corp. If you choose A, you take the process Activity Sequencing from the PMBOK (3 rd Edition) literally, and tend to determine chronology between their tasks: You prepare before taking exam, so the finish of preparing should be linked to the start of take exam. The result is a Finish-to-Start (FS) relationship. The predecessor task precedes the successor in terms of chronology, which makes sense. If you choose B, you treat dependencies to model cause-and-effect relationships between tasks (logic): The start date of the exam should drive where the preparation task is scheduled, so the start of Take exam should be linked to the finish of Prepare for exam. The result is a Start-to-Finish (SF) relationship. The predecessor actually succeeds the successor in terms of chronology, which does NOT make sense. The successor actually precedes. Which schedule is better? In our view, schedule B is more accurately reflects reality. There are several reasons for this: 1. In schedule A, the finish-to-start dependency implies that if you need more time for prepare for exam, you will (and can) postpone the exam. Only some exams can be rescheduled; the PMP-exam and the driver s license exam. In schedule B, the exam date drives when you need to be finished with the preparation, which is valid for most other exams. ProjectPro Corp Page 3

4 2. Schedule A suggests that if prepare for exam will take less time, you will reschedule the exam to an earlier date. In schedule B, the exam date will stay where it is. 3. In schedule A, if the exam is rescheduled, the preparation task stays scheduled where it is, whereas in schedule B the task prepare for exam would be rescheduled accordingly. As you can see, schedule B is able to withstand real-life changes much better than schedule A and is in our view a better schedule of the situation. Schedule B is a dynamic model of the situation and will need less maintenance and provide forecasts that are more accurate. Over the years, we have made some observations: Most people have difficulties with dependencies as sequencing relationships because when they sometimes see that the successor precedes and that the predecessor succeeds, it does not make sense to them (in terms of chronology). It does not make sense to me either. Many people struggle with the process of Activity Sequencing because it is arbitrary and subject to change. Sequence relationships are not stable relationships; they simply ask you to express your personal preference. When the schedule shifts, the sequencing relationships often need to be changed. The sequencing relationships are very maintenance hungry. The PMBOK calls for sequencing the activities by calling the process Activity Sequencing. We can see here that some terminology used and defined in the PMBOK does not support thinking of dependencies as cause-and-effect relationships. In my view, this process should call for Determining Causality between activities instead. We will now explore these concepts in a larger, more realistic schedule situation, the creation of a wiki-based website. Sequencing Relationships in the Wiki-Website Schedule If you create a small schedule in terms of Activity Sequencing the following would result: Explanation: The task write documentation can start as soon as the screens of the computer software application are completed. The task write documentation has 5 days of total slack, because it is scheduled to be started very early. The problem with this schedule is that documentation is scheduled too early in the project; documentation is seldom completed before the feature is entirely coded. ProjectPro Corp Page 4

5 Cause-And-Effect Relationships in the Wiki-Website Schedule If you create the schedule in terms of cause-and effect or impact relationships (causality), the following schedule would result. The task write documentation is now scheduled backward from when the feature is expected to be completed using a Start-to-Finish relationship: Explanation: The way the current scheduling software Microsoft Project handles this situation is: The startto-finish relationship from feature completed to write documentation overrides the dependency from screens completed to write documentation because the start-to-finish dependency tells the software that it should schedule the finish of task write documentation at or after the start of feature completed. We don t agree that write documentation should be allowed to finish after feature completed, but that makes it end up scheduled close to the feature completed milestone. The start-to-finish dependency does not have an Earlier-Than attribute, neither Microsoft Project nor Oracle s Primavera has Earlier-Than dependencies as a feature. The strength of this schedule is that the schedule is more realistic in terms of the dates for the task write documentation. It is scheduled to be done as late as possible and does not finish before the features are coded (code feature). The problem with this schedule is that the Total Slack on the task write documentation is calculated to be 7 days; it can slip to May 30 th. The total slack should be only 5 days, the window of opportunity from May 8 until May 21 minus two weekends and minus the duration of the task: 13 2*2 4 = 5 days. You can see here that the current scheduling software does not support thinking of dependencies in terms of cause-and-effect and entering them as such. The software does not have earlier-than dependencies. By the way, the screen shots are made in Microsoft Project, but Primavera calculates the Total Slack (Total Float) in this project exactly the same; it is how the Critical Path Method and algorithm are defined. The task write documentation is now an open end (loose end) in the network of dependencies; its finish date is not constrained by anything but the project finish date. Technically, this is wrong, because you cannot still be writing your documentation while you are implementing the feature; you need the documentation in order to implement the feature! Of course, master schedulers have worked around this by setting an extra Finish-to-Start dependency from write documentation to implement feature to bring the total Slack down and tie up the loose end. If the Start-to-Finish dependencies were treated by the scheduling software as an Earlier-Than relationship, there would not be less slack on task write documentation, because with the Start-to-Finish-Earlier dependency, we are telling the software that the start of the milestone Feature Completed should cause write documentation to end. We would have a perfect, logical model of the situation. ProjectPro Corp Page 5

6 What Future Scheduling Software Should Do in the Wiki-Website Schedule Scheduling software should allow us to model the wiki-project in terms of cause-and-effect logic: 4 d 0 d Finish-to-Start-Later Start-to-Finish-Earlier Finish-to-Start-Later (FS Later) dependency from screens completed to write documentation. Start-to-Finish-Earlier (SF Earlier) dependency from feature completed to write documentation. The total slack on write documentation is calculated as the window of opportunity that the two dependencies on the task provide. The task is currently scheduled to finish just before the milestone feature completed but could move up to 5 days earlier: Total Slack = 5 days. This schedule is able to withstand almost any type of change or progress that you throw at it without having to revise the dependencies: If the first five tasks slip, the window of opportunity for write documentation will slip accordingly. If code feature or test feature takes longer the window of opportunity for write documentation expands; the documentation specialist will have more time. If they take shorter, it shrinks. This is often what happens in practice. Write documentation is cut off when the feature completed occurs, which is often what happens with documentation in practice. The documentation is shipped as-is. All Our Current Dependencies are Later-Than Dependencies! The four types of dependencies, we currently have, are all Later-Than dependencies: If you set a Finish-to-Start dependency without any lag or lead, it means that the start of the driven task (dependent) cannot be earlier than, but can slip later than the finish of the driver task (independent). If you set a Start-to-Start dependency without any lag or lead, it means that the start of the driven task cannot be earlier than, but can slip later than the start of the driver task. If you set a Finish-to-Finish dependency without any lag or lead, it means that the finish of the driven task cannot be earlier than, but can slip later than the finish of the driver task. If you set a Start-to-Finish dependency without any lag or lead, it means that the finish of the driven task cannot be earlier than, but can slip later than the start of the driver task. ProjectPro Corp Page 6

7 In the case of the exam, we concluded that the Start-to-Finish dependency was the better type of dependency in most cases, but we still have a problem. The Start-to-Finish dependency between these tasks allows the Prepare for Exam task to extend its duration and to slip its finish date past the start date of the Take Exam task, which of course does not make sense in this situation as shown in the next illustration: Start-to-Finish-Later (existing dependency): prepare for exam take exam Start-to-Finish-Earlier (new dependency): prepare for exam take exam ProjectPro Corp. What we need to model this situation properly is a new type of dependency, a Start-to-Finish-Earlier dependency. If we could make the Start-to-Finish of the Earlier-Than character as shown in the illustration, we could tell our scheduling tool that the Prepare for Exam task should always finish before the Take Exam task. This would also restrict the Total Slack for the task, which the current Start-to-Finish dependencies don t do. Do we need all four types of dependencies to provide an Earlier-Than and a Later-Than variety? Yes, all dependencies should allow you to indicate if it is an Earlier-Than or Later-Than relationship because more types of dependencies provide more flexibility to model a wide variety of project situations. Specifically: Earlier-than dependencies give us the possibility of dynamic due dates. Dynamic due dates are rescheduled automatically when the network moves and it recalculates the slack (float) of each task constantly. Dynamic due dates are a very useful feature that cannot be found in any scheduling software currently, as far as we are aware of. Earlier-than dependencies give us the possibility to model dynamic windows of opportunity. Why Are Causal Relationships Important? There are several reasons: Cause-and-effect relationships make it easier to analyze how a network updates the scheduled dates. Each arrow will be treated as an impact relationship, and in order to understand how the impact will flow through the schedule, you just need to follow the arrows in the direction that they point with cause- and effect relationships. ProjectPro Corp Page 7

8 Cause-and-effect relationships in combination with Earlier-Than dependencies allow you to create: Dynamic due dates: The date when you need to be ready is often dependent on when other people will be ready with their work. If we had earlier-than dependencies, we could say if this milestone slips, extend the time allocated for that task (earlier-than relationship). This is a useful concept in many situations. Dynamic windows-of-opportunity: The period in which a task can take place can shift through dependencies. You will be able to give a task a later-than relationship with an early task as well as an earlier-than relationship with a later task, which creates a window-of-opportunity for the task. This is a useful concept in many situations. Other Issues That Will Be Resolved With Causal Relationships Backward scheduling from a fixed finish date does not work well in current scheduling software: If all tasks are scheduled as late as possible, there are no buffers in the schedule and the project will be late. An ALAP task may have total slack (total float), but if you start work on the day the task is scheduled and enter the actual start date, the total slack suddenly disappears. If you do want to schedule as late as possible, you have to build buffers into the schedule in appropriate places, which is exactly what Critical Chain schedulers do. Nobody understands Start-to-Finish relationships currently. Nobody can produce an example in which to use them. The Start-to-Finish dependency is hardly ever used in schedules, because it is hard to come up with an example where the start of one task should drive the finish date of another task. If you can create a Start-to-Finish-Earlier relationship, it will have utility and application in practice. Primavera already has a solid hammock task feature, but Microsoft Project does not. The new Earlier-Than attribute of dependencies will allow us to create hammock tasks where needed that fluctuate in duration as the network shrinks or expands. We can then constrain a hammock task, like Manage the project, to start Later-Than contract award and simultaneously, we can force the task to finish Earlier-Than the project finish milestone. If the task can also automatically stretch or shrink driven by its dependencies, we have a real hammock task feature in Microsoft Project. Earlier-than dependencies will allow you to create dynamic buffers on tasks in secondary chains. This will allow us to do traditional Critical Path scheduling or Critical Chain scheduling with a single scheduling application. We will explain this in more detail. Integration of Critical Path and Critical Chain Scheduling In current scheduling software you have to choose between scheduling your project in either the Critical Path way or the Critical Chain way and the resulting schedules cannot be converted back and forth. A Critical Chain schedule with buffers is essentially a different schedule than a Critical Path schedule, because of: The time buffers that need to be inserted in every chain The ALAP scheduling ProjectPro Corp Page 8

9 The tight estimates The resource-critical path The avoidance of multi-tasking Particularly, the buffers make a Critical Chain schedule different from its Critical Path brother. With the new type of dependency that we propose in this article, we think it will be possible to switch back and forth between a Critical Path view of the schedule and a Critical Chain view of the schedule. What Scheduling Terminology Can Stay For Causal Dependencies? Terms that can stay the same or that can keep their current definition: The terms that characterize the different kinds of dependencies can stay the same: Finish-to-Start: creates an impact from the finish of the driver task to the start of the driven task; if the finish date of the driver task moves, the start date of the driven task will move with it. When the driver finishes, the driven task is triggered to start. Finish-to-Finish: creates an impact from the finish of the driver task to the finish of the driven task. When the driver finishes, the driven task is forced to finish. Start-to-Start: creates an impact from the start of the driver task to the start of the driven task. When the driver starts, the driven task will be triggered to start. Start-to-Finish: creates an impact from the start of the driver task to the finish of the driven task. When the driver starts, the driven should finish. When there are multiple dependencies, the most constraining dependency will take effect. The term Network Logic is ok. The term Network Diagram is ok. What Scheduling Terminology Should Change For Causal Dependencies? Terms that need to change or that need to be redefined in our standards: We need to remove the terms Predecessor and Successor from the PMBOK and from our vocabulary and replace them with the words Driver and Driven or Independent and Dependent task. The word Predecessor implies that this task always precedes, which is often not the case, for example in a Start-to-Start dependency. The word Successor implies that this task always succeeds which is often not the case, for example in a Start-to-Start dependency. Note that, even if we decide not to start treating dependencies as cause-and-effect relationships, we need to find better terminology for Predecessor and Successor. We need to rename the PMBOK process Activity Sequencing to something else, like Determine Causality or Determine Relationships. A lag is defined in the PMBOK (3 rd Edition) as that it directs a delay in the successor. The words lag and delay imply sequencing and chronology and are confusing when you treat dependencies as cause-and-effect. The term lag should be dropped; the term lag is ProjectPro Corp Page 9

10 not appropriate any longer in that case, because the driven task is not necessarily lagging the driver task, for example in a Start-to-Start relationship. The term lag needs to be replaced by the term dependency duration, gap or time-spacer. The term lag relates to time and chronology and is no longer appropriate. If a dependency has a duration, it will naturally create a gap between the ends of the driver and driven tasks that are linked (FS, SS, FF and SF relationship). If you add a positive lag of 2 days (dependency duration) onto the Start-to-Finish dependency (Later-than), the driven task write documentation will go to the right (later) in current scheduling software (Microsoft Project and Oracle s Primavera) as in the following screen shot: Instead, in this situation the lag should be treated by scheduling software as a duration on the dependency and should go to the left (earlier). An Earlier-Than dependency will do this (We tricked the software to make the following screen shot). You can see why terms like gap or dependency duration are more appropriate: A lead is defined in the PMBOK (3 rd Edition) as that it allows an acceleration of the successor (PMBOK, 3 rd Edition). The word lead can be dropped entirely if the field dependency duration ( gap or time spacer ) in scheduling software allows entering negative values (even though for activities, negative durations do not make sense). Changes Needed in CPM and in Scheduling Software The most important change is that in the Critical Path Method (CPM), the Critical Path algorithm needs to be enhanced so it can process the new Earlier-Than dependencies. The algorithm needs to calculate Early Start, Early Finish, Late Start and Late Finish dates correctly when the scheduler uses Earlier-Than dependencies. The current generation of scheduling software treats dependencies exclusively that the independent (driver) task imposes a Later-Than constraint on the dependent (driven) task. In addition to this type of relationship between tasks, the next generation of scheduling software also needs Earlier-Than dependencies. Therefore, in scheduling software we need the following change. The dialog box in which you specify the type of dependencies should provide the following options: ProjectPro Corp Page 10

11 Existing dependency relationships: FS: Start driven task after Finish task driver = Finish-to-Start-Later (FSL) SS: Start driven task after Start task driver = Start-to-Start-Later (SSL) FF: Finish driven task after Finish task driver = Finish-to-Finish-Later (FFL) SF: Start driven task after Finish task driver = Start-to-Finish-Later (SFL) New dependency relationships: Start driven task before Finish task driver = Finish-to-Start-Earlier (FSE) Start driven task before Start task driver = Start-to-Start-Earlier (SSE) Finish driven task before Finish task driver = Finish-to-Finish-Earlier (FFE) Start driven task before Finish task driver = Start-to-Finish-Earlier (SFE) The new thing here is that these options allow you to create dependencies that kick back in time (earlier) instead of dependencies that can only kick forward (later). Graphically, we should be able to see immediately if a dependency is of the later-than or earlier-than type. We can accomplish this if we use the following depiction for the later-than and earlier-than dependencies: Finish-to-Start-Later Finish-to-Start-Earlier ProjectPro Corp. As you can see, you just have to look at the direction of the arrowhead to understand in which direction the impact will happen. If the arrow points to the right, it is a later-than relationship. If it points to the left, it is an earlier-than relationship. ProjectPro Corp Page 11

12 Conclusion In this article, we proposed to change the paradigm of scheduling from determining chronology to determining causality. This requires us to see scheduling as creating a dynamic model of the project that needs little maintenance and that produces forecasts that are accurate under most circumstances that can occur. For this, we need a new type of dependency relationship, the earlier-than dependencies that currently do not exist in scheduling software. Author of Dynamic Scheduling with Microsoft Office Project 2003 President ProjectPro Corp. Ottawa, ON, Canada Tel EricU@ProjectProCorp.com ProjectPro Corp Page 12