<img src="https://secure.leadforensics.com/51024.png" style="display:none;">

The Worst Pieces Of IT Transformation Advice We Have Ever Heard

We all know that hindsight is always 20/20. There is probably nothing more frustrating than realizing that you just made a huge mistake, and then looking back and realizing that you should have known that that was a bad idea. But sometimes, we also receive really bad advice that overrides our gut feeling or better judgement.

Whatever caused the misstep, we all learn from mistakes — but it's always easier to learn through someone else's mistakes. So, we compiled below the worst pieces of advice we have ever heard on the topic of managing an effective IT Transformation. This way, if you hear one of these common myths, you'll know to be wary of it and consider it twice.


1) Transform Everything In One Project (Boiling The Ocean)

One of the biggest obstacles to effective IT transformation is technical debt that organizations have been carrying around from migration to migration — hoping to clean up at some point. Because migrating to Windows 10 means you are starting the upgrade clock on bi-annual or yearly upgrade cycles, many IT managers think they have to solve everything with their initial move to Windows 10.

Usually, it doesn't start out with the intention to "Go big, or go home". These projects start with a dedicated team and budget and have a well-defined scope, but once you are knee-deep into analyzing your estate, you realize that

  • The majority of your devices are close to reaching their end-of-life or out of warranty and would benefit from a hardware refresh.
  • Your application estate is much more of a mess than you realized and you need to weed out or retire unused, outdated, and unlicensed applications and, while you are at it, implement a full-blown application lifecycle management system.
  • You want to move to VDI and virtualize all of your applications without really knowing if your environment is suitable for it.
  • Your desktop management infrastructure is outdated and needs a complete overhaul, which kicks off another number of required infrastructure upgrades.
  • You discover a bunch of "stuff" out there that needs fixing as a dependency for the migration that you did not have in your original scope (e.g. software licensing)

Those are just a few examples, but you can already see how your project starts ballooning into something way beyond the original scope, budget, and resource capacity.

Consequence: By bundling everything together rather than separating different components to create successful projects, you set yourself up for failure right from the start. While piggy-backing a hardware refresh on top of a Windows 10 migration might make sense for your unique situation, this will need to be scoped out and properly budgeted/planned for. It's all about balance and proper planning.

How to avoid it: One of the most valuable lessons we have learned by helping to ready more than seven million devices for migration is that a thorough analysis of your estate is the key to success. You need to understand what you are dealing with first before you can decide on how you will manage it (and what you will need to do so). In addition, we have found that it is much easier to get executive management to approve a higher budget based on real analysis and insights before the project starts than to get an increase to rescue a failed mission.

2) Get Numbers On The Board Fast Without A Proper Process And Strategy In Place (Show Progress, Even If It's Not The Right Type Of Progress)

You just got approval for your IT Transformation project and are pumped to get going. You know the first three months are absolutely crucial to show your important stakeholders that your project is moving forward as planned and you were able to produce some big wins early on in the project. It's only natural to want to get numbers on the board fast!

But we have seen this too many times: large organizations rush into deploying as many pilot users as possible without having their strategy, methodologies, or project frameworks and processes properly defined. It is crucial to understand that a fast start doesn't mean you are necessarily running it efficiently and well. even worse, you could be creating a bunch of technical debt to fix later.

Consequence: Many organizations guilty of a flying start ended up having to go back and redo the migration for those early pilot users because they did not deploy the right thing (e.g., they are now running different flavors of the target state) or it contradicts the later-defined upgrade process. This not only drains your budget unnecessarily but also sets you back in your progress and keeps your resources from working at optimal capacity.

How to avoid it: To avoid jumping the gun and having to go back and redo everything, make sure you go through the Plan for the Plan step in your project setup phase. Always have your overall migration strategy in place and your transformation process defined before starting small incremental waves of change.

Click here to download the Windows 10 Project Plan Template

3) You Can Never Over-Analyse A Project (Analysis Paralysis)

While some projects fail due to a lack of strategy and analysis, we have also seen projects fail due to analysis paralysis. Some project managers want everything analyzed upfront, to rationalize every app, and to get every app ready before moving on to the next step.

Consequence: Unless you have very few users, devices, and applications, you will never get out of the analysis and pre-deployment phase. There are so many dependencies and variables that it is close to impossible to have everything sorted out and ready to go before deploying the first users.

How to avoid it: The secret to successfully deploying is to do enough analysis to be able to prioritize the first streams. As you work through the first batch (e.g., a large batch of users that use low-impact, compatible apps that are ready to go with minimal packaging and testing), dependencies will start to resolve on their own. With each iteration, your batch gets smaller, yet more complicated. This way, you get the low-hanging fruit right away and deal with more difficult users later.

4) Target As Many Friendly Users As You Can

Traditionally, the best practice was to go to all of your business users and ask them for a list of users willing to serve as early adopters, the so-called "friendly users". These end users were open to migrating to the latest version as early as possible and providing feedback, reporting bugs, and so on. However, experience has shown that this approach does not return the benefits you might expect.

