Everything comes to an end... except projects?

Everyone is beaming with pride! We did it – the software is up and running. The project team and the customer have made it through the go-live. Everything is gradually going back to normal. It’s time to relax. Or at least it would be, if we didn't still have 1000 things to do. 

Oftentimes, wrapping up a project is harder than getting it started. What does an end-of-project situation typically look like? The software is live, but there’s still a million little items that got pushed off before the go-live, because they weren’t that important. And then you’ve got a few little errors – minor bugs that you figured you’d get around to fixing after the go-live. Completing the software goes pretty fast. But fixing the bugs can take forever. 

The project close-out generally goes along with the project acceptance procedure. And oftentimes, that’s when it gets complicated. You’re faced with a long list of bugs to fix. You go over the list with the customer and agree on when each bug needs to be fixed, depending on the urgency. Usually what happens then is this: The bugs are fixed, and the customer monitors the progress in the system. In the process, the customer finds new bugs that they’d also like to have fixed. Instead of getting shorter, your list of bugs is now longer than it started out. Rest assured, this state of affairs is not very satisfactory for either side. 

Usually, these new bugs are new functions or optimizations or the “well, obviously that’s what we wanted it to do” kind of bugs. The reason it only comes up at this point is usually that the customer is worried that the contractor will just disappear once the project is accepted, leaving the customer to deal with the bugs. But software, like other products, is subject to warranty provisions, which can be stipulated in the project contract. Not to mention that it’s in the interest of most contractors to continue working with the customer. 

Still, it could be that the end user isn’t entirely satisfied with the software and that’s why they keep bringing up new functions and optimizations. This situation can arise if there was only minimal or no change management at all implemented during the project. 

Either way, the result is that the project drags on, while both the customer and the contractor gradually lose their motivation and satisfaction. The costs mount, and, at some point, the project quietly peters out. 

That said, bringing a project to a good conclusion can actually be really easy. The best thing to do is to get an early start on preparing for the close-out; you could also get an early start on the project kick-off. Specifically, I'm referring to the way you talk about how the project acceptance and project close-out will go down. You could also point out the contractual provisions. The sooner you start preparing and the more often you discuss the subject, the less confusion you’ll have to deal with when it comes to the close-out. 

Putting in place an effective system of change management not only helps to reduce resistance in the organization, which makes the project close-out easier – it also lets you redirect energy from resistance to productive purposes. 

Usually, it’s not so much because of the project itself or the contract terms – it’s about the close-out party. These days, people like to skimp on project parties. After all, they cost money, and you don’t get anything in return. In reality, it’s quite the opposite. A team works on something together and achieves a complex and difficult task. If they’re successful, naturally they feel like celebrating their success. We all know what it’s like. When you manage to stick to a diet, you treat yourself afterwards to a steak or a big slice of cake. When you’re done, you feel good – you've rewarded yourself. It’s the same with project teams. They want to reward themselves for a job well done. In all likelihood, they had to work overtime to do it. 

Having a project close-out party is also important for dissolving the social fabric of the project and bringing closure to the participants. The project is over, after all, and the project team will not be working in the same configuration anymore. 

If the project didn’t leave them with very pleasant memories, then the party would be a good way to get that bad taste out of their mouths. Fortunately, it doesn’t always have to be that way.