| While this is not intended to be a book on project management and scheduling, I think it is an important enough topic to share what the ROPES process has to say on the subject. In my experience, lack of good scheduling is a leading cause of project failure, so while it might be a bit tangential, I will offer a few thoughts on the topic. 1.7.1 Why Schedule? There are two primary reasons projects are estimated and scheduled. These two reasons are incompatible and mutually exclusive. Nevertheless, they are often combined with disastrous results. The primary reason for estimating and scheduling projects is to plan and this requires the understanding of the cost and resource and time-based properties of the project. For example: When will the project be done? How much will it cost? Is this project likely to provide a good return on investment (ROI)? Should I invest in this project or another project? How many resources must I apply to it? Do I need to hire people and if so, with what skills? When should I begin ancillary activities, such as gearing up manufacturing, starting the marketing campaign, beginning the next project?
These are legitimate business questions and can only be answered with accurate schedules constructed from reasonable estimates. The other primary use for schedules is motivation. Motivational (i.e., optimistic) schedules are used to inspire workers to apply their lazy selves to the project at hand and not goof off. Also to donate their nonwork time (i.e., professional time) to the project. To accomplish this motivation, the project requires a sense of urgency, and this is instilled by constructing a schedule that is unachievable without Herculean efforts, if at all. An accurate schedule is actually an impediment to this motivational goal, so that the two primary uses for schedules are in fact at odds with each other. The real difficulty arises when a schedule is used for both purposes. The schedule is constructed to be optimistic but then used as if it were an accurate planning tool. The first step to estimating and scheduling projects is to select for which of these purposes the schedule is to be used. If it is to be used to plan, then the goal should be an accurate schedule. If it is to motivate, then an urgent schedule should be created. If both are needed, then you need to create two different schedules. In reality, the only really appropriate use for schedules is for planning. In my experience, the vast majority of engineers are highly motivated, hardworking professionals[23] who respond best to being treated as if they were. For this reason, we will assume that our goal is the first purpose the creation of schedules that are accurate and reasonable so that they are useful tools for planning. We will relegate the use of motivational schedules to the Dilbertesque business environments where they belong. [23] The only exception that comes to mind was an individual who quit to go into marketing.
1.7.2 Estimation As a group, we engineers fail miserably at accurately estimating how long things will take. Studies of just how bad we are at this abound in the literature. In one 1995 study, 53% of all projects were almost 200% over budget and 31% were cancelled after being started. Other and more recent studies confirm these results. In a more recent study, 87% of the projects missed functionality expectations, 73% were delivered late, and a full 18% of the projects were so off the mark that they were cancelled after development had completed. There are many reasons why this is true. The primary reason for such incredibly poor estimation success, in my experience, is because engineers are actively encouraged not to be accurate. For example, one manager told me, in response to my estimate for a project, "That's the wrong number. Go do it again." Of course, this anti-accuracy bias is based in the desire for motivational, rather than accurate, schedules. While the desire itself may be well meant (such as maximizing fourth-quarter revenue), one cannot ignore the facts without consequence. Even if being done with the best of intentions, estimation is hard! Estimation is inherently more inaccurate than observation for obvious reasons. Good estimation is possible, but it will never be as accurate as hindsight in principle. A good estimate must come to embrace uncertainty as a way of life but understand that the more you know the more accurate your estimates will be. The further along you are in the project, the more accurate your estimates will be. Schedule management must in principle include refinement of estimates and the schedule over time, resulting in ever-increasing accurate forecasts. In practice, few engineers are trained in estimation or even rewarded for accuracy; in fact, far too often, engineers are actively encouraged to give inaccurately low estimates. 1.7.3 BERT and ERNIE The ROPES process provides means for both constructing estimates and for improving one's ability to estimate. These (sub)processes are known as BERT and ERNIE. 1.7.3.1 Constructing Estimates: The BERT Approach Bruce's Evaluation and Review Technique (BERT) is the ROPES way of constructing estimates. Estimates are always applied to estimable work units (EWUs). EWUs are small, atomic tasks typically no more than 80 hours in duration.[24] The engineer estimating the work provides three estimates: [24] Although it can be used for larger units early before the decomposition to smaller units has been made.
Of these, the most important is the 50% estimate. This estimate is the one that the engineer will beat half of the time. The central limit theorem of statistics states that if all of the estimates are truly 50% estimates, then overall the project will come in on time. However, this estimate alone does not provide all necessary information. You would also like a measure of the perceived risk associated with the estimate. This is provided by the 20% and 80% estimates. The former is the time that the engineer will beat only 20% of the time, while the latter will be beat 80% of the time. The difference between these two estimates is a measure of the confidence the engineer has in the estimate. The more the engineer knows, the smaller that difference will be. These estimates are then combined to come up with the estimate actually used in the schedule using equation 1-4. Equation 1-4 Computing Used Estimate for Scheduling 
The estimate confidence (EC) factor is based on the particular engineer's accuracy history. An ideal estimator would have an EC value of 1.00. Typical EC values range from 1.5 to 5.0. As an estimator's ability to estimate improves, that number gets smaller over time, (hopefully) approaching 1.00. 1.7.3.2 Improving Estimation Capability: The ERNIE Method We also want engineers to improve their ability to estimate. As Tom DeMarco notes, "If you don't track it, you can't control it." The approach in the ROPES process for estimation improvement is called Effect Review for Nanocycle Iteration Estimation (ERNIE). It consists of tracking estimated versus actual and recording these. From this, the EC factor used in Equation 1-4 is computed. A sample from an estimation tracking spreadsheet is shown in Table 1-6. To construct a new EC value, use the formula ECn + 1 =  (deviations using ECFor example, to construct a new EC value from Table 1-6, you would compute EC2 = (0.425 + 0.56 + 0.842 + 0.1)/4 + 1.00 = 1.48
In this example, the engineer went from an EC factor of 1.75 to and EC factor of 1.48 (a significant improvement). This EC value will be used to adjust the "unadjusted used" computed estimate for insertion in the schedule. It is important to track estimation success in order to improve it. In order to improve a thing, it is necessary to track it. Table 1-6. Sample from Estimation Tracking SpreadsheetDate | Task | Low | Mean | High | Unadjusted Used | EC | Used | Actual | Dev. | % Diff. |
|---|
9/15/04 | User Interface | 21 | 40 | 80 | 43.5 | 1.75 | 76.1 | 57 | 17 | 0.425 | 9/17/04 | Database | 15 | 75 | 200 | 85.8 | 1.75 | 150.2 | 117 | 42 | 0.56 | 9/18/04 | Database Conversion | 30 | 38 | 42 | 37.3 | 1.75 | 65.3 | 60 | 32 | 0.842 | 9/20/04 | User Manual | 15 | 20 | 22 | 19.5 | 1.75 | 34.1 | 22 | 2 | 0.1 |
1.7.4 Scheduling A schedule is a sequenced arrangement of EWUs taking into account which can be run in parallel and which must be serialized. Further, the schedule must take into account inherent dependencies, level of risk, and the availability of personnel. The waterfall lifecycle scheduling is often considered more accurate by naïve managers because schedules are constructed early and may be tracked against for the remainder of the project. However, this ignores the fundamental rule of scheduling: The more you know, the more accurate you can be. Early schedules are inherently inaccurate because you know less than you do one third, one half, or even seven eights of the way through a project than you do at the end. So it is ridiculous in principle to state at the outset of a project that it will be done in 18 months, 3 days, 6 hours, 42 minutes, and 13 seconds. Nevertheless, managers often act as if they can dictate the passage of time and the invention of software. The BERT and ERNIE approach can be applied to waterfall or spiral projects. In either approach, though, early estimates will be less accurate than later refinements, when later refinements take into account information gleaned from observing the progress of the project. In principle, I believe the following accuracies for a waterfall lifecycle are achievable:[25] [25] The astute reader will note that these far exceed the accuracies of most project schedules.
Concept ± 50% Requirements ± 25% Systems analysis ± 20% Design ± 15% Implementation ± 10% Validation testing ± 5%
When schedules are first constructed, in the concept phase, "10 person-years" means, in fact, anywhere from 5 to 15 person-years. If you need a hard number, then go with 15, but if your estimation process is fairly good, then 10 will be the most accurate single number you can provide. In the spiral approach, the milestones are not the end of these waterfall phases, but instead planned prototypes. If you plan for 10 prototypes, then your first working schedule will have 10 primary milestones, one for each prototype. On average, these will usually be four to six weeks apart, but some may be longer or shorter, depending on their scope. If you want to construct larger-scale milestones, similar to preliminary design review (PDR) and critical design review (CDR) called out by some development methodologies, then you (somewhat arbitrarily) say that one prototype (say 3) will form the basis of the PDR and a later one (say 6) will form the basis of the CDR. The ROPES scheduling approach uses the Central Limit Theorem from statistics, which states that if you take enough samples from a population, your accumulated samples will form a Gaussian distribution. What that means is that if you have enough estimates of the pieces and they are in fact 50% estimates, then half of them will be early, half of them will be late, and overall, your project will be on time. That having been said, schedules must be not only tracked against, but also managed and maintained. Assessment and realignment of the schedule is one of the primary activities done in the so-called party phase of the ROPES microcycle. Figure 1-12 shows a constructed schedule using prototypes as the primary scheduling points on a Gantt chart. Each prototype has a mission, defined to be a set of requirements (normally one to a small number of use cases) to be developed and a set of risks to be reduced. In the figure, the first such prototype, called "Hello World," is subdivided into the microcycle phases, each with some time attached to it. We see that in this particular example, PDR, CDR, and customer review activities are specifically scheduled. This schedule is tracked against on a daily, or at least weekly, basis, and modified to incorporate new information as it becomes available. The net result is a self-correcting schedule that improves over time. Figure 1-12. Sample Schedule 
Other scheduling views are important as well especially the resource view that shows how your people are mapped against the schedule. Special care must be taken to ensure that they are neither over- nor underutilized in your schedule. Figure 1-13 is a resource histogram showing the loading of a resource over time.[26] In the example, you want to be sure to neither over- nor underutilize the resource. This means that for a typical eight-hour workday, you should not assume more than four to six hours of productive work effort per day, the actual value of which varies according to the business environment. You should also not assume that a work year is more than 45 weeks, to account for sick and vacation time,[27] training, and other business activities that may be not directly related to your project. [26] You never ever want to schedule overtime. If you are in the position of scheduling overtime, you will never meet your plan. At that point, you should take some corrective measures on your schedule to adjust it rather than schedule overtime.
[27] Yes, in some environments, engineers actually get vacation time!
Figure 1-13. Resource Histogram 
Figure 1-12 shows a highly serial set of prototypes. It is possible to run some prototypes in parallel and merge them together in a future prototype. This makes the schedule a bit more complex, but it may be more optimal. The important thing is to come up with a plan that you actually intend to follow. This allows you to be more accurate and to effectively track against the plan to see how you're doing. Tracking against the schedule is crucial. In virtually all things, the earlier you try to correct something, the cheaper and easier it is. This is especially true with schedules. This means that you must schedule what actually is supposed to happen and must identify deviations from that plan. If you have a schedule but it does not reflect how the work is being done, you cannot track against it. The work against the EWUs (such as the "Design Phase of Prototype 3") must be tracked if you want to be able to make adjustments, either to take advantage of the fact that it is coming in early or to adjust for the fact that it appears to be coming in late. The earlier you have this information, the easier that adjustment process will be. Adjusting the schedule may involve Schedules are dynamic entities that change over time. They are never completely accurate, except perhaps in hindsight, but a good scheduler can take advantage of the elasticity of a schedule and use it to guide the management of the project to a successful conclusion.
| 