Introduction to Planning

and the PEP Tool

Lynn Robert Carter


Macro Lifecycle Model

At the heart of the Personal Engineering Process (PEP) is a belief that lessons from the past can be leveraged to produce better results on future projects. When people are open to the patterns of the work they do, it is easy for them to see recurring activities in their projects. These patterns of work are often called lifecycles. The most fundamental lifecycle in PEP consists of four major recurring activities:
  1. Plan
  2. Perform
  3. Reflect on actual versus plan
  4. Reflect on quality

How can one produce a reasonable project plan before the details of how the work is to be done are known? The answers is that one can't. The question implies a misunderstanding of the fundamental purpose of a plan. A plan is not a prediction of the future. A plan is a communication tool to help a team work effectively together as well as a memory aid. People often avoid planning out of a belief that they must predict the future in order to produce a good plan; they don't want to be held accountable for their inability to do this. This belief is not helpful.

A better view of planning is to think of it as a record of a person's or a team's best guess for how the work should proceed. The goal is not the accuracy of the guess. Rather, it's having all of the project stakeholders understand the plan and concur that this approach makes sense, given everything that is currently known. Too often, people spend much too much time writing things into a project plan when there's no basis on which to do so. Having invested so much effort in the plan, many are unwilling to discard it when it becomes clear that the original ideas will no longer serve the team well. Plans should only provide enough detail to remind everyone on the team of the group's answers to the standard set of questions: who, what, why, when, where, and how. When it becomes clear that these answers are no longer adequate, the plan needs to be rewritten. A good plan allows team members to make independent progress without interrupting others with questions. Therefore material should be put into a plan only if it:

Armed with the best answers the group can produce to the standard six questions (who, what, why, when where, and how), the team shifts from planning to performing. If the plan was not developed collaboratively and does not represent the best consensus the team can attain, there's little hope that the implementation will honor the plan. When a team plans effectively, work tends to flow smoothly (at least for a while). The three critical activities during performing are to:

The first and third activities are self-explanatory. The second requires a little more detail.

The basis for the PEP system is the observation that work tends to be like previous work with minor differences. As stated earlier, lifecycles capture standard high-level patterns of work. Within each lifecycle are a number of smaller activities, many of which occur with regularity on project after project. When people get used to recognizing these standard activities, they are more willing to admit that there may be useful standard solutions available. Moreover, the amount of effort to implement these standard solutions can be predicted, to a point, and such predictions makes it much easier to make commitments to both customers and senior management about the questions they tend to ask (e.g. "When will it be done?", "How much will it cost?"). Capturing information about what activities are actually performed and the amount of effort to perform them gives the team solid data on which to base future planning and improvement efforts. It is truly amazing how predictable many common tasks in software development can be when one takes the time to really record this information.

At the end of the project, the work of a serious professional is not finished. The task of reflecting on what actually took place and contemplating what can be learned from the experience is critical. The PEP system partitions the reflection into two parts: actual versus plan, and quality. (See phases three and four of the four-step PEP macro process above.)

The PEP System provides a repository for information that makes leveraging past experience easier. When a student carefully logs actual effort, actual complexity, and defects into the system for each assignment, the PEP System is able to calculate baseline information to assist in planning future efforts. When the reflection process is employed carefully, the lessons captured by the system are made available to the student at precisely those times where previous experience indicated the lesson was needed. The actual versus plan reflection helps the student capture "Based on this experience, what could I have done differently to produce a more effective plan?" The defect reflection helps the student capture "Based on this experience, what could I have done differently to avoid these kinds of defects?" It is critical not to think of these reflection activities as assigning blame. The goal is to understand how to improve.

We split the reflection into two parts because of the sources of the information that drive each. The actual versus plan reflection can take place as soon after the project as it can be scheduled. In fact, we encourage people to hold these reflections as soon as possible after the delivery. The quality refection depends on information from the customers about the quality of the product. Thus customers must use the product and discover actual or perceived quality issues. (Regardless of what you call it, if a customer thinks it's a defect, it's a defect.) As with the actual versus plan reflection, the point of the quality reflection is to address the question, "What could we have done during the planning and performing phases of the project that could have avoided these quality problems?"