Consequence: Often, those users are not testing the majority of what you need to test, or their environments might be more complex than the environments of other users that you might have been able to migrate earlier on. Additionally, they often will not test everything thoroughly enough and, consequently, will sign something off as okay when it is not because, as early adopters, they are used to a lighter level of testing. If we had a dollar for every "key user" that we have interviewed that actually has no real clue on what they were actually signing off on, then we'd be very rich indeed.

How to avoid it: This concept is quickly becoming outdated with the wider adoption of Evergreen IT. With the proliferation more sophisticated tooling that allows centralized analysis and real-time insights into your current state, it is much more efficient to mathematically prioritize those machines that give you the widest range of application testing (and therefore the most velocity) and add in some of the users specifically assigned to those prioritized machines. By using empirical data and mathematical analysis rather than historic processes, you are much more likely to achieve a highly successful, low risk IT transformation or migration.

5) Deploy Your IT Department First

This piece of advice might be a little sour pill to swallow, but targeting your IT department as the initial pilot roll out is not a great idea for three reasons:

  1. The IT department is always the most complex department in any organization when it comes to applications installed, etc.
  2. A lot of the apps installed within the IT org are not used anymore or not widely used throughout your business units.
  3. They are also the most likely to not test things properly, or even really understand how the applications are used in the wild.

Consequence: Starting your project off by migrating your IT team first won't get you very far in regards to moving your broader business user deployment along. It simply gives you a very inefficient start to your project because you are having to do a large amount of work to migrate a relatively small amount of users who are not adding a lot of value to the data that you will gather.

How to avoid it: Like with the friendly users, you'll be much more effective if you mathematically determine the machines that will get you farther, and then find early adopters in that list. This way, you achieve maximum velocity but with a useful set of test and process data that you can use to drive the project forward in an effective manner.

6) Use This Project To Modernize Your Entire Estate

Another phenomenon we have seen is the setting of artificial targets based on assumptions or objective goals. For example, claiming "75% of our state should be virtual" is setting a target without prior suitability testing and could easily backfire.

Consequence: Not every application is suitable to be packaged to App-V and not every user environment lends itself to being moved onto VDI. In this case, often the complexity of building out infrastructure, rebuilding and (over)packaging applications far outweighs any benefits of going virtual. Without proper analysis, enterprises find themselves shoehorning physical machines to become virtual and spending significant time packaging applications for a platform they really are not suitable to run on. This can significantly reduce performance, which will slow down end users and ultimately throw off your return-on-investment.

How to avoid it: The lesson learned here is to not define your outcome before you have done your analysis. Or, in other words, make the right decision rather than a popular, but assumptive decision.

7) Upgrade To Shiny New Infrastructure

If you have talked to any Microsoft sales rep lately, attended Ignite, or seen the latest marketing material, you probably know about Microsoft's enterprise push towards its Modern IT Vision. This includes new, shiny infrastructure like its Microsoft Enterprise Mobility + Security (EMS) suite including Microsoft Intune, Azure Active Directory, and Azure Information Protection, as well as Office 365, and the Microsoft Store for Business.

Consequence: We have seen some enterprises trying to move all their devices on MDM as part of their Windows 10 migration. This is particularly bad advice as the platform (in our opinion) is not quite yet ready for full enterprise device deployment and it will take a massive amount of work to get there. Even in the Ignite sessions in Fall 2018, Microsoft's customer success story included only customers that have migrated very few users in the pilot phase in a hybrid Co-Management approach.

How to avoid it: Start evaluating these new platforms once you have finished your initial Windows 10 migration and you have a scalable and repeatable Windows-as-a-Service management project framework in place. Then, and only then, start inching slowly into this uncharted territory by moving a few users onto the new platform.

8) Outsourcing Will Solve All Your Migration Problems

Last, but not least, let's talk about outsourcing. Outsourcing is a great option for some enterprises that don't have the internal resources or skill set to handle IT Transformations of this magnitude or on an ongoing basis. Your outsource partner has best practices and skilled people who probably have done this before. But they don't know your environment and they will take time to get up to speed.

Consequence: Whenever you shift a problem to someone else and expect them to handle it efficiently, you are assuming a certain level of risk. The same is true with outsourcing. You need to allow your outsourcing partner enough ramp-up time and to plan on providing plenty of knowledge transfer and support to get them up and and running. Also, consider that procurement processes can take months, especially once they get into the contract phase.

How to avoid it: Outsourcing is not always the silver bullet, but it can be very successful in the long-term, if you give your chosen partner the right support to achieve the combined goals. However, before you sign the dotted line, be sure to exactly understand the issue you are trying to solve. For more information on how to set yourself up for successfully outsourcing your migration, read this article.

Have you gotten a piece of bad advice with regards to managing large IT Transformation projects that you would like to share with us? We would love to hear from you in the comments.

New Call-to-action