Hi all,

thanks for reading this thread.

i could really do with some advice.

some context:

since I was at uni (many years back!) - I've always wanted to be a B/A b/c of the nature of the role; that is - the interaction with the clients, the requirements process etc now i work as a business systems analyst for a superannuation and insurance company.

i've worked for the past 6.5 years across various facets of IT; programming, support (application & infrastructure), b/a consulting  - this varied exposure has given me the nuts and bolts of IT - that i felt i needed to understand before moving into the analysis stream.

currently now - being new to super & insurance & fairly new to the organisation, i find there is no documentation and the systems being upgraded are legacy systems (no suprise here). it seems a steep learning curve. most companies i've found don't spend time on this aspect - as it doesn't relate to bottom line revenue at the end of the day. thing is, how to learn the application then? how do bsa's normally survive in conditions like this ??  is this the 'norm' everywhere?

Guy: This is common although not the norm. One trick that has worked for me is to ask for the training courses that new starters who will use the systems are put on. The training course will at least educate you about how the application is being used there and (hopefully but not always!) what it can do. Looking for old project specifications is usually a waste time (out of date if they exist!). Reverse engineering the functionality from the code is a last (expensive, slow, error prone) resort. Of course, there will almost certainly be a subject matter expert on these systems in the user community - if you can find them and they want to they can be worth their weight in gold.

i find that there are many miscommunications within the team and i want to make sure i'm not at the tail end of it (which seems to be happening alot recently) - i try to keep everything on email. yet sometimes i'm not included for meetings, decisions are made and i'm not told etc  i guess this is a softer skill question - what can i do to ensure there is clear communication ? and how can i be more professional about this ?? are there courses you'd recommend?

Guy: Why would you be excluded? For example, if you were excluded because you are not seen as relevant to the meetings, is that in fact true? Are you needed for any reason? If not, why be there? If you are then make sure that people understand the consequences of you not being there ("so I wasn't at the last project meeting so I have no idea what I am meant to be doing and why so unless someone takes more time out to tell me then I can't progress the analysis and the project cannot progress"). This can be communicated informally (verbally with your project manager) or fomally (through the issues log) or both.

There are many courses available first - just sort out what you want from the course before you select it. E.g. if you want help on the job with your current project select a distance learning mentroring course such as mine. If you want accreditation select a course that includes that and teaches to that syllabus.

also i find the ba/ bsa world not as 'strict' (how to say..). the notations of UML/BPMN, are not used at all - as most of the system upgrades are for maintenance. it's rare that new functionality is built. coming from technical background, i'm craving a bit of structure in this role. will this come from perhaps doing a course to understand my industry a bit better ? or is being a b/a more suitable for structure? what would you recommend? 

Guy: I would recommend that you get the structure of requirements analysis embeded in your thinking and then apply it to your every day job. They may not have a structure (your company, your team whatever) but there is no reason why you can't have one.

thanks and hope to hear back soon.

cheers,

mani