Capturing the lessons from the reflections is not adequate if behaviors don't change based upon them. The final and most critical aspect of the PEP Tool is how lessons learned and performance information is fed forward in an easy manner to support future planning and performing activities.

Starting Up the PEP Tool

To access PEP, one starts from any relatively current web browser on the internet. (Either Netscape or Explorer should work. PEP does not use Java or employ frames. I've successfully use the system with older various of Netscape back to some at version 2.0.)

The URL to access the system is:

http://deming.colorado.edu/

Entering that URL will cause your browser to display a page similar to that shown in Figure 1:

Figure 1

The PEP system stores sensitive information, so the system requires you to use a username and a password. Your professor will provide you this information. We recommend that you change your password to something meaningful to you that is not likely to be cracked by others. The following figure shows the login dialog one version of Netscape uses.

Figure 2

Logging out

In order to keep your information in the system secure, you need to either log out of the system or terminate the browser session. Figures 3 through 6 show the sequence of steps required to log out of the system.

Figure 3 is a PEP user's main page, from which the user may change their password or log out. This figure shows the user positioning the cursor in preparation to logging out.

Figure 3

None of the current browsers make it easy to clear your username and/or password from the browser. To accomplish this task, you need to log into to a page that does not support your username/password. The PEP system has created such a page that only accepts a blank username and a blank password. The following two figures shows what the system will display when you click the log out link.

Figure 4

Some systems will automatically insert your old username into the dialog box shown in Figure 5. If that happens, you must remove it before you click the OK button as shown in Figure 5.

Figure 5

When you have entered an empty username and password to the system, PEP will display the following message to tell you that you may safely leave the machine without quitting the browser (if that is an acceptable thing to do. Please follow local policies, whatever they may be.)

Figure 6

Selecting A Course

From this page, the user may follow links to information for any of the courses the student has been authorized to access. Figure 7 shows that this user has access to only one class, ECEN 4553 - Compiler Construction. When it is time to work with a specific course, click on the link related to the course. In Figure 7, there is only one course available. Some students may have more than one course being supported by the system. In that case, each of those courses would appear on a separate line.

Figure 7

In the case of a course such as ECEN4553, the following page is similar to the page you will see. In this case, the professor has only defined one assignment. As the semester progresses, other assignments will be added to the system and those additions will be reflected in the page. Each assignment is given a separate row of data and a link similar to that shown in Figure 8. To work on an assignment, click on the link that is the name of that assignment.

Figure 8

Creating a Plan

It doesn't make sense to spend a great deal of time thinking about the details of a project until there is concrete information to support the effort. That information is obtained from an understanding of the work that must be done, the tools that might be available, and a general approach that could be used to produce an implementation. Therefore it is proper to think of planning, from a macro-level, as consisting of two major steps:
  1. Understand the problem and capture a reasonable solution to it.
  2. Estimate the effort to accomplish the solution and schedule the work.
The understanding phase of planning consists of a careful study of the problem. In many classroom situations, the instructor has taken care to spell out the problems in great detail. This is artificial. In the commercial world, the specification of what is to be done is never complete, is usually self-contradictory, and the customer is constantly changing their mind about what they want and how it is supposed to work. The notion that the requirements will eventually settle down is the dream of beginners. Those that have been in the commercial world for a while know better.

Once the team understands as much as they can about the nature of the problem to be solved, the next challenge is to understand the tools at their disposal. Many developers work in disciplines where there is a wealth of existing support. To ignore the investment the firm and others have made in system architectures, subroutine libraries, code generators, etc., is to doom the team to waste time and effort needlessly implementing things that have already been implemented. While it is true that there is a cost associated with understanding the work of others, there is a cost associated with ignoring powerful tools as well. The ECEN4553 class will expose you to a number of standard compiler writing problems and standard approaches for solving these problems. Whether you elect to use Eli, existing support libraries, or implement the algorithms yourself is really beside the point. The real issue is whether or not us understand how to solve the problem and can implement the solution in a timely manner with adequate quality.

With an understanding of the problem and the available tools, the final understanding step is to reach a team consensus about how to go about solving the problem. Without the "idea" on how to actually write the implementation, nothing will happen. Of all of the tasks we've described so far, this is the hardest one to describe. Either one has an idea on how to proceed happens or one doesn't . This is why being part of a team can be so valuable. Different people get insights at different times. Once one member of the team has an idea, they can start sharing the vision with the other team members. The discussions about the potential solution will either convince the others or help everyone appreciate new aspects of the problem they hadn't understood before. For this class, the critical "ideas" are available and teams seldom have problems moving forward.

The only support the PEP Tool provides during the understanding activity is to capture the effort, information, and insights for each of the three understanding steps. The following figure shows me about to log information for the "understand the problem" step of the "understanding" activity.

Figure 9

Once the link has been pressed, the PEP system responds by creating an effort log item and asks you to provide additional information. The following figure shows the information the system is designed to capture. One of the most critical aspect of logging effort is to ensure the proper Task Step and Deliverable have been selected. In the case of the understanding activities, the system automatically fills in the step and doesn't allow you to change it. (You can go back to any effort item log entry and alter any of the fields, but it is best to avoid that if you can. Do it right the first time.)

Selecting the right deliverable can be confusing during the planning activity. While it may be true that all of the work that you are doing during the planning activity is really aimed at producing the plan, thinking of the effort that way is not helpful. A better way to think of the effort is to realize that the understanding activities are really about understanding the solution, and all effort that is spent working toward producing a solution should be logged against that solution. You should only log time against the project plan or the lessons learned when you are actually producing the project plan or capturing lessons learned (filling out PEP screens).

You will also notice that the ECEN4553 class provides two "kinds" of solutions: specified solutions and programmed solutions. Your professor allows you to decide for yourself what tools you will use for your implementation. If you elect to code everything in Eli, the compiler-compiler environment, you should select the "Specified solution" deliverable, as all of the code you will be writing will be specifications. If you elect to write you solutions using C++ or Java, you should select the "Programmed solution" deliverable, as all of the code you will be writing will be in a general purpose programming language.

The following figure is how an effort log might be filled out by a student that is going to do at least some of the work using a general purpose programming language. By the way, it is perfectly reasonable to select a mixed strategy where some of the solution is done by writing specification (say BNF input to a parser-generator) and complete the implementation with programming language code (say C++ routines to actual construct the tree based on the connection points from the generated parser.)

Figure 10

The remaining two steps of the understand activity would be logged by clicking on their corresponding links.

Estimate complexity

Once the team has as much understanding as they are likely to have about the solution to the problem, the next step of the planning process is that of actually producing the plan. The support PEP provides is to walk you through a process of developing a schedule based on effort estimates derived from estimates of deliverable complexity. The following figure shows me about to click on the link to capture deliverable complexity information.

Figure 11

Your instructor has determined the number of significant deliverables needed to support the planning, performing, and reflection process supported by PEP. It is true that one could image a very different set of deliverables, but for the sake of this class, your professor has defined just four deliverables and these are shown in the following figure.

Figure 12

Data driven planning processes start with the deliverables to gauge the amount of work that will be required. Just as the number of miles you need to drive can be used to help you predict the amount of time required to drive from one place to another, the size of deliverables can be used to predict the amount of work required to produce them.

The fundamental notion behind the use of size based effort estimation is to find some measure of complexity for each deliverable. A direct relationship between the value of the measure and the amount of work required to produce the deliverable. It doesn't really matter if we understand what the relationship might be. All we really care about is the ability of the relationship to predict effort given a measure that is relatively easy to make.

As described above, the amount of time required to plan an effort is compose of two major activities: and understanding process and an effort estimation and scheduling process. The amount of time one has to spend in the understanding activities appears to be related to the complexity of the problem to be solved. The amount of time needed to estimate the effort and schedule that effort seems to be related to the complexity of the lifecycle selected and the number of deliverables that lifecycle might produce. Therefore, the amount of time one spends on planning is really a function of two variables: the complexity of the problem and complexity of the plan.

The measure of complexity of the plan is expressed (for this class) as the sum of the number of tasks in the lifecycle for the plan and the number of deliverables that lifecycle produces. The lifecycle for this class consists of seven tasks (see Figure 19). The solution I will be producing consists of three deliverables leading to a total Project Plan complexity measure of 10. (The problem requires a program, so the Project Plan, Programmed Solution, and Lessons Learned deliverables were counted. Had I been able to elect a mixed implementation consisting of both a programming language and a specification solution, both solutions would have been generated for a total of four deliverables and a complexity measure of 11.)

Figure 13

The complexity of the solutions are both measured in term of the number of lines of code required to generate the solution. At first glance, this appears to be a circular definition. It is true that the precise number lines of code required to generate a solution can't be known until the solution has been developed. At the same time, it is possible to estimate how large a solution might be by comparing the problem to other problems that have been solved and using the actual sizes from those solutions.

In this case, I learned that the professor's solution was roughly 250 lines long. I figured my solution would not be as tightly coded as the professor's, so the figure of 325 lines was selected. (After the implementation has been completed, you will be asked to specify the actual complexity number for each deliverable. How large was the solution? Did you indeed develop the solution using just a programming language? These actual complexity figures are critical for computing actual production rates that will support the creation of performance baselines. These baselines will assist you in planning future assignments.)

At the bottom of Figure 14, please note the Rationale text area. Each of the steps in the planning process has such an area. This is where you need to record the rationale behind your planning. For the planning assignment, the reasonableness and the consistency of your rationales and how well they describe the figures you select is the basis for grading. The fact you choose one set of numbers or another set of numbers is irrelevant. The accuracy of your numbers is irrelevant. The quality of your rationales and the lessons you have learned are all that really matters.

Figure 14

Estimate effort

Once each deliverable has an associated complexity estimate, you can proceed to the effort estimation step. From Figure 9, press the Estimate the effort and an estimation error for each deliverable link. The PEP system will respond with the following page. In this case, the effort has already been estimated. When you see this page for the first time, only the Deliverable and Complexity Estimate columns will contain data (from the previous activities). To specify the production rate, click on the link as shown in Figure 15.

Figure 15

From the effort estimation summary page, the PEP System takes you to the following page. This page shows you the current value for the production rate and the estimate error for this deliverable. For this example, I believed that roughly 60 minutes was a reasonable guess for the amount of time to fill in the plan using the PEP system. (Recall, that the time to figure out what goes into the plan should be allocated to the solution deliverable.) On the next assignment, the baseline information fields will provide insight from past experience for you to use. For the first time, it's okay to guess. Since the student estimated 60 minutes, a production rate of 6 was selected. The production rate times the complexity measures yields the effort estimate. Since the complexity measure for this deliverable is 10 (see figure 15 above) and the total effort estimated is 60, the production rate should be 6. After you have experience using production rates, you will use production rates and complexity measures to tell you how many minutes to allocate.

This figure also shows that I estimated the potential error in the estimate of 100%. This means that I wouldn't be surprised if the actual time were somewhere between 30 minutes and 120 minutes. (The upper bound of the error range is calculated by taking the estimate and multiplying it by 1 plus the error in the estimate. Since the error in the estimate is 100%, (1 + 1 * 1.00) * 60 = 120. The lower bound of the error range is calculated by taking the estimate and multiplying it by 1 / (1 plus the the error in the estimate). Since the estimate error is 100%, 1 / ( 1 + 1 * 1.00) * 60 = 30.)

Figure 16

Once you are satisfied that you have specified the right production rate and the estimate error figure, click the update button. The system will then update the appropriate data bases and return you to the following page.

As before, the effort estimation page contains a Rationale field. You must specify the rationale for your production rates and your estimate error figures. For the first assignment, it is okay for these to be guesses, but this will not be adequate for future assignments.

Figure 17

To update the rationale, you must click on the Save button as shown in Figure 17. The PEP system will save the current information and return you to a page similar to that shown in Figure 18.

Allocate effort

Once all of the effort for each of the deliverables has been estimated, the next step is allocation of that effort for each deliverable to the appropriate lifecycle tasks. This begins by clicking on the link as shown in Figure 18.

Figure 18

Again, this screen shows what the page looks like after this effort has been completed. When you first see the page, only the Lifecycle Task column is filled in. To specify the values for the other columns, you must click on the links to each of the various deliverables as shown in Figure 19.

Figure 19

The following figure shows the allocation of the effort estimated for the Project Plan deliverable. You professor has specified that project planning can only be allocated to the first lifecycle task, so this deliverable is trivial.

The PEP system expects you to specify the percentage of the total effort to accomplish all of the work to produce a deliverable to all of the tasks that contribute to it. Since percentages must add to 100% and there is no easy way for you have the sum of the inputs be 100, the PEP System asks you to enter units as opposed to a percentage. The system sums all of the units that have been entered, and uses that sum to establish the ratio of the allocation. Since there is only one lifecycle task for the project plan deliverable, any value specified for units (other than zero) will result in 100% of the project planning effort being assigned to the Plan the Approach task. A more interesting example follows where there is more than one lifecycle task. (See Figure 22.) To update the number of units for a lifecycle task, click on the name of that lifecycle task as shown in figure 20.

Figure 20

The PEP System will then paint a page similar to that shown in Figure 21. I filled in the number of units needed for that lifecycle task and presses the update button as shown in Figure 21.

Figure 21

When the update is completed, the system will take you back to a screen similar to that as shown in figure 19 above. If I should click on the Programmed Solution link in figure 19, the system would display a page similar to that shown in Figure 22.

In this case, I had already specified the various units for the allocation of the total effort estimated for the production of the Programmed Solution. Here I elected to enter actual percentages. Any set of numbers could have been used as long as their relative ratios remain the same. With this deliverable, I assumed that 45% of the effort needed to produce the programmed solution will be consumed in understanding the problem, understanding the tools available to solve the problem, and developing an idea into a high-level design and 30% of the total effort will be spent in the implementation of the design (including detailed design, coding, unit testing, and integration.) The rest of the effort is spread over the remaining tasks, including the creation of the information to go into the lessons learned document.

Figure 22

Figure 23 shows the allocation of effort to capture the lessons learned into the PEP system. I believed that the number of steps required to insert information into the produce the actual versus plan screen would consume far more time that needed for the defect reflection. The reasoning has to do with the number of steps in the two reflections; there are more than twice as many steps in the actual versus plan reflection as in the defect reflection.

Figure 23

The following figure shows the rationale for the allocation. Again, recall that the quality of the rationale for the selection of the values is far more important that the numbers themselves.

Figure 24

Elaborate Tasks

Gathering data on the time needed to perform an implementation is useful for helping people improve their ability to estimate the amount of time to perform similar activities in the future. The goal of the PEP System is more than that. In addition, the PEP System is intended to help people improve both the speed as well as the quality of implementations. These aspects of the goal require more than a time accounting facility.

The PEP System assumes that its users can benefit from timely reminders of lessons learned from previous experience. When people are under pressure, they tend to fall back to more basic and fundamental processes: the fight or flight response that is hard-wired into us all. Professionals, wishing to react in more disciplined ways during times of stress, have developed proven methods and mechanisms to support them. The first of these is the checklist.

When the work is critical and workers find themselves under significant stress, checklists serve to remind their users of vital information that may not be remembered quickly enough. The point of a checklist is not to imply that the checklist user is not good enough to remember fine details in normal situations. Checklists are a tool to address unusual situations, those times when physiological and psychological processes all humans experience disrupt us.

The PEP System provides a checklist facility that extends the basic lifecycle given to you by the professor. Each student is allowed to establish a set of process steps for a subset of the lifecycle tasks. (At least one step per task must be defined.) In Figure 25, a table is displayed showing each of the lifecycle tasks (defined by the professor) and the number of steps that have been defined for each task. Notice that the first and last two tasks are not links while the middle four tasks are. (The PEP System defines the steps to be used for planning and the two reflection tasks.) You are required to elaborate the rest.

To elaborate a lifecycle task, click on the name of that task as shown in Figure 25. In this figure, I am asking to examine and/or update the steps for the "Develop testing procedures" task.

Figure 25

Once the link has been clicked, the system will respond with a new page similar to the one shown in Figure 26. This page provides a representation of the steps that have been defined for the "Develop testing procedures" task. In this case, only one step has been defined. To create a new step and add it to the list, click on the Add link found in the upper right-hand side of the page. To update an existing step, click on the name of the step as shown in Figure 26.

Figure 26

Pressing the Add link or the name of the step link takes you to a page that is similar to the one shown in Figure 27. When the Add link is used, the form will be blank except for the order field at the bottom. When the name of a step link is pressed, the previous definition for each of those fields will return.

Each task step consists of three critical fields:

  1. Step name
  2. Step description
  3. Sort order
(The system also provides the name of the lifecycle task to which this step belongs.)

It is a good idea to select a step name in active voice. Short names starting with a verb tend to be more effective. The description should be just enough additional information to remind you what it is that you are supposed to be doing. Keep this short as well. These steps are not intended to teach anyone what to do or how to do it. Rather, they are there to remind you of something you already know but might not remember when you are placed under pressure.

The third field is the sort order field. The system uses this field to order the steps when they are displayed as in figure 28. When a student updates the steps, the system sorts the steps using whatever values are currently in the sort order field. The system then defines a new serial number value for the sort order for each step, starting at one. To move a step from the third place to the first place, enter a sort order value of zero. The system will then sort that step ahead of all of the others and will then renumber them starting at one. To insert a step between the first and second steps, change the sort order value to 1.5 and click on the update button.

Figure 27

The next three figures show how I elaborated the rest of the lifecycle tasks from figure 25.

Figure 28

Figure 29

Figure 30

The following figure shows the rationale text field for this lifecycle task. After specifying your rationale for your elaboration, be sure to press the Save button. After that button has been pressed, the system will return you to a page similar to that shown in figure 32.

Figure 31

Adjust Effort

Up to this point, the PEP System has been computing time estimates for you based on an algorithm and a set of assumptions. You need to look at the amount of time the system has calculated for you and consider how you feel about these estimates. (It makes sense to do the adjustment now, as you have just finished thinking about the details of the work that needs to be performed for each task.) If you like the figures, this task is done. If you are uncomfortable with any of the figures, you need to adjust them to something that feels better. (If you make an adjustment, you need to capture the rationale for that adjustment.)

To alter an estimate, click on the name of the lifecycle task. You will be asked to specify a non-negative value of the percentage of the automatically calculated figure you wish to use for your plan. The default adjustment is 100, representing 100% of the automatically calculated figure. Numbers less that 100 will reduce the estimate (as well as the lower and upper bound). Numbers greater than 100 will increase them. (Recall that the lower and upper bounds come from the estimate error values you specified for each deliverable. See material provided above figure 16.)

Figure 32

Figure 33 shows the page used to specify an adjustment factor to one of the lifecycle tasks. The table of figures has been duplicated, but the upper right corner of the page is different. This portion of the page reminds you of the field being altered, provides an input field, and contains the update button to be used once the new adjustment has been entered.

Figure 33

Once the update button is pressed, the system results you to a page similar to the one shown in Figure 34. Before moving on, you need to provide a rationale for your estimate adjustment, even if you've made none. Figure 34 shows my rationale and shows that the Save button needs to be pressed in order for the rationale to be saved.

Figure 34

Schedule Effort

When all of the previous steps have been completed to your satisfaction, you are ready to consider how to spread the effort across the period of time you have available to you. The point of scheduling your effort is to recognize that not all tasks are equivalent. Some tasks require access to certain resources (such as a library or the professor) that might not be available 24 hours a day, 7 days a week.

The second aspect of scheduling is to cause you to think about providing enough time to recover from surprises. If one of the tasks results in new insights that invalidates some of your planning assumptions, do you have time to recover? If you schedule all of the work the day before a deliverable is due, it is difficult, if not impossible, to recover from a surprise.

The third aspect of scheduling is communication. Have you and your teammates come to agreements about the answers to the standard questions (who, what, why, when where how)? Without this agreement, it is easy to waste time and effort.

Worst case effort scheduling is recommended. Don't just schedule time based on your estimate, for there is a very real probability that this estimate is low. (When you have a wealth of data at your fingertips, you will be able to make much more accurate estimates, but all this additional data does is reduce the size of the estimate error. You will still do worst case scheduling, it's just the definition of worst case that will change.) It is better to schedule more time than you need than to schedule less time. When you discover that you have scheduled more time than you need, it is easy to find things to do to fill the suddenly found free time. Should you fail to schedule enough time, it is very difficult to figure out how to recover.

