Have you ever been part of what seemed to be a never-ending project? Come on…admit it. No matter how hard you try, some things are just outside of your control. Or at least partially outside of your control. No project manager likes to admit that they aren’t in complete control, but it’s a fact. The team has a mind of it’s own. The customer certainly is working on different timetables and with different constraints and assumptions. And the project itself seems to be a guided missile being manipulated by some outside entity at times….a juggernaut that seems to not respond to your guidance during the most critical of times.
So, you going down the road toward project completion and you think you know when your project will be over. It’s all planned out in the project schedule, right? It’s straightforward…deployment is deployment. It’s not rocket science. Well, actually, sometimes it is. Here’s the scenario. Have you ever had that project customer that goes through acceptance testing and finds some glitches and they won’t signoff on the project? I’m not talking about huge things…they could be small. The problem is, they are vaguely either just inside or just outside the project scope. The issues that are outstanding really aren’t addressed by the scope of the project – but to the customer they are important. Initially, you do everything you can to meet their needs because at first glance these things don’t seem that big. However, as you work to tackle these issues and your team is struggling, it becomes apparent that resolution is going to take longer than anticipated. Hours turn into days, and days turn into weeks. Seriously, this happens. And it’s painful. And it seems like a two-headed monster. It can turn a customer who has been an ally to this point into an opponent who won’t signoff on deployment or a final invoice and now frustration has set in.
Could this have been avoided? Are there processes that could have been put in place at the beginning of the project to avoid this mess? Maybe, maybe not. What needs to be done on a project-by-project basis in order to hopefully avoid this mess on future projects is this:
Hold a proper kickoff session to set customer expectations
I don’t care if it’s a small project and it’s just the project manager and the project sponsor on the phone together, hold what is understood as a true project kickoff and set expectations. Go over milestones, discuss how the project will be managed and agree on what the scope of work should be.
Cover formal signoff procedures
Next, discuss formal signoff procedures and what is meant by ‘acceptance’ of a deliverable and – ultimately – the final solution at deployment time. You certainly don’t want to get down to the 11th hour of the project without this process in place.
Ensure you have a post-implementation support structure in place
The final piece of the puzzle is to ensure that you have a proper support structure in place for your customer. If your project customer knows your team will be around for, say, 30 days, to help support any short-term post-deployment issues then they will be faster to signoff on the final solution even if there are some remaining small issues. Likewise, make sure that your support organization has the proper project info to adequately support this customer – it will definitely instill additional confidence in your customer to enable them to give you that final signoff without the worry of abandonment.
The bottom line is that there’s nothing you can do to ensure that you positively will never experience these frustrating situations. However, if you have signoff and support processes in place that your customer understands, then it might help them to let go of the little things when it comes to final solution acceptance.
About the author: Brad Egeland is an IT/PM & Business Strategy consultant and author with over 25 years of software development, management, and project management experience. He can be reached at firstname.lastname@example.org or you can visit his website at www.bradegeland.com.