This is essentially a discovery and analysis exercise that
most of the times can be split into two different perspectives or areas of
focus: Business and Technical. As a rule of thumb, I always think of these six
questions:
What? E.g. what’s in scope?
How? E.g. how is IT run?
Where? E.g. where are the customer sites/facilities?
Who? E.g. who is involved?
When? E.g. when should the transition be completed?
Why? E.g. why migrate to the Cloud?
The following paragraphs cover some (not everything!) of
what to look for when asking and answering these questions.
Business Assessment
I often engage CxO executives that couldn’t care less about
how sexy my Cloud solution looks like. As I keep saying, Cloud is never the goal.
Cloud is a means to an end. Customers know that as well and therefore all they
want to know is if my proposition makes business sense and more importantly,
how exactly can they benefit from it.
With regards to Programme Governance, I normally start by
gathering the requirements. I can’t
stress enough how important it is to get the customers’ requirements right, as
this will make a huge difference between an assessment that is either too
shallow or too thorough (not to mention it can obviously compromise the success
of the project). Cover what the customer thinks of their own functional/non-functional
requirements and needs but consider complementing it with your own view. Some
customers are less familiar with some aspects of the Cloud so it’s likely they’ll
count on your expertise and background to complement their vision.
Another of my initial concerns is to establish roles and
responsibilities, both from the provider and the customer side. For this I normally
use a RACI or RASIC matrix. Sometimes this precedes the requirements gathering
as it’s a natural evolution from the people’s introductions.
It’s also very important to understand what are the goals
and business drivers to consider Cloud as an option - this will most certainly
shape the Target State Environment and potentially the Transition Strategy. I
find it fundamental to learn about the customers’ business model and strategy.
What is the customer aiming to achieve over the next 3 years? Are there any
known pain points? What is IT importance within the business? I also look for
compelling events, such as a lease on a Data Centre building that is about to
expire or a server infrastructure that is rapidly approaching EoL. I try to
identify any quick wins as these tend to increase the level of confidence in
the project, which is often very useful in the project’s early days. I also try
to think outside of the “Cloud box” and be watchful for any opportunities for additional
optimization. I always aim to get as much tangibility on the targets as
possible, however some customers will state vague goals like “reduce
operational costs”. To my view, this doesn’t help me to realize how success will
be measured. I’ll often ask by how much? Are there constraints, budget, time or
otherwise? Is there a preference for a CapEx or OpEx model?
Don’t forget the all-time favourites: processes. I don’t think
I can say I know my customers’ business well enough until I’m aware of their
relevant business processes. I typically enquire about assets related processes
(e.g. procurement, provisioning, decommissioning, etc.), operational processes
and project control processes to name a few.
Invariably, a lot of the business assessment will focus on
financials. Remember, exec sponsors will be putting their budgets on the line
so the business case and consequently the figures need to stack up. For some
techies, this might pose a challenge, so hopefully this and my following posts
on the subject will be of some help.
As the simplest of tactics, it’s important to understand the
current TCO and if there’s a target TCO or a target ROI (I have TCO/ROI models
that I can share if you need). Find out all you can about budgets, from the
overall IT budget to the project’s. Ask how does the business fund IT? Other common
KPIs may be of importance, such as inflation, depreciation, payback period, hurdle
rate, Return on Assets (ROA), Net Present Value (NPV), Internal Rate of Return
(IRR), amongst others.
All of the above are often elements of a Project Initiation
Document (PID), which in turn is part of the Programme Governance
Documentation. A PID may also include sections that cover information such as contacts,
scope, deliverables, risks, assumptions, constraints, KPIs, project controls,
etc.
Technical Assessment
Cloud wouldn’t exist without technology and therefore there
needs to be a technical assessment, which normally follows the business assessment.
One reason for this is that by the time you start looking at the techie bits,
you should already have a good understanding of how IT relates to the business.
In my opinion, migrations to the Cloud should be application
orientated so if you think the same way, ensure applications are at the centre
of everything you do.
Starting with infrastructure, it’s important to understand
what is out there. I try to learn everything I can about the estate, from sites’
geographical dispersion to percentage of virtualized systems to the specs of
every piece of physical and virtual hardware. Most customers have this
information relatively up to date, so I often tap into CMDBs, existing
documentation, run workshops/interviews, anything that can assist me in
building a detailed Current State Design. If possible and applicable, I’ll extend
my time horizon, i.e., don’t focus on the present only and analyse growth and
any capacity plans.
Customers should also provide information on how is the
infrastructure being utilized, i.e. how are systems utilizing resources (e.g.
CPU, memory, disk, I/O, etc.). Unfortunately is less frequent (from experience)
when I can get hold of information about how are applications utilized. It’s common
to find CMDBs that provide information on what software is installed on which systems
down to version and patching level, however this is not sufficient to design a comprehensive
End State Environment and/or an effective Transition Plan. As a few examples, it’s
imperative to determine relations such as:
-
Application-to-business mappings: which
application maps to which business process, and how critical it is to the
business (usually indexed to revenue );
-
Application-to-infrastructure mappings: which
infrastructure components are required to be operational in order to guarantee application
availability (from the servers where it’s installed, to the switches/routers that
provide network connectivity);
-
Application interdependencies: which
applications communicate with which applications (from typical 3 tier
dependencies to authentication requirements)
Information like the above will also allow defining the transformation
approach for each hardware and software component to be transitioned to the
Cloud.
Conclusion
I’ll be writing further posts on both Business and Technical
assessments, to deep dive on these subjects and also to share some ideas on
tools and templates to use, so if this interests you, watch this space!
As a closing thought, don’t expect this post to exhaustively
cover all that needs to be assessed in a migration project, or that aspects
covered will always apply to any migration project. Instead, this post is
intended to provide an overview of common aspects to be aware of, a spark to
trigger new ideas in your own mind and enable you to explore even further.
PS - By the way, once those new ideas start popping, make
sure you come back and share them with us J