Figure 35 shows the scheduling main page. This page summarizes the scheduling of effort in three one week blocks. Each of the lifecycle tasks is displayed separately for each of the three weeks of the time allocated to the assignment. In general, the first week is dedicated to the planning activities, the second week is dedicated to performing and the actual versus plan reflection, and the third week is dedicated to the defect reflection.

To schedule time, click on one of the lifecycle task names. It doesn't matter which one you click from the three times that name appears (once each week), the system takes you to precisely the same page. When you schedule a task's effort, you are asked to provide 21 days worth (three weeks). In Figure 35, I am clicking on "Plan the approach" task. (This figure only shows two of the three weeks. The monitor I was using was too small to show all three weeks, so I could not capture all of that information in the screen shot used to generate this document. In this case, your browser will generate vertical scroll bars so you can scroll to the rest of the page.)

Figure 35

Once you have specified which task to schedule, a page similar to the one shown in Figure 36 is displayed. As you can see, the system has replicated the lower bound, estimate, and upper bound at the top of the form. That is to guide you as you work to schedule the effort. In addition to the range of effort estimates, the system also shows you the steps the system and you have elaborated for each of the tasks. The intent is that you will consider the work to perform these steps, seriously consider what resources are required, and will schedule your time in a manner that allows time to recover from surprises.

