Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Structured Anal...  Tasks Involved as a BA in application lift and shift.
Previous Previous
 
Next Next
New Post 5/21/2019 8:18 PM
User is offline April
1 posts
No Ranking


Tasks Involved as a BA in application lift and shift.  

Hello All,

I would like to know the list of activities that are required for a BA w.r.t an application lift and shift change. This is not a version upgrade project. On the high level how do I approach it ?

Cheers,

 
New Post 6/4/2019 2:15 AM
User is offline Stewart F
98 posts
7th Level Poster


Re: Tasks Involved as a BA in application lift and shift.  

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 !  


 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Structured Anal...  Tasks Involved as a BA in application lift and shift.

Community Blog - Latest Posts

Rajesh-N
Rajesh-N
What Everyone Must Know about AI in Testing Artificial Intelligence is the buzzword that we frequently keep hearing. Its widespread popularity and influence can be understood from the way industries adopting AI in their organization. Whether it’s Healthcare, Automobile, Banking & Financial Services, or Airlines, many industries have st...
0 Responses
Ashish Adike
Ashish Adike
As a Business Analyst, very often we get into a situation where the Project requires multiple IT Products to be evaluated before implementation and might seek Business Analyst’s recommendation for the same. With the ever-growing range of Products in the market and the marketing promotions associated with some of the products, it’s very ...
0 Responses
m_anst
m_anst
What Does Success Look Like? I challenge Business Analysts to view requestors’ requirements as an opportunity to define success. Too often, teams fall into a trap focused on requestors’ prescriptive requirements that are meant to serve as roadmaps for developers and testers. When you limit your view of requirements to this prescripti...
0 Responses






Latest Articles

The Art of Letting Stakeholders Have Your Way
Nov 23, 2020
0 Comments
Study after study in behavioral science show that certain approaches are more effective than others when we’re trying to convince others to see ...
Copyright 2006-2020 by Modern Analyst Media LLC