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:
- 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.
- 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”
Over the next ten working days, this blog will list what I have observed to be the top ten blockers to operating system deployments. My focus for the past sixteen years has been on the Microsoft Windows environment, so my Top Ten List is mainly for Windows. The list is also oriented more toward desktop deployments than to servers, although much of it applies to servers as well. It is aimed at larger enterprises that typically struggle through mass deployments and complain about how hard it is to keep up with the changes in technology.
Although does happen to be Windows focused, I believe what I highlight is likely to apply to any massive deployment, including Apple, Linux and Unix. And I’m already noticing nearly identical blockers when customers attempt to move into the Cloud–because ultimately, the Cloud is about continual, dynamic deployment of services, and nobody is going to get there from here without adjusting old habits.
I’m not saying I have answers to all these deployment blockers, although I will try to give some hopeful “Better Way” advice. But I have been out there for a long time, observing successes and failures, big and little. To me, what is on my list is just our human condition, that is, behavior that is uniquely human, habits which technology alone cannot resolve. Most people call it politics, but I think it goes way beyond that. There isn’t a customer that doesn’t suffer through these blockers—some more than others, but no one has been free and clear, at least in my experience.
Once the Top Ten countdown is complete I’ll dig in with future posts to give deeper details on what I’ve seen contractors, partners, and Microsoft Services do to resist and counter these blockers, what worked, what failed, and the reasons why.
Drum roll please. Let’s roll out Deployment Blocker No. 10.
Hello, my name is Shelly Bird. I’m a Microsoft Solution Architect whose expertise for over twenty years has been deployments of operating systems and major applications. I help customers deploy servers, desktops, laptops, tablets and even phones.
I’m an odd Bird, not only because I’ve been at it so long in this space, working with literally hundreds of customers, but I’ve been doing it mainly with Public Sector customers in US Federal Government. I have worked for almost two decades with Civilian, Military, Intel, and even State and Local Governments.
This is unusual. There are a lot of additional challenges in these spaces due to the sheer scale of government customers: we’re dealing with tens of thousands or even hundreds of thousands of devices. Also, this kind of customer is extremely focused upon pursuing privacy and security, to a degree rarely found in the commercial space. So I’ve had to learn host security at a level of depth not normally encountered in an infrastructure consultant.
I’m launching this blog for one reason. Much as I love the geek blogs that give us great scripts, great tools, and terrific advice on the latest way to streamline and strip down the deployment to the minimal number of steps necessary, I see a huge gap out there. I see people making their deployments—and their lives–a whole lot more difficult than they need to be.
Customers often don’t understand the real reasons why deployment of a new operating system or application is frustratingly slow. They sometimes miss the fact that most of these reasons have little to do with the features of the products, the bells and whistles of deployment technologies.
Deployment has a lot more to do with psychology and turning large ships, because ultimately deployment is about change, and while change can be good, it is not always welcome.
I want to tell deployment stories. I want to show how customers made it through major deployments, the kind of events that transform an enterprise. This blog will give insight into what I and some of the brightest deployment consultants in the world have seen work and fail–and why–over the years. The hope is readers will pick up information that will help make more deployments succeed.
Finally, I’m deliberately aiming this at decision makers, the “non-geeks” in many of the blogs here, because most of our current deployment blogs are more technical than process and people oriented. And as stated above, the biggest challenges don’t really come from the technology.
One final note: if you are a former customer, and think you recognize yourself in certain descriptions, please think again. I am choosing situations and behaviors that I’ve seen over and over again; ones that are so ubiquitous I now regard them as a human condition. Take comfort in the fact you are not alone.