Planning a cloud project: winning the trust of the line organization

If IT carefully assembles the right planning team, and the team plans carefully and candidly, the team can vastly improve the probability of a successful implementation — and avoid costly and time-consuming rework.

Based on the large and growing number of cloud implementations over the last few years, IT is learning some valuable lessons about how to successfully plan a cloud project and how to avoid catastrophe. This article summarizes the most valuable lessons.

Who belongs on the planning team?

Cloud projects can range from the very small (a departmental project, financed on a credit card) to the very large (conversion of an Oracle implementation to a cloud structure, requiring CEO approval). Compare this to a construction project: It takes only a few people to build a house, many more to build a hotel, and many more than that to build a skyscraper. Your cloud project will require different expertise depending on what you’re moving, what hardware it’s going to reside on, how secure it needs to be, what sign-offs and approvals are necessary, and the budget available.

However, generally speaking, here are the people who should be on the planning team:

• Customer: The person or persons who will be using the cloud, often line managers (line-of-business managers).
• Provider or providers: The internal or external service providers, technology providers, or IT organization.
• Finance: Certainly for a large project. On small projects, line managers may be able to finance the costs on their credit cards, bypassing the finance department.
• Compliance: Sometimes line managers bypass compliance, too; they are looking at cloud as a way to get around rules, not to follow them.

All the key parties should be involved to ensure success.

Obstacles to good planning

One obstacle to good planning is fear. Every group and almost every person on the planning team may have an unspoken fear. For example, an IT organization might feel threatened by an external cloud project because it looks like outsourcing, which removes control and budget from the IT organization. A line manager might resent a forced private cloud over a public cloud because it looks like a power grab by IT.

You have to build trust by reconciling and defusing these fears. If all the parties can reach a high degree of trust on the front end of the project, there’s a much better chance they won’t be fighting on the back end.

Another obstacle to good planning is a lack of communication on the front end. For example, one company hired a software consulting firm to plan and implement a cloud project. The consultant was inexperienced; he spent fifteen or twenty minutes talking to a few salespeople — and did no further research. Then he spent a year drafting a plan and implementing it. Because the implementation did not reflect the company’s real needs, it was completely unusable. The company brought in another firm. The new firm had to discard everything, redo the research, write a new plan, and implement the plan — adding another year to the project.

Measure twice, cut once

In your planning, follow the carpenter’s motto: “Measure twice, cut once.” In the construction business, people often get impatient during the planning phase. They figure they can gain some time by beginning the execution while they plan. But they soon discover that they have to redo a massive amount of work because of something they had not fully thought through. And, of course, they run over budget.

If the work is going to be outsourced, the danger of starting work too early is even greater. For example, many companies give contracts before they can coherently state what they want. So the vendors have to guess what the companies want — and they may guess wrong.

In IT project planning, as in construction, there are three absolutes:

• Always get someone at the table who has been successful at this type of project. Chances are there’s someone on the vendor side or the IT side. Finding that person early will prevent rework.
• Always make sure you have a full set of requirements for the project, including budget requirements. Get everything down on paper, and drive to agreement across the team.
• Always complete your plan before anyone starts coding or before any data is moved. This is a big reason why you should never give anyone a cost-plus contract; the mistakes are more expensive.