When a project ends, there are three objectives: completing obligations and support for stakeholders (Section 16.2); saving information and artifacts that might be needed in the future; and releasing resources that the project used.
Note that ending the project is separate from retiring any particular instance of a system. Ending the project is about stopping development and support for a system product, independent of whether there are instances of that system in operation or not. Some projects will combine these, such as for exploration space missions that build and fly one spacecraft.
A project might end for one of many reasons. It might have a fixed term or have completed a defined system deliverable. It might run out of money or time. It might no longer fit the organization’s or funder’s strategy, perhaps because a better replacement system is planned. Competitors might have won over customers and there is no longer demand for the system. The team might be unable to deliver, with the project behind schedule or over budget or lacking key features.
The first step is a decision to wind down the project. This is typically a decision made by the organization that hosts the project, or its funders; the project staff generally do not make the decision on their own.
A decision to end the project is followed by a plan for how to do so, which defines the steps the team will take to meet the final objectives. The plan typically gets review and approval before proceeding. (In some environments, at least part of the plan must be worked out early in the project, long before any decisions are made.)
The following sections list some of the steps that are involved in ending a project. The specific steps will depend on the project; for example, not all projects have contracts with funders that must be closed out. The team can use this list to help build the plan, bearing in mind that some steps should be done in particular orders. Customers should be notified of the project’s impending end before ending contracts; shutting down production should happen only after all upgraded components have been manufactured.
Obligations to customers. If there are any system instances still in operation, the first step is to let those customers know that the project is ending. If system instances are owned and operated by customers separate from the project, then they will want to work out how to keep their system in operation after project support ends or they will decide to retire the system. The terms on which the system is licensed may affect what the customer can do after the project ends.
The project develops any final updates or fixes for the system, and releases them for deployment along with appropriate documentation and training. The project builds or acquires such spare parts inventory as is needed for remaining customers before shutting down production.
If there are contractual relations with the customer, the contract is closed out. This might include final billing or payments, or other deliverables.
Finally, the customer service mechanisms are shut down.
Obligations to team. Ending a project means loss of work for everyone working on it. It can also mean the loss of social relationships.
The first obligation to the team is to keep them informed once the decision has been made to end the project. The people should understand why the project is ending, the plans or timeline for winding down, and their roles during that time.
People will be needed on the project for different lengths of time. Some roles will end shortly after starting to wind down the project, such as doing development of new system changes. Other roles will last to the end, such as closing out finances and contracts. Each person needs an expectation of how long they will be needed so that they can make plans for what to do next. (In some jurisdictions, notices of layoffs are required well in advance.)
At the same time, many people will have incentives to move on to something else before their project role is complete. The plans for ending the project must take this into account, and often include incentives for people to stay on as long as they are needed.
Finally, the team’s experience represents an asset. These people can be a resource to other projects in their organizations. Helping people transition can help other projects and, done well, generates good will that helps incentivize people not to leave early.
Obligations to funders. Some projects will have contracts or other agreements with funders. These projects provide final reports and other deliverables to the funder. They can then finalize financial accounting with the funder and close out the contractual relationship.
Obligations to regulators. Some projects for systems in highly-regulated industries may need to work with their regulators when the project is shutting down. This might include filing notices that the project is ending. The project is responsible for determining what other requirements their regulators may have.
Obligations to organization. The project takes two final steps: saving information and releasing resources.
There are several reasons that information about the project may be needed in the future. There may be a need to restart the project, in which case the new team must be able to learn about the system’s design and implementation, as well as the reasons behind its design. The intellectual property in the system may be valuable for licensing or sale. There may also be investigations related to the system or the project that need information about how the project was conducted.
The project may archive the artifacts needed to restart the project. It may also archive records of project execution, known issues, and any plans that will not be completed. Some projects will archive physical artifacts: molds and forms that support production, for example; some artifacts may be kept for museums.
The end of the project is time to gather a retrospective on how the project went. A bit of introspection about what went well and what didn’t will help people on the team to do better on future projects, and helps build institutional knowledge.
Archiving project information has security concerns. The process of moving information to an archive must maintain the information’s integrity and confidentiality: it must not be modified, lost, or disclosed during the move. After that, the archive must maintain the information’s integrity and confidentiality.
The project also releases the resources it has held. This includes:
- Shutting down production lines and supply chains that supported production;
- Releasing office space, lab space, lab equipment, servers, and purchased licenses; and
- Disposing of or recycling physical artifacts used in the project.
Lastly, the people on the team will move on as discussed above.
30.1 Project cancellation
Some projects end because they are canceled, even before they have completed their development phase. Anecdotally, it seems that more projects are canceled than go to completion—this is a consequence of using competitive approaches to programs, and the net effects of competition are generally regarded as valuable. The information in this chapter applies to canceled projects just as to other projects.
Consider two examples, based on projects I have worked on.
In the first project, the team was writing a proposal for a US DoD spacecraft system. In the proposal-writing phase, the team has to establish the basic architectural and management approaches for the project, show they meet the department’s needs, and establish the price at which the team proposes to build the system. The team progressed through establishing the initial concept and architecture for the system, and we began evaluating the solution to see how good a job it would do for the customer and how much it would cost to build it.
We had a checkpoint milestone where we reviewed what we had found. At that review, it became clear that while our team had a decent solution for the needs, we did not have a great solution, and that other companies we expected to propose designs would likely have better solutions (because they had more experience in a couple of key technical areas). We made the decision not to pursue the proposal.
This was a good decision. Assembling a proposal is not a small task; we had a team of about 15 people working long hours. For US government projects, the proposer generally pays for the proposal development. Choosing to spend our team’s time and money on this project meant that the team couldn’t work on some other project. We judged that the opportunity cost was not matched by the probability of successfully winning the contract, so we freed up the team to work on a different system that did prove successful. If we had continued to work on the original proposal, we would have spent the budget available to develop proposals and could not have spent it on the proposal that succeeded.
In the second example, a different US DoD spacecraft program, the team was about two years into a multi-year contract. The team had performed excellently in a competitive first prototyping phase, and was the only team to be selected to move on to a second phase for building an initial working version. A key subcontractor on the team had staffing and management problems, and were not delivering results. Within the team we were struggling to fix the execution problems or find another way to build the necessary components, all the time keeping a large staff on payroll and running through budget. While the technological solutions for many system capabilities were probably sound, the team could not deliver. The customer observed the problem, and after working with the team to try to resolve the problems, went through the process to cancel the project.
This was also a good decision. In hindsight, the team lacked necessary capability in the subcontractor and in the project management team. If the project had been allowed to continue, it is unlikely that the team would have solved the problem and more money would have been spent without benefit in the end.
The take away from these examples is that there are many sound reasons for canceling a project. Sometimes the cancellation is designed in (as with competitive acquisition); other times it is because continuing to invest money, time, and the care of the team building the system has become unlikely to pay off.
For a more general discussion of US DoD project failures, see the report by Bogan et al. [Bogan17].