A scientific approach to Cloud Computing strategy development

A scientific approach to Cloud Computing strategy development

Summary: Is there a correlation between the size of the spreadsheet – with larger being better – and the comfort level that executives have?

SHARE:
TOPICS: Cloud, CXO
2

For all the enormous, color-coded, multi-tabbed spreadsheets, and the number crunching, and the analysis, it has been suggested that much of today's strategic planning is contaminated by bias, judgement and opinion. And it most definitely is not scientific.

The authors, in the article Bringing Science to the Art of Strategy, suggest that there is a correlation between the size of the spreadsheet – with larger being better – and the comfort level that executives have in their process.

The process, for me, translates well for the development of a Cloud Strategy. How can organizations be more scientific in their approach to Cloud Computing strategy, or any strategy for that matter?

Organizations need to move beyond simply doing data analysis and strategic planning. The scientific method requires the creation of  unique hypothesis that will be rigorously tested. The authors suggest that if you talk to those managers, “you will likely uncover a deeper frustration: the sense that strategic planning does not produce novel results. Instead they perpetuate the status quo.

One manager put it this way, “There's a reason we keep those ideas outside of the box.

How do we move from keeping novel ideas outside of the box to, “applying creativity to a scientifically rigorous process [that] enables teams to generate novel strategies and to pinpoint the one most likely to succeed”?

Here are seven easy steps to a successful Cloud Computing strategy:

1. Move from issues to choices: Often this is the most difficult step in the process because if you do not correctly identify the issues that you are trying to solve, then no matter how successful the implementation of the strategy, the issue will persist. The trap is that strategic planning tends to be calendar driven and focused on things like "declining profits." Your best option here -- to ensure that you are not just investigating data -- is to convert your issue into "two mutually exclusive options." This will focus the team on what must be done next.

2. Generate strategic possibilities: Once you understand the choice, then you can move to the possibilities that you might consider. Be certain to have a broad enough range of options to ensure an inclusive range of genuinely new possibilities. The status quo ought also to be investigated as there is always the possibility that no Cloud strategy will be adopted.

3. Specify conditions: Ensure that -- for the solutions being proposed -- every one understand what conditions must be true for the specific option to be strategically sound. Moving someone from “that will never work,” to “what would have to be true for me to accept this offering” are completely different conversations. Even a condition like, "a provider must be able to provision a production ready server in under 5 minutes" (which is not really realistic in most enterprises because most employ work-flows that require approvals and such) should be captured at this stage.

4. Identify barriers: There is always someone in the group who is convinced that none of the options are good enough. It is important to ensure that, regardless, you identify which conditions are least likely to hold true. The reasoning behind this is that the research that must go into exploring the viability of a condition may be quite extensive – especially with complex issues; so it is important that you only focus on conditions that have a possibility of playing out.

5. Design tests: For each key barrier that you identify, it is important to devise a test that will be deemed “valid and sufficient” to garner or generate commitment. This ought to be written into the RFP as the tests need to be conducted ahead of product selection.

6.Conduct the tests: When you start to run through the testing scenarios or barriers, it is important to run through the least likely first as the testing process is the most labor and time intensive. This will allow more time for the barriers that stand a chance of making it.

7. Make your choice: Review your key conditions in light of the test results in order to reach a decision. The old approach would have two or three executives, who had already made up their minds, battling it out -- which leaves the skeptics to almost immediately start to undermine the decision.

The new approach simply selects the product with the fewest barriers.

Topics: Cloud, CXO

Gery Menegaz

About Gery Menegaz

Gery Menegaz is a Chief Architect for IBM with more than 20 years supporting technologies in the financial, medical, pharmaceutical, insurance, legal and education sectors. My Full-Time Employer is IBM. I write as a freelancer for ZDNet.

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

2 comments
Log in or register to join the discussion
  • All Hands on Deck

    In my experience, even the best plan/process strategies only give tacit acknowledgement that the entire IT structure may not be at their disposal during a mass failure. How can anyone plan for a managing director unjustly jumping ahead of the queue. Unless there is a huge and immediate monetary loss attached to your project, expected SLAs will not be met. What will your contingency plans be when folks internally won't answer your calls or emails? This applies to your outside vendors since the sales team will be deeply involved in prioritizing which customers get serviced.
    Tired Tech
  • BCDR

    Thanks for the comment.

    In my experience - working mostly with large enterprise clients - is that most organizations who plan for a DR event have a solid process that they follo. But where their plans come off the rails is when they encounter a hardware failure that prevents them from executing.
    gery.menegaz