Successful migration to the cloud is not as simple as a direct “lift and shift” of your existing technology over to the cloud. Without a clear strategic rationale or motivation you may well end up with a more expensive -- and possibly less performant -- service than you started with.
When electric motors started replacing water driven mills (or steam engines) as a power source for factories, the electric motors did very little to improve efficiency or productivity. The reason why this new-fangled technology did not increase productivity was that the fundamental design and layout of the factory did not change. The replacement motor continued to power the same belts and pulleys system designed for more primitive technology. It took literally decades for things to change: for example, for folk to realize that factories no longer needed to be located near a water source and could instead be built close to more important resources, such as roads or cities. New factory designs emerged over time as well. Rather than using one big motor with belts and pulleys to distribute single-source power around the factory, factories embraced the more efficient approach of having multiple smaller motors located near each task.
There are interesting parallels between the adoption of electric motors and migrating to the cloud. To extract the biggest benefit from the cloud, there’s a pretty good chance you will need to redesign or evolve your current service to take advantage of this next-step tech.
So then, how do we go about migrating to the cloud?
Migration and Management
“Strategy” is a much abused term. Fundamentally, though, it means knowing where you are, identifying where you want to be, and then figuring out how to navigate between the two.
Thus strategy is a vehicle for delivering change, and project management is a form of strategy. Well-run projects are about understanding where you are, knowing where you want to be, and planning the execution to get there.
So: we can consider cloud adoption and migration as basically a project to be managed.
Over the last 20 years I have run, and been an executive sponsor of, a wide range of complex projects. Some seemingly complex projects turned out to be trivial and were delivered with faultless execution whilst other supposedly simple projects turned out to be treacle and quicksand. Why was that? Well...not all projects are the same.
One of my favourite project concepts is from Professor Eddie Obeng’s book All Change!: The Project Leader's Secret Handbook, which provides a model for classifying projects by type. Eddie introduced an incredibly simple map to allow you to figure it out. I love the idea so much that I’ve extended Eddie’s concept and overlaid project methodologies on top of it.
Here is Eddie’s original map:
Painting By Numbers are those childhood picture kits where you match the numbered paint colors to corresponding numbered areas on the pre-printed canvas. It’s a very simple, almost foolproof, way to create a painting.
Fog is pretty self explanatory. If you are unclear about What needs to be delivered and you’re unclear about How to deliver it, then you are lost in the Fog.
A Quest or Crusade is where there’s a strategic desire to achieve something, and clarity about What is high -- while at the same time, How to actually deliver it is not clearly defined. These can be “boil the ocean” type projects if not controlled.
The Making a Movie category has low clarity for What whilst clarity about How is high. The idea being that everyone knows the basics of how to operate a video recorder, but that’s not the same as knowing how to make a movie. The same equipment can be used to create a Hollywood blockbuster, or an amateurish home video.
Looking at my previous projects using this map, it turns out the ones delivered with faultless execution fell into the Painting By Numbers box. These projects had high clarity about What was required. The fact that the organisations involved had prior experience delivering similar projects meant that How to deliver the change was also clear.
Mapping Cloud Migrations
So let’s come back to Cloud adoption and migration. Companies that have successfully migrated to the cloud usually have an existential threat that is driving them then to act. So how does it fit into the matrix?
Quite often, the Existential Threat is an event that changes the business paradigm in a major way. Kodak, for example, recognized early on that as the world was changing to digital photography, they needed to change as a company - this was their existential threat. The problem Kodak had was, while they were crystal clear What change needed to happen, they were unclear regarding How to do anything about it.
At the other extreme, there are companies that simply declare “We must move into the cloud!”. The rationale or motivation for doing this is unclear, and desired outcome from the migration is undefined. I can just picture those water mill owners demanding the adoption of electric motors in their factories. Blindly adopting cloud without a plan considering “What” will usually result in failure.
Project Methodologies
So finally back to project methodologies. Waterfall is often seen as an unfashionable project methodology, yet it can be extremely effective. For example: if you’re planning to build the Hoover dam or put man on the moon, you really only get one chance. It would be extremely expensive to use a recursive Agile approach, demolishing all failed attempts to ultimately build a proper dam.
I mentioned earlier that I have built upon Eddie’s concept, and below is how I see project methodologies fitting into the map.
The Waterfall project methodology works well for Painting By Numbers projects. Often these projects are predictable with few real risks. Now our “build the Hoover Dam” project may not fall neatly into the Painting By Numbers box. There may be a huge number of uncertainties such as the underlying geology of the area resulting in complex civil engineering solutions for piling. It could be we discover that we need a step change in concrete technology. Maybe there are huge logistical challenges in getting the construction materials to the site. There’s nothing in the Waterfall paradigm stopping us using Agile project techniques for these sub-projects where there is uncertainty, while still using Waterfall as the umbrella for the project.
Six Sigma is a statistical and project tool box, a set of techniques and tools for refining any process to eliminate defects. Though I personally don’t consider it a project methodology it can be used on projects. The original Six Sigma’s roots lie in manufacturing environments requiring strong consistency and predictability. In batches, the product (What) from the factory is expected to be consistent, and the performance of the factory (How) is expected to never vary. In reality, however, there is always variation in the process and resulting output, and Six Sigma arose as a way to identify and minimise the inevitable variation.
The core of Six Sigma is that it you are usually clear about What you are making and also clear about How you are making it. Thus it fits quite nicely in the Painting By Numbers box.
Since Six Sigma is a toolbox, you can indeed apply its tools to the other boxes -- but it does tend to lend itself best to Painting By Numbers.
So how does Agile work with our Crusade or Making a Movie boxes? Well, Agile lends itself to the experimenter model. Meaning that, if we have uncertainties about the What or How of a current project, we can use Agile to make small bets which we can learn from. These learnings create greater clarity, which thens allow us to move toward a box with a stronger foundation. in other words, these small bets help reduce project risk.
In Case of Fog
And finally I will cover the box which I’ve been ignoring...The Fog. Fog can be a confusing and disorienting state, and this box is no exception. My top tip is avoid being in this box altogether. However, despite best efforts you can still end up in Fog. I once experienced this with a project with the directive “To be the most highly regarded company.” This project was utterly unclear about What was to be done, and it was unclear How to even get started. The deliverables were most definitely neither specific nor measurable.
If you are unfortunate enough to find your project occupying the Fog box, the first thing is to try and get the project owner to paint a picture of What it actually means. If clarification does not work to move the project from the Fog into another box, then Agile can be useful. Use an Agile approach to deliver small experimental chunks of change which fail fast; each time you can then engage with the project owner to evaluate “is this What you want?”.
So in summary we can use this powerful technique to help ensure a successful migration to the Cloud. By figuring out where we are on the map, we can if necessary take deliberate steps to move into a better and more appropriate box -- one with a more stable foundation.
Interested to know more about going Cloud Native? Download our free eBook below.
Previous article
