So what do we do with a deployment that has last minute changes that threaten the Project? You know those ones, the business users can't make up their minds, they won't actually sign off on the system and continually add, change and delete features, even though your senior management has set a date for migration. So, here you are at the last minute making changes because someone in operations is insisting that they won't move forward without the implementation, and any margin of error (MOE) you have given yourselves for unforeseen circumstances is gone, and you're praying and begging for everything to go smoothly even though you know it won't. You're going to be late and miss your deadline. So what do you do?
I've looked long and hard at this, and unfortunately, been through this quite a few times, and in an immature IT organization I have concluded that it's just going to happen. However, I think that the best way to manage this is to deal with the delays, communicating the impacts to Time, Scope & Cost at every opportunity. Not only that, but make sure that you are documenting ALL of the events along the way that caused the breakdown, and by whom. You're probably going to get the blame, but at least you can be documenting the issues (and projecting them via e-mail so that you have an audit trail to refer back to) so that when "IT" hits the fan you are prepared for battle.
I think we have to allow for push back and balance. It's going to happen and we can fight it, but there is definitely a point where fighting it isn't going to do any good and will only cause further harm to the project and the team. At that point, which is determined by you an very subjective, you can adjust the focus to the quality of output and do the best you can with the dung on your plate. I see this as waiting for the right moment to fight the battle, and although you have already resigned to lose the fight, you're preparing to win the war. The war would be the goal of organizational change, and maturation of the Project Management process, as well as a great teaching opportunity for the problem players.
So, for you football fans out there, start looking at this situation as a way to gain yards, and possibly get close enough for a field goal. Take all of the chronological information on the: who; what; when; where; why; and how, and conduct a post mortem after the system has finally been released. Make sure everyone knows what the failure points are, and how to avoid them in the future. NEVER conduct the meeting without SOLUTIONS to mitigate the past failures, and outline the “ideal state” as your ultimate goal. Even if you fail, you can use it as an opportunity to gain knowledge as to specifically where the issues are and why they happened, and make contingencies for managing them in the next release. As for the human failure points, define the ground rules moving forward, and make sure that they are communicated to everyone. If there is only one person that can call a “NoGo”, make sure EVERYONE knows who that is. If you need more authority or clout to get it done the next time, either ask for the power, or make sure the person responsible knows you are going to ask them to champion your direction on the next release cycle.
It sucks to miss a deadline, but we all know that most things don't succeed on the first try. If you didn't make the deadline, make sure that you use the information gained from the failure to your advantage, so that it never happens again. I have always been of the thought that if I had to take any kind of a beating it was fine, as long as I got closer to the prize. Figure out where you want to go, and use the past failures to help you get there.
Margaret de Haan