1. You create elaborate documentation about your software release process. Now you have two things to maintain: the documentation about your release process; and the actual release process itself. Documentation is a way for people to communicate in an unambiguous way about complex topics. But documentation maintained separately from the underlying activity creates yet another legacy.
2. Your production environments are not the same as your test or staging deployment environments. Machines are different, configurations are different, database settings are different, and the list goes on.
3. The software deployment is performed manually. You have different teams each taking ownership of different parts of the problem at a different stage of the process, and making a series of changes to a whole variety os systems in a highly manual activity.
4. Releases take hours or days rather than minutes. You have no reliable way to measure how long the release will take to complete. There are no measures or trial information available for you to make the assessment.
5. Releases leave you in a cold sweat, not knowing whether the release will succeed or fail. The dread of releases creates extreme stress throughout the entire organisation because of the fear of the unknown. Did you miss some minor detail that will cause everything to fail? Will your organisation suffer losses of perhaps millions of dollars as a result? Will furious customers jam the help desk with complaints, or the releases’ failure be splashed across major media outlets? Will you have to explain the situation to executive management, or worse still, the board?