Iterative Software Project Planning and Tracking

Project management can be described as the activity of bringing all participants from within a department to successfully complete a product deliverable. Iterative planning and tracking are techniques used by some project managers to avoid having to choose between reducing the number of features or extending the schedule.


Project management can be described as the activity of bringing all participants from within a department to successfully complete a product deliverable. Iterative planning and tracking are techniques used by some project managers to avoid having to choose between reducing the number of features or extending the schedule.


Because software is ephemeral, software projects are frequently difficult to plan, track, and assess. Iterative project management techniques help make the obscure clearer.

Most successful project managers know how to set up a project plan. They know what the standard milestones or events for the project need to be (O'Connell, 1996), and they plan the project accordingly. They plan the schedule according to a specific critical path (generally tasks). McConnell (McConnell, 1996) and others have shown that once a project has missed a milestone, the project's staff cannot “make up” the time. Project managers may face the choice between extending the schedule and dropping the features. The management part of project management is required to manage the schedule and include the features.

There is an alternative to the blind choice of extending the schedule or dropping features. As a project manager, if you can “chunk” the features, and give yourself sufficient flexibility in learning about the features and project scheduling, then you can redirect the critical path, and still make the schedule with the planned features. This method of developing a number of small independent features, and frequent replanning is iterative project management.

This paper presents an iterative project scheduling technique together with two example releases from an organization.

Initial Project Planning

Senior management frequently fixes the ship dates without a good knowledge of the features to be produced. Naturally, the engineers decry this as a terrible, awful thing. Planning and expecting to completely meet a fixed schedule project without adequate feature knowledge is truly is a terrible, awful thing. For example, imagine this scenario.

Dan, the project manager, has just talked to senior management. “Those **&&** just did it to me again. They told me to ship this next release in 4 months. Our competition just announced availability in 8 months. Now we need to announce availability in less than 6 months. We don't even know what it's going to take to design this feature, never mind implement it within this architecture. How the heck can I sell this to the engineers? What am I going to tell my project team? They're going to kill me- or what's worse, they'll all walk out. How could senior management do this to us? Don't they know what it's like to develop software?”

It's not that senior management is bad or stupid. Commercial companies have significant market forces that may prevent them from fully understanding what they are requesting of the product developers. Market forces drive companies to make choices before the company is really ready to do so. Iterative project planning allows a company to get started on a project when only the major issues of the feature set are understood, but the ship dates are set in stone.

Critical Paths

There are multiple critical paths in a given project. The tasklist generates a particular critical path. The people working on the project create another critical path. And, hard resource availability creates yet another critical path. The true project critical path is the critical path through all three views: tasks, people, and resources.

During the initial planning phase of many projects, the tasks and events are planned, and with any luck, the task critical path emerges. Many project managers are also aware that people and hard resources (i.e. machines, networks, etc.) have an impact on the critical path, and they plan for using these scarce resources appropriately.(Goldratt, 1997)

In a project where the project manager and the technical staff do not have sufficient knowledge of the full feature set under development, a traditional approach does not guarantee success. The traditional approach assumes the project manager knows and understands the critical paths of tasks, people, and resources. In a less-fully specified project, it is unlikely that the project manager will know all the critical paths. The project manager will probably be surprised by new tasks that arise, unforeseen tasks, or new expertise may have to be developed, and new resources may be required.

When project knowledge is imperfect an iterative approach is more successful:

  1. Plan the major milestones. Estimate the feature freeze, code freeze, system test freeze, beta ship and product ship dates. Determine the criteria by which the project staff can agree that these milestones have occurred.
  2. Plan each segment of the project as it crystallizes, staying at least four weeks ahead of the current state.
  3. As each project segment completes, the project manager and technical staff have a better understanding of the project and the eventual product, so more complete planning can take place. By the time the project has reached the feature freeze milestone, the tasks required to get to code freeze are well understood. By the time code freeze is reached, the rest of schedule can be laid out and planned.

This iterative approach reduces uncertainty for the current project work, and allows replanning of the critical path at a number of points in the project.

Milestone Definitions

This set of milestones is useful for defining software project schedules:

Milestone Criteria
Feature freeze The date when all required features are known and the detailed design has uncovered no more. No more features are inserted into the product.
Code freeze Implementation of the design has stopped. Some testing of the features has occurred.
System test freeze Integration testing is complete. Code freeze for system test to start.
Beta ship The date the Beta software ships to Beta customers
Product ship The date the product ships to the general customer base

For small projects, there may be only one of each freeze and Beta ship. For larger or more complex projects, functionality may be grouped so that part of the product is ready for code freeze while part of the product has still not met feature freeze.

Milestone Planning and Criteria

Effective project managers and software engineers understand that a general approach of

  1. Requirements planning
  2. Feature definition (leading to feature freeze)
  3. Design and implementation (leading to code freeze)
  4. Verification and Validation (leading to ship)

is a time-effective and cost-effective way to implement a project. In addition, early and often reviews and inspections will reduce project time (Gilb, 1993). Project managers following this technique can get a better handle on the milestones of feature freeze, code freeze, system test, beta freeze, and ship freeze.

In an iteratively planned project, it is critical that the project team agrees on what each milestone means. The project manager depends on accurate information about the current state of tasks from the project team. How can the project be successful if the project manager and team do not understand what the milestones mean?

To use the iterative planning technique, the project manager plans the major milestones (e.g. feature freeze, code freeze, system test, beta freeze, and ship freeze), and then iterates on the work between the milestones.

(Re)Planning the Next Project Phase

Even for an iteratively-planned project, some tasks are clearly defined in each phase. For example, if a formal beta test is planned, then all the pre-beta tasks need to be completed before beta can start. These tasks can and should be planned in the initial project schedule. Any tasks that can be planned in advance should be planned.

One of the benefits of not doing detailed planning of the next major phase is that the project can advance more quickly. Some people are intimidated by a large schedule with many tasks (Maguire, 1994). Either they think they can't possibly make any progress, or they figure since there are so many tasks, if their task slips, it's not a big deal. However, any task slippage diminishes the ability to replan the rest of the project. If the project manager shows people a project plan with less detail, and continually asks them for more detail, they are more motivated to complete their tasks. My experience has been that people are anxious to complete their work, and get the next batch of work. When there is huge task list of everything that needs to be done, people get bogged down.

By planning the current phase in detail, and gradually increasing the detail on the next project phase, people can see how progress is being made, and they come up with possibilities the project manager may have missed to accelerate the project.

In a fixed-ship schedule, the project manager is always looking for ways to advance the project. All too often in traditionally planned projects, project advances (tasks finishing early) are wasted (Goldratt, 1997). The reasons for this are the following:

  1. There is no rush to start this task, so the task owner starts at the last minute. (Goldratt calls this “Student Syndrome”, waiting until the last possible minute to start the assignment.)
  2. When people multitask between different tasks, they waste time changing context between tasks. (See (DeMarco, 1987), (Weinberg, 1994), and (Weinberg, 1997) for an excellent explanations about the damages of context switching on effective work.)
  3. Dependencies between steps can waste all advances, if the dependencies between steps and resources are not uncovered and planned for before the tasks are started.

In an iteratively planned project, no one person has a huge list of tasks, so lack of progress is more visible. Since there are fewer tasks, there is incentive to start each task as quickly as possible, so that forward progress can be reported.

A fixed-schedule project has a deep sense of urgency, so the project manager can reduce the requests for and effects of multi-project multitasking. Using an iterative planning approach, the schedule becomes more and more detailed over time. The dependencies are uncovered early, and replanning can occur when more dependencies are uncovered.


Replanning is necessary when there is a project advance or delay. Project delays propagate to later project steps (Goldratt, 1997). Time can never made up, only plans can change.

In traditional completely-planned projects, there are only two alternatives to project delays (Weinberg, 1994):

  1. Reduce the number of features
  2. Slip the schedule

If you understand precisely what it will take to complete the features, and you understand the current project state, there are no other alternatives. The reason is that the project critical path is fixed.

Shifting the Critical Path

In a less well-defined project, however, there are alternatives. For example, if you understand the current critical path by task and person performing that task, there may be an alternative to who performs the task at what time.

If the critical path cannot be shifted, then the project manager only has the two choices above- reducing features or slipping schedule.


This is two examples of iterative project planning and tracking with a small group developing a middleware communications application. For the purposes of this discussion, we will call the product “Messenger”. In this case, senior management did not fully understand features, and the ship dates were fixed.

The original project milestone dates were:

1/15/96 Complete requirements (feature freeze)
3/31/96 Code freeze
4/15/96 Beta ship
5/15/96 Product ship

By 3/15/96, the project was in this state:

1. The project manager had not written a project plan (the prose defining the features, approach, and release criteria).

2. Feature freeze had not occurred. Two of the three major features for the release had not been adequately defined technically.

3. A task list existed, but many tasks were defined as three to four weeks duration. In reality, the project team was slipping about a week every two calendar weeks. The original task list only had about a dozen more tasks than the excerpt above.

The technical staff were working on what they thought was important to do, but it turned out they were not working on the project's critical path. They were working on whatever was interesting to them, and on customer problems (Rothman, 1997).

By April 1, it was clear that a mid-May product ship date was not going to be possible. The original project manager was replaced in April 1996 by a more experienced manager who then worked with the technical staff to create a new project plan.

The first project schedule from the second project manager looked like this:

4/5/96 Feature Freeze
4/12/96 Code Freeze
4/18/96 System test freeze
4/22/96 Start System test. Start beta test.
6/14/96 Product Ship

The new underlying task list had substantial detail for the feature freeze and code freeze milestones. There was little detail past the “Start System test” milestone. There was very little detail in the beta test phase, primarily because Feature Freeze had not been met yet. However, the major milestones, and some of the specifics of the end game (manufacturing dates, etc.) were specified, because they were known, and their dependencies were understood. The plan was to get to the System test freeze date. If the system test entry and beta entry criteria could be met, the rest of the schedule could be planned. The project team understood that their first priority was to get the software features implemented and stable.

Within two weeks, by 4/15/96, it was obvious that beta test was not going to start on 4/22/96. These things happened:

  • Senior management and the project manager discussed the promises made about this product release to the customers and the press. The external promises were for “Second quarter 1996”, rather than a hard date.
  • The customers were willing to take beta software that had not been through system test.
  • Senior management understood that the project was about three months late.

These realizations allowed the real replanning to start. In mid-April, not all the features were fully designed. The project team worked with the project manager to determine what would define the feature freeze, and came to (not quite bloody) agreement.

In mid-May, the milestones were:

4/30/96 Feature Freeze
5/1/96 Code Freeze, start system test. Start initial beta testThere was incredible detail in the project task lists, itemizing which testing was to be done when, so that people and machines were not waiting on one another.
7/11/96 Final code (and documentation) freeze.
7/12/96 Product Ship

At the April project assessment, based on the progress and current slip rate, it was not clear that the project could complete before August. In July, senior management was overjoyed that the project was less than three full months late. The customers were thrilled. They had never received a Messenger release this close to on time, with as few defects as this release had.

The original missed time could not be made up, but iterative planning was useful for containing the project slips.

This same project team then started another project with initial dates:

9/3/96 Feature Freeze
10/7/96 Code Freeze, Start system test
11/14/96 Beta freeze, Start beta test
12/14/96 Final code (and documentation) freeze.
12/31/96 Product Ship

In this case, there was substantial task list detail for the feature freeze and part of the code freeze milestones. There were no technical tasks listed for the rest of the schedule. By the time the team achieved each successive milestone, the planning for the following milestone was complete.

During the implementation phase (9/3/96-10/7/96), a major problem was uncovered. The original design for a particular feature could not be implemented in the defined time. So, the replanning activity defined tasks for starting a partial system test in tandem with the completion of the feature. The milestone list now looked like this:

9/3/96 Feature Freeze
10/7/96 Partial code Freeze, Start partial system test
11/1/96 Final code freeze, start full system test
11/14/96 Beta freeze, Start beta test
12/14/96 Final code (and documentation) freeze.
12/31/96 Product Ship

The difficult feature was not dropped, nor was the overall project schedule slipped. The system architect and feature designer spent much time redesigning and prototyping the feature. That (originally unplanned) work proceeded in parallel with the system testing. The tasks underneath the listed milestones changed around to accommodate the additional work on the feature.

Senior management and Messenger's customers were astounded that the initial ship date was met. In addition, because everyone agreed to appropriate ship criteria, the product had very few customer-visible defects.


Iterative project planning is useful when the uncertainty is high, and the risk to shipping all requested features at the requested ship date is high. The iterative planning and scheduling technique provides:

  1. A sense of urgency for the development team.
  2. The ability to plan and adapt the critical path for the gradual unfolding of knowledge about the project.
  3. A planned replanning effort. Most projects replan, this technique sets the expectations that the replanning will occur.
  4. Use of the critical path to define priorities and motivate and inform the staff to the realities of the project.

Initially fixing the milestones but not the tasks allows for studiously and continuously shifting the critical path to make the most progress in a project. Then, even if the original dates are based on nothing but senior management's wishes, the project manager can use a rational approach to plan and manage the project.


DeMarco, Tom and Tim Lister. (1987). Peopleware, Productive Projects and Teams, Dorset House Publishing, New York.

Gilb, Tom and Dorothy Graham. (1993). Software Inspection, Addison-Wesley, Reading, MA.

Goldratt, Eli (1997). Critical Chain, The North River Press, Great Barrington, MA.

Maguire, Steve. (1994). Debugging the Development Process, Microsoft Press, Redmond, WA.

McConnell, Steve. (1996). Rapid Product Development, Taming Wild Software Schedules, Microsoft Press, Redmond, WA.

O'Connell, Fergus. (1996). How to Run Successful Projects II, the silver bullet, Prentice Hall, Englewood Cliffs, NJ.

Rothman, Johanna. (1997). Case Study: From “Chaos” to “Repeatable” in Four Months, Proceedings of Software Engineering Process Group 1997. Software Engineering Institute, Pittsburgh, PA.

Weinberg, Gerald M. (1994). Quality Software Management, Vol. 3: Congruent Action, Dorset House Publishing, New York.

Weinberg, Gerald M. (1997) Quality Software Management, Vol. 4: Anticipating Change, Dorset House Publishing, New York.

© 1997 Johanna Rothman.

Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.