Once you have filled in the number of minutes required for this task, click the Update button and continue with the rest of the tasks. In this example, I scheduled the bulk of the effort for the planning task to occur on the first three days of the assignment. The thinking behind this was that any problems discovered during the understanding activities could be resolved during the professor's office hours on Wednesday. Should a major surprise occur, the team will have Thursday through Sunday to recover from the surprise with Friday's office hours as a critical milestone. If the team doesn't have a solid handle by Friday's office hours, the team should camp out at the professor's office until the needed insight has been obtained.

The following two figures show how two other tasks were scheduled.

Figure 36

Figure 37

Once all of the time I believe is relevant has been scheduled, the scheduling rationale must be captured and the data must be saved. Figure 38 shows my rationale. Figure 35 (above) shows the Save button that must be used to save the rationale.

Figure 38

Finalize the Plan

Once the schedule has been completed and saved, the last step is to finalize the plan. This consists of two things:
  1. Log effort against the plan deliverable
  2. Signal that planning is done

If you have been logging effort throughout the planning process, you may not need to generate another effort log entry. Many people, however, will fill in all of these plan pages from complexity estimation through scheduling in one sitting. If that is the case, an effort log item should be completed before moving on.

If the finalize link is used as shown in Figure 39, the system will perform a two-step operation. An effort log page will be generated as shown in Figure 40. When that information is updated (by click the update button) the log will be updated and the system will be notified that planning for this assignment is done.

If there is no need to generate an effort log item (because the information has already been captured by clicking on the effort log link) the Finalize button on the right side of the page can be used to inform the system that the plan is complete without generating an effort log item.

In this example, I selected to provide effort information, so the "Finalize the plan and update the effort log" link is being used.

Figure 39

When you complete effort logs, it is critical to specify the time in minutes and to select the proper deliverable. During planning, time spent understanding the problem, the available tools, and coming to a decision about how to solve the problem should be charged to either the "Programmed Solution" deliverable or the "Specified Solution" deliverable. Time spent estimating effort, scheduling effort, and filling out the forms should be charged to the "Project Plan" deliverable. In this example, I logged 45 minutes toward the "Project Plan" having just spent 45 minutes filling out these various pages this system has provided.

Figure 40

When the system is finished updating the databases with your information following one of the two methods you have to finalize the planning activity, the system will generate a page similar to the one that follows. Once you have finalized the plan, you will not be able to go back and change any of the information that was captured in the plan. (You can always adjust the effort log and the defect log, should you feel the need. I encourage you to be honest. Don't change the log out of a belief that you will get a better grade by misstating how long you spent doing the work. Log reality and tell me what you have learned. That will earn you an excellent grade as long as your description of what happened and what you learned about it makes sense.

Begin the Implementation

The following screen shows that the plan has been finished. Click on the name of the assignment this time will take you to a completely different part of the system.

Figure 41


lrc@sei.cmu.edu
Revision 1.4 (1999/09/19 20:28:00)