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.
Abstract
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.
Introduction
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:
- 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.
- Plan each segment of the project as it crystallizes, staying at least four weeks ahead of the current state.
- 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
- Requirements planning
- Feature definition (leading to feature freeze)
- Design and implementation (leading to code freeze)
- 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.
Tidak ada komentar:
Posting Komentar