Planning for a Cloud Implementation

You are here

As the saying goes, action without planning is fatal, but planning without action is futile.

In a previous post, we outlined some of the key considerations when selecting a new cloud application for your business. This post moves onto the next step, which is developing a plan for implementing that new application and taking action.


Although we have covered this already, it's worth just touching on it again because it is so important. At every stage in the process, refer back to exactly why you are undertaking this change so you remain focused.

It's really easy to start changing your plan because of some new feature that you notice, or because a single user found a small detail less than ideal. While this might present an opportunity for improvement and to achieve your objectives more easily, unless it does, add it to a 'For the Future' type of list and deal with it when the time is right. Don't allow yourself to become distracted - from experience, it is often these departures from the plan that cause issues within projects.


But what is this plan, and how do you go about developing it? Generally speaking, we recommend keeping things as simple as possible - documententing every last thing to the nth degree can be counter-productive. What you want is a framework that will guide your activity, without being overly rigid if changes need to be made. Basically though, the plan needs to cover the following:


What will you do, and what won't you do? For example, this could be as simple as:

  • Subscribe to Xero and configure business and financial settings
  • Import contact spreadsheet
  • Set up invoice templates and test generation and processing
  • Create user accounts and set user permissions
  • Provide documentation and a two hour training session for the accounts team

As indicated above, it can be useful to have a 'Negative Scope' if you know there are things that ought to be dealt with in a later stage - that is, what you won't do, for example:

  • Integration third party applications
  • Customisation to reporting

A simple table is often a good way to manage the scope, and to it, you can add columns for the below headings.


This is fairly straight forward of course - who is doing what? Allocate the appropriate person against each item on the scope, and note any dependencies that might exist. Ideally, you have a project champion, who is responsible for managing the overall implementation, along with whatever other support that person needs.


It's tempting to think about Timing before Scope, but how can you really gauge how much time will be needed if you don't know what needs to be done? We see this a lot, and have fallen into the trap ourselves. You embark on a project, and decide that you want it done by some arbitrary date - let's say six weeks into the future. You then break down the project, and squeeze all of the things you have to do into that timeframe. Sometimes it works, but mostly only if you follow a very specific process that's been developed by doing it multiple times. If this is the first time you are implementing the application, which it probably is, you don't have that.

So, what you need to do is take your scope, and allocate reasonable amounts of time to each activity. If you think something will take two hours, then make it three or even four and build your plan around that. That way, if you are off in your estimate, you'll still be winning (unless you are way off).

You may like to break your project structure down into something along the lines of the below.

  • Information collection - gathering the various bit of information you will need: a logo, a GST number, a Contacts spreadsheet, conversion balances for example.
  • Base configuration - setting up the account, and doing a first run through of settings, including noting down any further information you need or potential challenges.
  • Advanced configuration and customisation/revisions - doing the finer detail set up, such as importing trial data, adjustments to the settings, and any of the challenges you noted above.
  • Data importing - this is broken out into a separate stage as once you start importing live data life can become more complex if you need to start changing things around, or the data import fails. Work with trial data until you are confident everything is set up the way you need it to be, then import your real data. In theory, you'll only need to do it once, which is the aim.
  • User access, acceptance and training - get your users set up, and prepare some documentation for them. Keep it simple. Screenshots are useful but bullet point lists work best for others - we find a combination of the two is ideal. Then walk your users through the software, following the training guide but making sure they operate the computer. This allows you to make adjustments to it that become apparent once a real user starts clicking buttons and you avoid the trap of assumptions.
  • Revision and final adjustments - when you walk your users through the new system, it's likely that there will be adjustments or problems that get noted. Just classify these as being minor, moderate or major, and address them accordingly. Where there are major problems, you will need to evaluate whether they are showstoppers and require a project re-think (but really, this shouldn't happen if you have completed all of the earlier steps), or just require a bit more work to get right. If it's the latter, you may chose to deal with them now, or move them into a post Go-Live stage.
  • Go-Live - this is it, you are ready to flick the switch. There may be some activities that need to occur at this point, including establishing live data feeds, disabling previous software, notifying key contacts about any change in process and so on.
  • Ongoing support and improvement - it's not job over just yet. The new cloud application set up may be flawless, but it is almost guaranteed that there will be ongoing changes that may be needed, new feature releases that have some implication on your processes, or additional user training and ongoing enquiries. Factor this in, and make some sort of allowance for how to manage these things as they come up. To some degree the application support team will be available to help you, but of course they can only help with things directly relating to the software and not business process.


How you set your budget, or what is an appropriate one, is really determined by the size of the organisation and the degree of complexity implicit in the project - which is why we have it towards the end of the list. Just remember, it's not just the software subscription fees, it's the time that will go into getting everything set up and then providing ongoing support. As within Timing, the Budget is best determined by figuring out what needs to be done, and additionally, how long you think that will take. Sure, set an indicative budget you would like to work to at the beginning of the project, but be prepared to be flexible and adjust upwards once you have more fully evaluated the required activity.

Risk Mitigation

While in an ideal world, risks are clearly identified prior to commencing an adoption programme such as this, the practical reality is that often this isn't the case, and that they emerge as you progress. The reason for this, is that it's just really difficult to scope projects down to every last detail and understand the finer nuances of software before heavy use. It's almost certain that part way through the project, a stumbling block will appear. To deal with this, the best approach is simply to be realistic and flexible. Expect it will happen, and when it does, evaluate the options and go with the one that is most likely to help you achieve your objectives.


From here, it's a case of following your plan, and actually doing the set up. Don't rush things, and give yourself or the people you are working with time to complete their steps. If there's information that you need from others, make sure you communicate this clearly and in advance. If you run into some form of roadblock, take the time to evaluate the scenario carefully before jumping into the first solution that presents itself. And overall, remember that this is part of a process improvement, and any short term pain will be rewarded with efficiency over time.

Link Solutions's picture

Posted by Link Solutions

At Link Solutions we believe owning a business should be fun, profitable and facilitate a flexible lifestyle with the ability to work from anywhere. We help business owners achieve this through the integration of technology, people and processes; enabling them to work less and do more with their time.

How can we help you today?

App AdvisoryApp ImplementationReporting