Skip to content

October 15, 2011


Deployment Blocker No. 10: Deciding to Wait

by Shelly Bird

The decision is made.  It’s a go.  The deployment will proceed.

But hang on: there is so much to worry about.  Let’s wait.

Waiting always seems safer than actually executing the decision.  Some bad reasons I’ve heard are:

  1. Wait for the next big update, such as a service pack or a newer version of software, because the bugs will be shaken out by then.  This might have been a good strategy a decade ago, but with Microsoft’s early adoption programs and Release Candidates (RC1 and 2 normally) going out to production networks for months ahead, RTM (Released to Manufacturer) 1.0 code is a lot more mature than it was fifteen years ago.  So waiting for a service pack is rarely a good excuse now. Cycles of incremental upgrades are going faster and faster, merging into a blur of ongoing deployment, especially with virtualization and the cloud.  The paradigm has shifted.  So should you.
  2. Wait for every application in the environment (mission critical or not) to be compatible.  Good luck with that, especially with Line of Business applications.  A better approach is to figure out which applications absolutely need to be moved to the new operating system.  Research their compatibility with the manufacturer and start testing, in order of priority, those that are still not clearly compatible.

My customers are usually pleasantly surprised at the good news they get regarding compatibility of their outlier applications with Windows 7.  They are always stunned at the number of “have to have” applications that drop off the list once they seriously prioritize and ask stakeholders to provide installation files.

There are hundreds of other reasons offered for waiting but I rarely hear a good one.

The better way:  Don’t wait.  Be firm, set a clear deadline, and drive like heck towards it, using testing to prove it out in production and to get those early wins.  Keep knocking down blockers one by one; make the groups that cannot move to the new Operating System the exception, not the rule.  Get complete backing from the most powerful executive you can find, because you are going to need it.

This is part of a ten part series of blogs “Top Ten Deployment Blockers”

Read more from Deployment, General
2 Comments Post a comment
  1. Brucelan
    Oct 17 2011

    I think one of the worst part of the “let’s wait” plan is that usually nothing is happening during the waiting period. If you have an enterprise application that you must remediate, or a comprehensive security review to complete it may make sense to wait. Having said that, I typically find that most customers that have fallen into the “let’s wait” trap end up just parking their efforts and are thus no more ready when they try the next time.

    Even worse are customers who continue to update an older version of the software. For example, I recently worked with a customer who was working on “release 11” of their Windows XP image. What possibly could they be changing in Windows XP considering there are now two subsequent releases of the OS? Wouldn’t it make more sense to use those same resources to deploy a current OS like Windows 7?

    • Oct 18 2011

      Even when an enterprise application is blocker, unless it is mission critical and must run absolutely everywhere, one can usually deploy to some systems, to other users in the enterprise. At least start the process, to show the intent to migrate is dead serious. Deciding to wait signals to users that the company is not really supportive of the migration to the new application or operating system.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Note: HTML is allowed. Your email address will never be published.

Subscribe to comments

%d bloggers like this: