Hi there,

I would break this down into a couple of key tasks and then each of those into further tasks. Think Agile Features & User Stories.

The larger tasks that you would require are:

1. Understand what is being moved. This needs to be precise not a vague statement of "our finance system". What exactly is moving? Get your stakeholders to list precisely what. If it isn't on the list, it isn't getting moved.

2. Once you have the list, then list all the other systems that interact with that application. Either directly or indirectly. Don't forget external clients systems, APIs etc.

3. Then do the same as point 2, from the perspective of where the Application is going to. What will it affect - directly or indirectly.

4. Then list what will be affected by the change over. Will internal or external processes need to be amended? Is that area (department) ready for the change - do they know how to change? These all need to be ready to go at the same time and each will need to be worked through. My suggestion is to ask that Department Head, if he or she can nominate a member of that team to act as the 'Product Owner'. They can help you list all of the impacted processes and sub-application. This takes some of the work off your shoulders.

5. Next, I assume there is an expert for the application itself, being moved? I assume as well that they know for a fact that it can be moved and things like licenses, new APIs and or Server settings have all been listed/documented? If they haven't, then you need to get someone in the IT department to be responsible for that. Try to avoid that person being you – it’s a bit of a minefield.

6. Not a task this, but always useful - can you talk to the Application development company in terms of them giving you advise? For example, lets say you were moving from Windows OS to Macs, and associated OS, it would be a good idea to talk to Apple - that's just an example, but hopefully you get my drift. Sometimes you don't get any information that is worthwhile, but sometimes....

7. That's the information gathering part of the task, now you need to put it altogether in a timetable. Be realistic and add contingency - things always happen that you didn't plan for. This is one of the most trickiest parts of the project. Everyone will have different timelines to meet their own personal objectives and requirements. IT for example will want it done yesterday. Operations have to change lots of processes, train people in them and potentially warn clients. All that takes time, so they will want longer than IT. You get the drift.

There are two way of doing this. First is to get all the key stakeholders together and get them to agree a date. I don't subscribe to this as, in my experience, this ends in general chaos and on occasions - punches being thrown (not quite but we weren't far off).

The second and best way is to ask each Stakeholder individually their preferred date. What do they think they can achieve? Are there key dates they want to avoid? (for example the Finance Team may want to avoid End of Year). Put that in a gnat chart and see if there is overlap between any of the stakeholders’ dates. If you are lucky there will be some similarity, but most likely, they will all be slightly different. Logic says you do the changeover when the Stakeholder who wants the date furthest away wants to go. However, all the dates should be challenged. Is there a Project Manager working on this or just you? If there is a PM, this is really their job.

8. Each of the key Stakeholders needs to be regularly updated. Again this will be a PM job if you have one.

9. From a BA point of view, you now just need to work through each task and tick them off as you go. New tasks will pop up as you discover more and more. Don’t be afraid to put the brakes on if needs be. It will only cause more hassle if you don’t delay the change before everyone is ready.

10. Lastly, devise a role-back plan. This will be in conjunction with IT mainly, but also with Stakeholders. You may need to look at rolling back other tasks as well.

Remember, in projects like this communication is vital. Send out updates via email – even if Stakeholders attend your meetings – it acts as evidence if they don’t do something. Get each area to take ownership of their requirements – they will quite possibly need to help you achieve the required changes.

Other than that – good luck !