Plans, Schedules, and Milestones

We use the word project to mean a task requiring large effort. Typically projects are also complex. Even something as simple in concept as "dig a deep hole" can involve complexities such as the walls of the hole caving in. So we plan our projects, anticipating such difficulties and preparing remedies in advance. But often we also want to complete our projects by a given date, and be able to know in advance if we will complete the project on time, or at all. Those latter requirements are addressed by schedules and milestones, respectively.

A plan is a description of an ordered collection of activities which lead to the completion of some task. The order is given by dependency relationships: activity A cannot be completed without completing activity B, or perhaps activity A cannot even be started before completing activity B. There may be required activities that can in principle be performed concurrently, and are not ordered by dependency. (If you've worked with certain kinds of mathematics you will recognize this as a partial order or preorder.)

A schedule addresses the question of completion date by assigning start and finish dates to each activity required to complete the project, and requiring them to conform to the dependencies in the plan. One date or the other is often left implicit in informal scheduling (such as timelines). They may also be fuzzy, and in GSoC schedules they are often expressed like "In week 2 I will write classes X and Y." (Formal scheduling methods such as PERT and CPM address such "fuzzyness" by providing multiple estimates of the duration of activities.)

Plans and schedules are typically fuzzy. Describing the required activities precisely is difficult or impossible in many projects, especially software, because they've never been done before. That is, we write software to automate a task, so that we never have to do that again! All software is a new task, because if we wrote it before, we'd just copy it and use it again. Also, in practice, we often think of a task as "almost done", the remaining work to be trivial "cleanup", and move on to the "main content" of the next task. Often that works well enough, but when it doesn't, it can lead to disastrous delays, cost overruns, and even project cancellation.

A "milestone" addresses the question of whether you are "on schedule" or not. It's also called an "exit condition", but that has a different meaning in software design and verification. Unlike the mile markers on many highways, project milestones need not be passed in a linear order. This is useful, because mistakes are often made in recognizing dependencies or scheduling resources, so that activities must be performed at times different from those in the schedule. If you have "holes" in the schedule in the sense that you've reached a point in time but some activities that are scheduled for later times are done, but others scheduled for earlier times are not, are you ahead of schedule, or behind? How do you assess tasks that are "almost done"? Experience shows that humans are terrible at assessing "almost", and the best practice is to assign earned value (estimated effort according to plan) only to tasks that are complete.

In order to avoid the human failing of redefining "done" to mean whatever state of completion we've arrived at and maybe add a "cleanup" task to the end of the plan, we add two more best practices: always measure progress in terms of the plan agreed at the beginning of the project (the "earned value" concept), and use an objective milestone to define whether a task is done. What this means is that a milestone should be written carefully with no "wiggle room". Sometimes this can be very simple and verifiable, such as "The merge request milestone is submission of the merge request on GitLab". This is objective, but probably not a very good milestone for other reasons. A better version might be "The merge request milestone is approval of a merge request on GitLab by a committer." A bad milestone might be "The merge request milestone is updating the merge request on GitLab to address all comments by committers." The problem with that is the word "all" -- no matter how good you think your current version is, there's no guarantee that some committer won't demand more work. It's not objective.

Note that a milestone need not be externally verifiable, as long as the worker sees it as objective. For example, your working style might be to divide your proposal into short sections, draft each section in a single session, then review and edit the whole thing when done. In that case, one milestone might be "The draft Requirements section milestone is the draft section is complete, saved, and committed to the local git repository." Then if you have four sections expected to take equal effort and the review activity takes twice as much effort, when you have committed the draft of the first section, you can reliably say "my proposal is 16% done" to your mentor. The mentor can't verify it (local repo only), but it's unlikely that you're lying about or "fudging" that milestone -- she can trust you. I wouldn't do it that way myself. I would make the milestone be pushing that commit to a public repo where my mentor can verify. But some people don't like to publish their work in progress, and that's OK as long as people who depend on that work product can trust the estimated date of delivery to be honest.

A note on "earned value", or "why do we use the plan rather than actual effort to measure progress?" The problem with using actual effort is that any difference between planned effort and actual effort is likely to reflect planning bias as much as random variation in productivity across activities. If you appear to have done 5 weeks of work according to plan in 6 weeks, then you should expect the rest of the 10-week project to also take 6 weeks, not the planned 5 weeks. (The same goes for doing 5 weeks of work in 4 weeks: the current expected project duration is 8 weeks. Of course, both estimates assume you don't change your work practices.) You might also suggest changing the plan. Obviously you have to change the schedule for tasks yet to be completed, and if the delivery date can't be changed, you may need to reduce the quality of the product, changing the plan itself. However, experience shows that for the purpose of learning from mistakes, it is essential that you be able to compare the outcome to the original plan and schedule. On the other hand, measuring progress in fractions of the original plan is almost always good enough, so the effort of maintaining multiple revisions of the plan for progress measurement is rarely worth the effort. If you want to make such an effort, formal planning methods like PERT and CPM provide valuable frameworks.