When does a project end? It’s a tricky question, but the correct answer is usually six months after most project teams think they’re over. Here’s why.
Projects typically have difficulty ending. The end of a project is usually the official beginning of a new process or system, and that distinction
helps us answer the question of when a project should finish. The project is over when three key groups of people have been satisfied. Let’s take a software development project and look at those who are at the end of your project life cycle.
Group 1: Your sponsors, of course. The customer who pays for your project is the one who officially accepts and signs off that you are done, so you had better be conservative with your promises. Your charter will state very clearly what is supposed to be delivered. You must be careful not to promise too much, because that day of reckoning — when you ask your sponsor for final sign-off — will arrive, and you can’t leave town until you deliver.
Group 2: Those who will operate and support your system. Your project team will disband and your lead developer (who handled every code bug and performance problem throughout your project) will head into the sunset. Did you train the operations staff to support the system? Evidence that your project will eventually be supported can be found in your project and communications plan. You must have up-front meetings with operations early to talk about support. You have to meet with them on a regular basis, and you will need a budget to train them. Just because hand-over is the last thing to do doesn’t mean it should be the last thing to think about.
If you have managed projects, you know that the biggest problem is that new systems do not run smoothly for several months. You can deal with this by picking a transition date on which all open issues will be transferred to the operational support team. By picking that date you will be drawing a line in the sand when operations should be ready to support the system. And that will force you to have a training, transition and acceptance plan in place.
Group 3: The users and recipients of your new system. This is where the six-months-later rule comes into play. Your project no doubt introduces organizational change and a new way of doing business.
Has the business embraced this change and have they decommissioned their old ways and adapted to the new groove? If you think about success of your project being measured six months after you implement, you will be on your way to planning for a system where people have accepted the new ways. It is only six months into a new process that we see where the project left gaps. You should get your sponsor to agree to do check points on the new system with key users of the system. It is a nice courtesy for you to be involved in these follow-up sessions. Don’t be a typical PM, who flees the project as the new system careens into production.
