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

Why Mr Spock-Business Analyst Is Crucial To Windows Migration Success

In any large scale end user migration project, there will be a huge amount of data to slice, dice and rationalize. A mountain of it in fact! At Juriba, we often get asked about the best way to make good use of all that data. After all, our Dashworks software is designed to bring together many different sources of user, computer, application, departmental and location data, so we should have some idea! Having a central data warehouse is the first step, but it is the intelligence you apply to this data to make it into actionable project information that is the critical piece for accelerating your migration.

Previously I wrote about how your migration plan is illogical (link). Now, let’s imagine how Star Trek’s Spock (if you are in your 40’s, or Data if you were into the Next Generation) would have approached your migration project. Spock would focus on the desired outcome for the migration; namely that you are delivering it in the quickest, mathematically driven deployment time. In order to achieve this, Scotty would need to provide the engineering to support the required deployment and logistic outcome.

juriba

Now let’s run the same scenario, but this time Scotty (a.k.a your engineer) is the only crew member available. Captain Kirk takes an emotional decision to deploy department A first because he has no good data available to make an informed decision. Scotty engineers the process to deliver to this department. What is the likelihood of this being as successful as approach one? Unfortunately, not that likely. Because Kirk often choses the most complex department, and engineering alone without prioritisation and scheduling is a fundamentally flawed approach.

Ask yourself … how many of our project decisions are based on the heart rather than the head? How many are based on fiction rather than fact? And what was the result of those decisions? I suspect that in most instances, the answer is that they didn’t achieve the required outcome, or at least certainly not within the expected timeframe or budget.

The dilemma for any project manager is that they need to get deployment numbers on the scoreboard. The challenge is that to get to a realistic deployment schedule, Spock needs time. He needs time to get the data to the point at which he can deliver the maths. Practicalities of the desire to make ‘any’ decision are in direct conflict with any strategic, data driven actions. Rather than looking at the wall and figuring a way around it, our choice is often to keep trying to break through! As a result, the headless chicken quite often become a valid project team role. Your challenge is not to get stuck in analysis paralysis – finding the right timeframe to prioritise whilst still focussing on delivery.

As an example, we were involved in a huge previous Windows NT to Windows XP migration in 2004. We had three regional teams, and our US team started like a proverbial house on fire. They got a load of numbers on the scorecard. We, in EMEA were way behind. Why? Because we wanted to take time to get the strategy right. It caused much consternation amongst the management teams and questions were being asked why we were so far behind. But over time, guess what … well not only did EMEA deliver the project quicker, the US also had to re-deliver those initial deployments because everything had to be changed after realising the initial solution didn’t scale.

Deployment-Graph

Unfortunately, too many projects (not just migration projects) look like the brown line. So how did we achieve our blue line in EMEA? The answer, to start prioritising everything properly. In other words, we spent time on getting our data analysis right. We cut, sliced and diced that data and trusted and relied upon it. We spent time focussing on apps which would give us the greatest number of green users. We engaged the businesses so that we could run multiple deployments in multiple sites concurrently without needing huge additional resource. We added Windows XP as the default for new joiners. We ensured that any break/fix rebuild involved the user being migrated, not replaced back again if the user was in fact green to go but not yet scheduled. We built a just-in-time methodology for hardware delivery to give us flexibility. We investigated every possible way that we could accelerate the migration using tangible, actionable data.

The key to this – our business analysts. The right business analysts. Clever people that understood the data and made great decisions based upon it. We need you Spock!