The end of a stage provides an opportunity to make course corrections and learn from the experience of the stage. Increasingly accurate estimates can be made as the project progresses, laying the groundwork for planning that will be done at the beginning of the next stage. Project experience to date should be recorded in a software project log so that it can be used by future projects.
Staged delivery is a flexible delivery approach, and a staged delivery plan can be executed with either of two general bents:
- The stages can be deterministic, which means that they mainly provide a means of delivering the most important software functionality earlier than would be possible with an all-at-once approach.
- The content of the stages can be redefined at the end of each stage, which means that the stages deliver the most important functionality early but also provide an opportunity to change course at the end of each stage.

Hold an omnibus change board meeting
The time just after a release is a natural time to consider proposed feature changes en masse. The whole project team topically works hard to achieve its software release, and spending a day or two considering a proposed changes can provide a welcome change of pace. Project members shouldn’t be subjected to a continuous barrage of feature change request. If the number of times changes are considered is not limited, project members can find themselves evaluating change impacts every few days or so, and those bits of work add up to a huge distraction.
Recalibrate estimates
The end of a stage is a good time to review the project’s actual schedule performance against its planned schedule performance and revise the project estimates in the first place by considering these questions.
- Is the project scope still about the same as it was estimated by originally? if not, the estimate should be adjusted for the improved understanding of the project scope.
- Has the feature set been changed?
- Has the required level of performance, robustness or fit and finish changed?
- Has the development team been as productive as expected?
- Were necessary tasks omitted for the estimates? The estimates should be revised to account for these factors, too.
It isn’t wrong to underestimate the project size or overestimate the project team’s productivity early in the project; it’s wrong not to find and correct those estimation mistakes later in the project.

Evaluate performance against the project plan.
Keep sure that the team is following the plan, and keep track of their advance to the current goal to make sure everybody keeps with the plan. This books approach makes it easy to follow the plan. Since the information is public, the plans are credible, humane and up to date.
Stick to the plan, if the plan is impossible to follow, replan. A sure way to lose control of the project is to abandon the original plan without putting a new plan in its place.
Archive project media

At the end of each stage, the environment used to create the software should be archived. Organizations often need to be able to recreate an old version of their software, which can be an impossible task of old versions of project components are unavailable.
The project should archive at least the following:
- Copies of the release package, including CDs, printed documentation, collateral material, and packaging.
- Source code.
- Database or data files released with the software.
- Data files used to create the software.
- Custom tools developed for use on the project.
- Commercial libraries.
- Graphic resources, video resources, sound resources, and other resources contained in the software.
- Source text files for help files and other documentation.
- Build scripts.
- Test scripts.
- Test data.
Closure.
At the very end of the stage delivery we must also update the projects log, which is a valuable material for future projects.
Bibliography
McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.