Software Rollout Worst Practises

Rolling out client software can be fun or a nightmare. One of my early IT experiences was to roll-out software on new computers ( IBM AT to be precise) in universities in the state of Hesse. There was no network, no central software management and no IT manager with an (ill-conceived) plan. As student I got to visit all these universities on a corporate dime which was a cool intern project. And it was a green field deployment, so we had 100% control of the environment. That time I learned a great deal about batch/shell programming and how to succeed or screw-up a large scale roll-out. (They hired me back, so my ratio success/screw-up was acceptable)
Interestingly a lot of the lessons learned there hold true today. So before sharing my best practises for roll-out, let me introduce the worst (in no specific order):

• Don't have a plan! Planning is for wimps. You could get an idea what really is involved and get clarity what is needed. Avoid at any cost software that both helps in brain storming and project planning like iMindMap (the "prettiest" one, nice organic lines), Mindplan (a native Notes application) or MindManager (my former favourite, before I switched to Linux)
• Stick to the original plan! You ignored the first advice and created a plan, now at least stick to it and never adjust or revise it. Worked for the Soviet Union, will work for you
• Don't ask, don't tell! Communicating update plans is sooooo uncool. You business users love the surprise of having their workstations blocked and be confronted with unfamiliar UIs and moved functions. Don't negotiate for a time frame, they never will let you do that roll-out
• Trust your vendor blindly! Your vendor probably has exactly the same environment like you, so the install/update routines will work without you checking them, don't waste time to understand the process. In the same category: you won't find any side-effects since you don't test if the new software runs with existing files / data
• Shoot blindly! There are two important steps: first don't gather intelligence about your targets. Information about CPU, RAM, disk size, available disk space, existing software and configurations only make you uneasy and dent your confidence in the roll-out. If you have to collect these information, at least let the users do that and send it in an eMail or individual text or spreadsheet documents, so you can avoid analysing them because it is "too much work". Secondly make sure your roll-out is one-size-fits-all. Base the roll-out on assumptions rather than fact. Bare minimum assumptions need to be: all machines have enough space, the same version of software is installed and the locations are fixed for software and data
• Don't customise! The default installer/updater will do just fine, any adjustments can be done by the users or helpdesk later on
• Don't automate! Best is to have just a little printed cheat sheet with steps to repeat. If you would automate you would remove our beloved "failure by typo" (OK, the very best: only have an oral history of steps). Also don't use software to push things out, your kids and their friends need that intern job after all. Sneaker network is king. Never ever look at BigFix
• Don't backup! It only takes time, storage space and shows your lack of adventure readiness
• Presume the workstations are alright! Messed up configurations, highly fragmented disks, space constrains or screwed up registries are things that only happen in other companies. And previous patches are for sure properly installed and all software is the latest version. Did I mention: Never ever look at BigFix IBM Tivoli Endpoint Manager
• Don't have a plan B! Don't plan for rollback, restoring of computers or re-imaging of workstations. Users simply need to understand the perils of IT
• Broad daylight is best! Why waste nights or weekends in rolling out software? Do it during office hours. Plan creatively. Sales and accounting love a month or quarter-end roll-out. Engineering prefers their rol-lout shortly before a project deadline. It removed the burden of doing their job when it is busiest
• Data migration? What data migration? Do not account for the fact that files or databases need to be converted. That is the users responsibility. They need to schedule that out of their time
• Big bang is best! Never ever try to do a pilot. Waste of time. Also make sure all installation happens at the same time. After all you need to see how your network and servers behave under extreme load. Big bang removes the need to test transition and co-existence scenarios.
• Most important: Never ever train your users! You want IT to be the talk of town in your organisation. All that angry faces are just misled signs of affection. And your helpdesk wants something to do after all - make sure they are caught by surprise too

I've seen all of the above happening, what did you see?