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:
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:
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.
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.
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.