Posted by: Jason Tramer
IT best practices, project management, project planning
When implementing a new project one can never downplay the important of a solid plan of attack, this is especially true for those of us in the consulting field but even if your not, having a solid well-documented plan can protect you like a magic cloak if things turn south. So here are some best practices:
1) Put together a Statement of Work before you even start that details the entire project plan and run it by management for approval. IT managers love this stuff, it makes your look good and it makes them looks good when they bring it forth up the chain. Even if the high-ups a) don’t read it or b) don’t understand; they will still be impressed that you put one together. If scope creep occurs (and it will) you can point back to your original plan and indicate that you need a change request for it. You will thank yourself later for being that anal when you are later questioned on why the project a) took longer then originally expected b) cost more then originally expected; and you can reply by pushing over a stack of signed change requests, nod politely, and smugly leave the room.
2) Make the change first in a dev environment. If you don’t have a dev environment, ask for funding for a dev environment, draw up a long email on why dev environment help mitigate production problems that can cause outages. If you do not get the funding, save the email you got back denying you your dev environment. If later something bad occurs with your change and people are looking for someone to blame, divert attention away from yourself but stating that the issue would have been caught if you had a dev network to test changes on, keep a copy of that email in printed form with you at all times for the next few weeks for it shall be your magic shield which matches your cloak very stylishly.
3) If your change effect’s end users in the slightest, have a User Acceptance Training and Sign Off portion. If in the worst case scenario if an issue was missed and pops up in production and you are asked why you didn’t catch this during testing, you can quite rightly point out that the user’s didn’t catch it either and that it’s quite normal for small issues to wriggle through despite rigorous checking during the UAT phase. The UAT groups in this meeting who didn’t bother actually doing any testing and just signed off their names because they couldn’t be bothered to put in the effort will latch onto this idea that it is in actuality no one’s fault and defend it to the death, if only to avoid any scrutiny on their side.
Successful project planning is all about covering your butt, the better that it’s covered the happier you will be. Worst case scenario, if all the above doesn’t work then just blame the guy who doesn’t speak very good english.