|
And there was me thinking that a BA[^]'s main jobs were drinking milk, being afraid of flying, and pitying the fool. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I miss Sergeant B.A. Baracus. Great show from my childhood.
|
|
|
|
|
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
And my first thought was Bachelor of Arts.
|
|
|
|
|
Thanks so much for your response
Yeah I know that part. I was thinking they might also play PM in smaller projects. In our case each BA will have a department they support. Students, HR, Finance so they will become system experts in that part of the system. And to a point that side of the business. Anything else they might be required to do outside of being the middle man between myself and the business side.
I should have been more clear in my question.
cheers
|
|
|
|
|
Robert Cummings 2021 wrote: they might also play PM in smaller projects.
I would be careful with that. If you are trying to keep costs down, then I get that, but I strongly support the separation of concerns between PM and BA.
PM skillset is a whole other ball of wax. If you have the money to send them to formal PM training that would be wise, if they are not already trained PM's.
Best of luck.
|
|
|
|
|
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.
|
|
|
|
|
Depends on the size and nature of the organisation, partly. Strictly speaking a BA will analyse the business, which may or may not involve anything to do with IT. They might identify areas that can be automated or computerised, and they would input their business requirements to the Systems analyst. The SA would work with the DBA and any systems architects to create specs for the developers.
Unless you (or they) have job descriptions from HR, it's maybe difficult to determine whether this is their role, or a more "full stack" version where they are expected to identify the business' needs AND deliver that as a systems solution.
Either way, recruiting BAs from Desktop Support seems a very strange approach. If you get the business analysis wrong, or even suboptimal, it doesn't matter how good your developers are, your business will suffer - badly.
|
|
|
|
|
I understand what you are saying. Especially the part about recruiting from desktop support. We are a small technical college in a very rural area. Evidently HR had a hard time finding any qualified applicants. So they gave the existing employees the job. It was a promotion of sorts.
They will definitely be "full stack" BAs. Even having a BA is new to the college. And I am the only programmer on staff. I just support the integrations between all the various systems. So I guess what we need is way different from what 3M, Amazon, and other organizations with large IT staff.
|
|
|
|
|
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
|
|
|
|
|
Sincere wishes for success Robert.
My suggestion is to encourage your new staff to ask a lot of questions -- especially "Why?". They need to learn the business as it stands currently as well as why the customer wants changes.
Best wishes from Minnesota - Craig
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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 .
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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:
- 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.
- This should include key terms, abbreviations, and definitions.
- It should include any (industry) standards or regulations the business is expected to adhere to (with links to full specs/requirements where available).
- 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.
- 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.
- You might want to also have them help with developing persona, use case, or actor models.
Hope this helps.
|
|
|
|
|
A reactive metal and an odd dog. (6)
|
|
|
|
|
Afghan ?
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
