We all know that a project is a temporary endeavor. All projects have some start and end date. However, when I teach project management training classes I like to ask the participants exactly what they consider to be the end of a project. After some discussion, we realize that there are many candidate events that could signify the end of a project and, in most organizations, the definition is not consistent.
One idea is that an end-of-project meeting could mean the project is officially over. Although ending the project at the end-of-project meeting helps a little bit, it doesn't answer the total question, since you still need to decide when to schedule this meeting. You could hold the meeting after a number of events, for example after you go live or 30 days after you go live. The ultimate definition of project completion is not resolved by this answer.
The second definition that doesn't help is that the project ends when the money runs out. Although in many projects, this is actually true, it doesn't help you in terms of the basic definition. Ending a project when the budget runs out is a financial answer and it is highly arbitrary. It doesn't answer the more fundamental project management question of how to define the end of a project.
There are a number of events that could signify that a project has ended.
Perhaps the earliest date the project could end is when the client sponsor formally approves the project deliverables. This definition is probably valid for almost all projects. You're building the deliverables for someone or some group. It makes sense that the project has not completed until the people who requested the work are satisfied. This may involve presenting the deliverable for approval, and then performing rework based on their feedback. However, for the project to end successfully, the deliverables must be approved. The project could also end if the final deliverables were rejected and no further work is planned.
Many projects result in the implementation of a product or service. IT projects are typically this way. In most cases, you need sponsor sign-off before you would implement and so this implementation event would take place at a later date. Implementation may be a single event, or it may be a complex set of activities. The project doesn't end when implementation starts, but when implementation ends. For instance, if you're implementing a solution in multiple locations in close time proximity, the project would end when all of the locations were successfully implemented.
Turnover to support
If your project builds a solution that has a longer term life-span, at some point the deliverables go from being in "development" to being in "support." Sometimes this change in status also means that there's a change in the organization that's responsible for the solution. If your project solution is turned over to a support organization, that would also be a typical time to consider that the original project has completed. If there's a point where it's clear that the solution is in support mode, it's at that point the project would officially end.
Implementation plus one production cycle
If your solution has a production cycle, many times it needs to be run in production before the project is considered complete. For instance, if the solution has daily transaction processing, and a monthly closeout cycle, the solution needs to be implemented and then supported by the project team for at least one month. This makes sense since the project team knows the solution best and can respond the quickest if initial problems occur. This also helps ensure that the solution is stable before being turned over to the support team.
Implementation plus first year production
This is typically based on the budget cycle rather than a project management definition. There may be some accounting reasons why a project needs to exist until the end of the fiscal year. When the new fiscal year arrives, the project ends and support begins. Again, this would not answer the basic question from a project management perspective, but it may be the way that project end dates are defined at your company. This definition might especially be applicable for large projects.
Some end date options might not make sense for certain types of projects. For instance, if your project results in the creation of a study or recommendation, it would make sense that the project ends when the deliverable is approved. However, on that project, it would not make sense to say that you would run in production for 30 days.
The question of when a project formally ends is one that most people take for granted. However, there is not an easy answer for every organization. There are probably one or two answers that make most sense from a project management standpoint, but there may be cultural or financial factors that cause your organization to define the project boundaries differently. To a certain extent these dates just need to be understood up-front and agreed to for each project. This agreement will keep you from being in a position where you declare victory only to discover others that think you have more work to do.