Help me, help my BA
-
I am not sure if this is the correct place or not. We are starting to migrate ERP systems. As such our team has hired some new BA's. 2 of them came from the desktop support team. I have noticed they seem to be struggling. I asked them yesterday if they had any training or such. The reply was no. I then asked if they wanted some help to understand their new positions. Both of them said yes. Could some of you please tell me what you think are the most important skills, duties or anything else I can share with them to help them grow into their new positions please. cheers
A BA is a liaison between the tech side and business side. The tech side usually has poor social skills, and the business side usually has poor technical skills. A BA has to be the go-between between the two. Being slightly technical enough (not nearly that of a dev) to help translate what the business wants to what tech can consume and vice versa. IMO, a BA needs something that can't be taught... a friendly, type A personally with no ego... who respects devs and doesn't fear the business. They don't have to be great at tech, but they do need to be able break things down and quantify things. To your question... * Just about any team building activity will work. If they're new, then get them used to the people in the tech team - especially if it's remote. Go share a laugh, etc. * Show them the ropes for your existing business processes on the tech side... Is it Agile/Scrum, etc.? If they're not Jira gurus and you're using Jira... make sure they _really_ learn Jira (most people never do). They don't have to be as knowledgeable as a Scrum Master, but enough to help them get a solid understanding of how to track timelines, etc. * If they haven't met people on the business side yet, then they should. They should be proactive about this, but if they're brand new then perhaps an intro here would help too.
Jeremy Falcon
-
I am not sure if this is the correct place or not. We are starting to migrate ERP systems. As such our team has hired some new BA's. 2 of them came from the desktop support team. I have noticed they seem to be struggling. I asked them yesterday if they had any training or such. The reply was no. I then asked if they wanted some help to understand their new positions. Both of them said yes. Could some of you please tell me what you think are the most important skills, duties or anything else I can share with them to help them grow into their new positions please. cheers
Oh, the reason why it's important they don't fear the business side, if a bad BA is scared of their own shadow, they'll never be honest with the business. They'll usually over-promise and under-deliver out of fear. That's bad for devs. That's bad for the business. Yes, business competition can be fierce, but most folks just want the truth. If it's going to take 2 months, then don't say it'll take 2 weeks just because someone is stressed. Same goes for product owners as there's a bit of overlap between these roles.
Jeremy Falcon
-
Robert Cummings 2021 wrote:
We are a small technical college in a very rural area. Evidently HR had a hard time finding any qualified applicants.
This explains a lot more regarding your situation.
Slacker007 wrote:
This explains a lot more regarding your situation.
How's it go? We want a rockstar that turns down the likes of Apple, and we want to pay them $2 a month! And, we want them now!
Jeremy Falcon
-
I am not sure if this is the correct place or not. We are starting to migrate ERP systems. As such our team has hired some new BA's. 2 of them came from the desktop support team. I have noticed they seem to be struggling. I asked them yesterday if they had any training or such. The reply was no. I then asked if they wanted some help to understand their new positions. Both of them said yes. Could some of you please tell me what you think are the most important skills, duties or anything else I can share with them to help them grow into their new positions please. cheers
ERP means "enterprise"; refering to the systems that "run" the enterprise and how they integrate: Financials; manufacturing; order processing; purchasing; etc. The BA's role is to "know about those things". The BA role was invented to isolate the user from the "programmer"; as such, their usefulness is inversely proportional to competency (and political reach) of the development team. Working on the actual systems, the "programmer" tends to know more than the BA; so, yes, the programmer winds up being a ghost writer for the BA (who makes the presentations to management, but doesn't take responsibility for the results). If there are no existing systems, there is no "BA" (that I'm aware of); he would be a "systems analyst" (chicken and egg).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
-
I am not sure if this is the correct place or not. We are starting to migrate ERP systems. As such our team has hired some new BA's. 2 of them came from the desktop support team. I have noticed they seem to be struggling. I asked them yesterday if they had any training or such. The reply was no. I then asked if they wanted some help to understand their new positions. Both of them said yes. Could some of you please tell me what you think are the most important skills, duties or anything else I can share with them to help them grow into their new positions please. cheers
If there are more than those two BA's I'd say let the more experienced BA's help them out. If anyone, they should know what's expected of them and how things work. Also, get them proper (formal) training.
Best, Sander Azure DevOps Succinctly (free eBook) Azure Serverless Succinctly (free eBook) Migrating Apps to the Cloud with Azure arrgh.js - Bringing LINQ to JavaScript
-
I am not sure if this is the correct place or not. We are starting to migrate ERP systems. As such our team has hired some new BA's. 2 of them came from the desktop support team. I have noticed they seem to be struggling. I asked them yesterday if they had any training or such. The reply was no. I then asked if they wanted some help to understand their new positions. Both of them said yes. Could some of you please tell me what you think are the most important skills, duties or anything else I can share with them to help them grow into their new positions please. cheers
greetings kind regards may i please inquire edumakation of said BAs ? i have little knowledge re/ such matters however if i understand correctly via my ignorant opinion a so called BA would need to be learned of computer systems and business operations/systems . re/ "desktop support" if i understand its meaning i.e. so called "help desk" i.e. assists w/ operation of software again via my ignorant opinion though w/ no small amount of experience seeking assistance via same w/ only occasional pleasant surprises a "desktop support" person would have none of these as in my experience they merely follow a pre-written script which requires little knowledge .
-
My understanding is that BA's take the needs of the client and convert them to requirements (at a high level, I'm sure they do more than that). Those requirements get prioritized for the Dev team, db team, etc. through some sort of sprint or iteration planning. There are probably some good videos on YouTube for Business Analyst positions, etc. that would be worth watching. From the internet, random Google search result:
Quote:
This means their role is to develop technical solutions to problems in a business or to further a company's sales revenue by defining, documenting and analyzing requirements.
I think BA's also work with the QA team to make sure their testing scenarios are correct and complete and to answer any questions and/or issues regarding testing, and UAT.
It is probably too late for your organization, but putting BAs (Business Analysts) and PMs (Project Managers) in charge of any technology project (especially in software engineering) is a bad decision. Hiring or contracting these non-technical roles to assist the process, reporting under the authority of an experienced senior software engineer (we’ll refer to herein as the Project Lead) is a better approach when the project is large enough. On smaller projects, those roles should be done by the Project Lead. First, they should not be given any tasks that require technology decisions. The Project Lead should carve up the project into manageable tickets (e.g. epic, features, user stories, tasks, and tests) that are hierarchically related and follow a projected timeline and adjusted as the project progresses. If BAs and PMs are involved, the Project Lead assigns them user stories and tasks as fits their area of expertise. Second, the Project Lead is the primary contact and negotiator with both customer (internal or external) and the business leads involved. Technology projects are best led and managed by senior engineers who thoroughly know the technology and are still hands-on to at least some degree. Technology projects that are led by non-technical BAs, PMs, or other roles filled with non-technical people are likely to cost more, take more time, and result in lower quality. If it is too late for your organization to properly manage the project, then you are doing the kindest and most helpful thing by offering to help those non-technical BAs/PMs so they have someone to handle the technology part, and help them learn more about the technology, which gives them “a leg up” in their career. You are also fortunate that they are receptive to such help. I have found that all too often, the non-technical roles reject the help. A combination of pride and “not knowing what they don’t know” is often why do many non-technical folks don’t want the help they need. Best of luck to you.
-
I am not sure if this is the correct place or not. We are starting to migrate ERP systems. As such our team has hired some new BA's. 2 of them came from the desktop support team. I have noticed they seem to be struggling. I asked them yesterday if they had any training or such. The reply was no. I then asked if they wanted some help to understand their new positions. Both of them said yes. Could some of you please tell me what you think are the most important skills, duties or anything else I can share with them to help them grow into their new positions please. cheers
While there is some solid advice here and would encourage you to look into the options provided, I wanted to give you something a little more immediate, based on having dealt with two major ERP replacements and supporting a third, in my career. Essentially, the role of the BA is to be curious, to ask questions, and gain understanding. In my experience customers will try to prescribe a solution based on their own understanding of the technology or because they have always done something in a particular way, but more often than not they are not best situated to provide the solution, due to their lack of understanding regarding all of the factors involved. For this reason, it is so important to start with 'why'. Understand the business problem or requirement that the solution needs to address, without reference to technology, process or user experience (user interface, report layouts, etc.), and really understand the value that achieving that outcome will have to the business. Doing so will both aid in the prioritization and may potentially eliminate some requirements altogether if the value just won't be realized.
-
I am not sure if this is the correct place or not. We are starting to migrate ERP systems. As such our team has hired some new BA's. 2 of them came from the desktop support team. I have noticed they seem to be struggling. I asked them yesterday if they had any training or such. The reply was no. I then asked if they wanted some help to understand their new positions. Both of them said yes. Could some of you please tell me what you think are the most important skills, duties or anything else I can share with them to help them grow into their new positions please. cheers
Hi Robert, I work for a public university so I understand some of the challenges you're facing as I have faced them as well. A couple resources that might be helpful: 1) ITANA is a higher ed focused Enterprise Architecture collaboration that deals with these types of situations. I highly recommend you check out their material here: Home - Itana - Internet2 Wiki[^] 2) If your institution uses EAB, Gartner or Educause I would setup an analyst call to discuss your specific needs. These calls are usually including as part of your university membership. I find that most IT folks don't know that they have access to these resources. Posting to the Educause forum is a great way to get resources that are higher ed specific. I have 10 years in private sector IT and 10 years in higher ed IT. It is hard for people who have never worked in higher ed to understand that things just work differently until they experience it. I hope this helps.
Eric
-
And my first thought was Bachelor of Arts.
-
Hi Robert, I work for a public university so I understand some of the challenges you're facing as I have faced them as well. A couple resources that might be helpful: 1) ITANA is a higher ed focused Enterprise Architecture collaboration that deals with these types of situations. I highly recommend you check out their material here: Home - Itana - Internet2 Wiki[^] 2) If your institution uses EAB, Gartner or Educause I would setup an analyst call to discuss your specific needs. These calls are usually including as part of your university membership. I find that most IT folks don't know that they have access to these resources. Posting to the Educause forum is a great way to get resources that are higher ed specific. I have 10 years in private sector IT and 10 years in higher ed IT. It is hard for people who have never worked in higher ed to understand that things just work differently until they experience it. I hope this helps.
Eric
Thank you very much, I was unfamiliar with Educause. I will certainly check them out.
-
While there is some solid advice here and would encourage you to look into the options provided, I wanted to give you something a little more immediate, based on having dealt with two major ERP replacements and supporting a third, in my career. Essentially, the role of the BA is to be curious, to ask questions, and gain understanding. In my experience customers will try to prescribe a solution based on their own understanding of the technology or because they have always done something in a particular way, but more often than not they are not best situated to provide the solution, due to their lack of understanding regarding all of the factors involved. For this reason, it is so important to start with 'why'. Understand the business problem or requirement that the solution needs to address, without reference to technology, process or user experience (user interface, report layouts, etc.), and really understand the value that achieving that outcome will have to the business. Doing so will both aid in the prioritization and may potentially eliminate some requirements altogether if the value just won't be realized.
Thanks for your input Member. I wholeheartedly agree with your statement. I always find some confusion and push back from junior people in IT when I tell them there are NO IT projects. There are only business problems that can have an IT solution. But the project itself is less important than solving the business problem.
-
I am not sure if this is the correct place or not. We are starting to migrate ERP systems. As such our team has hired some new BA's. 2 of them came from the desktop support team. I have noticed they seem to be struggling. I asked them yesterday if they had any training or such. The reply was no. I then asked if they wanted some help to understand their new positions. Both of them said yes. Could some of you please tell me what you think are the most important skills, duties or anything else I can share with them to help them grow into their new positions please. cheers
I would also strongly encourage formal training, or at least reading up on the web what they should do and what outputs they should produce (with samples). You might even review some of that yourself, then tailor the sample outputs to something you would find useful. I don't recall ever working with a Business Analyst per se; however, my expectations would be something like: 1. They should document the main business processes, especially those that need automation or interface with automation (like user stories). This should include copies of sample forms and reports currently in use. 2. This should include key terms, abbreviations, and definitions. 3. It should include any (industry) standards or regulations the business is expected to adhere to (with links to full specs/requirements where available). 4. This should include data flow (and decision/action flow) diagrams that show who creates the data, who acts on it, and where it eventually goes. 5. It should also include data models. They don't have to be formal/relational, but they should list all the business data entities, allowable (and sample) data, volume/size/quantity, and relationships. 6. You might want to also have them help with developing persona, use case, or actor models. Hope this helps.
