Forums for the Business Analyst

 
  Modern Analyst Forums  Careers  Getting Started  Former developer now working as a BA
Previous Previous
 
Next Next
New Post 6/2/2017 9:43 AM
User is offline Nobee
2 posts
No Ranking


Former developer now working as a BA 

Sorry this is a long post! TLDR; at the bottom.

Hey guys, I just recently got a new job as a Business Analyst at a new government department. I previously worked as a developer of an enterprise system and have decided to make the switch over to the BA role. 

Now I am at a new department, new team, and I have a scary new career of which I know nothing about. I was hired for my IT experience and they needed someone to gather requirements for a new enterprise application that has yet to be implemented. I also showed initiative in the interview that I am willing to learn in my new role, so I guess that's why I got the job even though I don't have the experience yet.

A little background on this new project I'm on: My section consists of several developers on different teams supporting several different applications. Some of these applications are being used in different regions. Currently, there is no system to track bug reports or for end users to easily request for a new service to be done. It's all done through emails. The product they want to implement, and for which I am responsible for gathering requirements and delivering, is a new ticketing application for managers and developers to use in order to manage service requests for support.

One month in I am still completely lost. My supervisor would like me to create a requirements document so I researched on what a BRD was and how to write one. But that proved to be pretty difficult at the start. Initial meetings with dev team leads were awkward. They didn't really care much about the product. They were happy with their current process of managing everything through emails. The product was kind of forced on them by the section manager. So requirement meetings were a little challenging. They wanted to see a demo of the product so they can get a better idea of what they want, but I barely know the product (since I'm still new) and I'm having my own challenges trying to get any information from the one (and only) developer who is developing this new product.

 

Activities I've done so far:

  • Identified who the stakeholders are
  • Attended an initial requirements meeting with some of the stakeholders and asked about their current processes
  • Attempted to write a BRD (then realized it was too early on in this stage)
  • Read up on some documentation on the product
  • Working with the one developer to strip the product down from its out-of-the-box version to something I can demo for the clients

 

Challenges:

  • Stakeholders aren't forthcoming and are generally uninterested in the product being implemented
  • Timelines: This project has been sitting for almost 8 months when I joined. My manager would like to get this out in the next 3 months or so. Seems unrealistic!
  • Documentation: There so many documents to write, and no clue where to start!
  • Small team with little support. It consists of me (the BA), my manager (responsible for managing this project), and the developer. That's it! There isn't even a QA team. I suspect I will be the one doing the testing.

TLDR; So in summary, I am a former developer joining a new team as BA with zero experience in the field.

Any help on where I should go from here is much appreciated!

Thanks!

Nobee

 
New Post 6/5/2017 9:18 AM
User is offline Chris Adams
307 posts
5th Level Poster






Re: Former developer now working as a BA 

It sounds like you've entered a very unstructured environment.  My advice would be to use an Agile approach to gathering and organizing the necessary requirements.

If you aren't already familiar with Agile, you should read a short overview book on the topic (though there is plenty of online reading as well).  But keep in mind that Agile approaches very a bit from company to company and from team to team.  It's intended to be flexible.  Adapt it to work for you.

I would document the obvious, key requirements as user stories.  A good structure for starting a user story is “As a (role) I want (something) so that (benefit)”.  You can read a fairly details explanation of user stories here.

This process is fairly light-weight and flexible.  Now, I realize that you were asked to create a BRD.  You can either have a discussion with your manager about what you are really trying to achieve or you can take each user story (“As a (role) I want (something) so that (benefit)") and list it in the BRD as a requirement.  They are essentially the same thing.  User Stories are eventually estimated and given a priority ranking.  A BRD does the same thing with its requirements.

When it comes  time to code each requirement you can use a light-weight collaboration tool like Trello to manage each User Story as a "Card" on a "Board".

So, why am I recommending this process.  A BRD is a heavy-weight document that most managers, end-users, and developers expect the BA to "fill-out". It's tough to get the level of collaboration and review that you need from other parties in an unstructured environment.  The User Story process is much more interactive but doesn't require much effort from other stakeholders.  You write a 1-3 sentence user story, you have a conversation with the user about it to derive the user acceptance and test criteria (this can be done with end users and developer at different times if it helps).  Then you can estimate the time to develop the feature and prioritize it in a Product Backlog.

Hope this helps.


Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile
 
New Post 6/9/2017 1:30 PM
User is offline Nobee
2 posts
No Ranking


Re: Former developer now working as a BA 

That's great. Yes, it definitely helps. The challenges you mentioned about creating a BRD in an unstructured environment is exactly the kind of thing I encountered when I tried to write one.

Okay, creating user stories seems like the best approach. I'll try it that way. Now, is this similar to a use-case? I just came off a 4-day BA course this week and there was a heavy emphasis on business use-cases and system use-cases. From the business use-case, we derive the system use-case, and then from the system use-case, we determine the basic flow. I'm just trying to get all these documents straight in my head so that I am not duplicating information. It's very confusing at this stage, and a lot of documentation seem to blend in together and overlap.

Thanks for the help!

 
New Post 6/11/2017 8:41 PM
User is offline Chris Adams
307 posts
5th Level Poster






Re: Former developer now working as a BA 
Modified By Chris Adams  on 6/11/2017 10:50:55 PM)

User Stories are different from Use Cases, though either can be uses to document functional requirements.  Check out the link that I put in the last message to really understand how User Stories work.  A User Story is typically a 1-3 line requirement statement.  Then it's further detailed out by the acceptance test criteria that are documented along with it.  

Here is a  short little video segment that talks about the similarity and differences though there probably isn't enough detail in it to help you understand how to document the user stories. Again the link previously provided should help with that.

Use Case versus User Story


Chris Adams
Core Member – ModernAnalyst.com
LinkedIn Profile
 
Previous Previous
 
Next Next
  Modern Analyst Forums  Careers  Getting Started  Former developer now working as a BA

Community Blog - Latest Posts

Bert Wagner
Bert Wagner
It’s 4:30 pm on Friday and Mr. Manager comes along to tell you that he needs you to run some important ad-hoc analysis for him. Previously this meant having to stay late at the office, writing cumbersome queries to extract business information from transactional data. Lucky for you, you’ve recently started using Temporal Tables in SQL...
0 Responses
Ronak Sanghavi
Ronak Sanghavi
Current State For many years now, the most commonly used metaphor on Business Analysis has been the “Bridge”. However, in recent past, some in the BA community have started revisiting the metaphor resulting in a debate on how relevant it is. Of course, the value business analysis can provide for an organization does not depend on how i...
0 Responses
SarikaA
SarikaA
Pega systems(Software Company) is the leading provider of business process management (BPM) and customer relationship management (CRM) software solutions. Pega systems motto is “Build For Change” and their goal is to “eliminate software coding” and “automate manual work”. Pega systems has bee...
0 Responses




Latest Articles

Getting the Job Without Previous Domain Experience
Jul 23, 2017
1 Comments
Trying to secure a business analyst job interview in an area in which you don’t have prior experience can be a huge challenge. It’s common...
Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC