Timelines and Milestones

The problem: You have a deadline (say, the end of the semester), and resource constraints:

You may also face obstacles along the way:

How can you plan your work and plan the allocation of your limited resources so that the task gets completed on time and on budget?

(In your case, "budget" refers to the team membersí time, rather than to money. In business, to some extent money can purchase more time.)

 

 

Information

No plan can be much better than the information that goes into it. Among the information that will be useful we can list

Once we have some crude numbers attached to those figures, we can see if there is a chance of completing this project with the available resources by the specified deadline.

You will see that in the case of your term project, the most uncertain item is how much work it will take. Well then, we can work this arithmetic backwards: As of now you have 11 weeks more to work on this project,

of which 3 more weeks will be devoted to design and, letís say, 6 to programming and 2 to testing. At 6 hours per week per person you have over 50 hours of design time and about 150 hours of implementation and testing time, assuming a three-person team.

Now we need two more pieces of information:

Letís say the first number is somewhere between 10 and 25. Letís say the second number is 1500 (probably an overestimate). Dividing we get

somewhere between 60 and 150 hours of implementation required. So it seems the project is feasible.

[Besides, in this case, we know that a previous class successfully completed similar projects.]

Parallel Efforts

That calculation depends on the assumption that all the people can work productively all the time. For that to work, it must be possible to divide the tasks into parts that can be done simultaneously, without requiring anybody to wait for the others to finish something required as input.

That is one of the tasks of the architectural design phase. But the architectural design may have identified two top-level classes, or four, when you have three programmers. So the actual plan of the work requires more than just the architectural design. Moreover, until the detailed design is finished, it may not be quite apparent where the person-hours will have to go.

Once the detailed design is done, it should be possible to refine the estimate of the lines of code required, by estimating how much is required for each class in the detailed design.

 

 

Putting more people on the task

Suppose the initial calculation came out showing that the task is not feasible. Then we may try to hire more developers so that the task can be completed by the deadline. Frederick Brooks, in his famous book The Mythical Man-Month, pointed out that this sometimes doesnít work:

If the task is to make a baby, you canít get it done in one month by putting nine women on the job.

Not every task can be subdivided.

If a software project is running behind schedule, you canít always speed it up by adding more people, either. Even if the task is in principle divisible, the new people will need help (training) getting up to speed, and providing that training will sap the time of the existing programmers, perhaps slowing the whole project down more than speeding it up.

 

Timelines

A timeline is a diagram that has a line representing the flow of time, with tasks for the various team members laid out along its sections.

It doesnít matter if you draw the timeline horizontally or vertically; the actual line might even not be drawn, it might be implicit. You may also want to draw one line for each team member. You can use a spreadsheet to construct a timeline; if you have a spreadsheet I recommend it, although it is not necessary. In case you use a spreadsheet, you can have a row for each week and a column for each team member (time running vertically). The first column could give the calendar date at the beginning of the week.

Time could be indicated in weeks from the beginning of the project, or in weeks until the deadline, or in calendar dates. For this class, please use calendar dates, as there is no possibility of changing either the start date or the deadline.

While it might be nice to wait until the detailed designs are complete before making the timeline, that is not possible, as the work must be planned to some extent long before then. (Both in this class and in industry.)

Therefore, the timeline has to be constructed based solely on the specifications and architectural design. The entries for the individual developers would ideally be the names of the classes that would be implemented and unit-tested each week. Unfortunately those names wonít be known until the detailed design is complete, so the timeline entries have to be less precise when the timeline is first constructed.

 

Monitoring Progress

The best plan is no good at all if it isnít followed. There are many cases recorded in which huge software projects failed, or were very late or very over-budget, or both, or all three! In some cases, this wasnít known to management until it was way too late to prevent the catastrophe.

Therefore, once the plan is made, we need a way to monitor progress. This means to check if the actual progress to date corresponds with the plan or not.

It can be difficult to ascertain that. Suppose you ask your team member how he is coming with his part of the project. Suppose he actually hasnít done very much yet. He may not want to admit that, and may tell you itís

"half done". He figures he will work all weekend and catch up. But if this sort of thing is widespread and goes on longer, the result can be disastrous. You donít want to find out when itís time to begin final testing that his part is a month behind schedule.

Even without deliberate deception, it can be hard to estimate progress.

Milestones

Milestones are the tool we will use in this class to monitor progress. A milestone is a definite achievement that one can check has or has not been achieved on a given day.

The project plan consists of a timeline and some milestones. The milestones are specific achievements, and are attached to specific dates on the timeline. On that day, management (in this case Dr. Beeson) will check whether the milestones have been met.

Example of a milestone: The program can connect to another copy of the program running on a different computer and chat messages can be exchanged in both directions.

Example 2: The game board can be displayed correctly and a piece can be successfully dragged to a new legal location, but illegal moves cannot be made.

Non-example: The chat system will be substantially complete.

Poor example: The game board can be displayed correctly and moves can be made. (Only legal ones? or also illegal ones?)

 

Selection of milestones

In selecting a milestone, we have two things to consider: the achievement, and the date. We want to match these up so that if all is going according to schedule, the milestone will be achieved on the specified date.

From the point of view of management, we want the milestones and dates to be selected so that meeting them shows the project is on schedule.

From the point of view of the programmers, we want the milestones as easy as possible and as late as possible, to reduce the danger of missing them.

This conflict of interest will be resolved in our class by having the milestones reviewed early on by Dr. Beeson and approved.

In industry there is no standard way of resolving this conflict but I suspect it works the same way: management reviews the milestones early on.

In our class, the dates for the milestone checks are already set (Oct. 26 and Nov. 16). Therefore, the project teams need to first form their plan, and then see where they expect to be on milestone days, and then formulate a precise milestone representing progress to that point.

It would be a good idea to set milestones to check progress on each of the three (or four) paths of development being pursued by the individual programmers. You can set internal milestones that will not be checked by Dr. Beeson if you wish.

The project timeline that you turn in should include the required two milestones, and may include others. If you use a spreadsheet, put the

milestones in a separate column (so you have one column for the date, one column for each programmer, and one for milestones).