10 Steps to Success When You Are Hired as a BA for a Company That Has Never Had a BA Before

I took a new position a year ago to become a Project Manager/Business Analyst (BA) in the IT department of a company that had never had these roles before. So far, it has been a challenging and often frustrating road. I am just getting to the point where I have gained enough credibility that I can start to introduce new processes for both the requirements phase of a project and the overall project management. After reflecting on my experience, I thought of 10 steps that will help BAs who find themselves in a similar position.

1. If you aren’t familiar with the domain, immerse yourself in it to learn as much as possible as quickly as possible. Ask questions to learn about the processes and systems that are used. Read about the industry and the company. Take tons of notes in meetings, and make special note of things you don’t want to ask in the meeting but need to follow up on later. The stakeholders in your projects will appreciate your efforts to learn their business, and it will be easier to gain their respect.
2. When existing processes are discussed, ask if there are process flow documents that you can reference. If not, ask if you can sit down with someone who performs the process so that you can create a process flow. This will help your understanding of the process and can also serve as documentation for requirements and beyond.
3. Find out what the developers are accustomed to receiving as “business requirements.” Was someone on the business side writing up some type of documentation? Were the developers writing their own business/technical requirement? How were requirements communicated to IT? Understanding the current state and any pain points will help you figure out where to go with the future state. When I did this my first month on the job, I got lots of feedback. The developers wanted to have a thorough requirement document so that they didn’t have to chase down the business owners and wait for answers while trying to program something that wasn’t adequately thought out.
4. Find out what level of detail the developers want in a business requirement document. This will really depend on developer experience and the type of system. Some web developers may not want a lot of detail because they appreciate creative latitude to figure it out on their own. On the other hand, mainframe developers may require more detail because the system doesn’t offer much room to be creative. Many developers will want more detail in requirements documents to save them the time and energy that they are currently spending going back to the business owners and subject matter experts (SMEs) with questions.
5. Find out what level of detail the business users want in a business requirement document. This will depend on how the document will be used on the business side. Are training materials created from the business requirements? Maybe the business users can’t answer this question yet because they have never had a document to reference in the past. In this case, you may need to build on your prior experience of what business users want.
6. Find out who tests the projects and what kind of detail they need to see in the business requirements. If you are lucky, there will be an official Quality Assurance function. Then you can ask the testers how much detail they need in order to efficiently write test cases. This may require a change in mindset on the part of the testers if they have never had business documentation before. Especially if you have prior testing experience, tread lightly and try not to step on any toes!
7. Balance #4 – #6 to create a template that everyone can use. You may want to adopt a business requirement document template that has worked well for you in the past, but keep it simple to start with. If some type of template was used at your new company in the past, review it and try to incorporate any pieces that stakeholders seem to find useful. Once you have decided on an initial requirement template that you think will work, it’s a good idea to hold a meeting with members of the affected areas (Development, QA, Business areas). Let everyone know that you have compiled their feedback and have come up with a standard format that you want to use going forward. Explain the benefits of the approach you have chosen and let them know that you will check back with the group in six months or so to collect feedback on how the format is working.
8. Determine what types of stakeholders you will be working with on business requirements. Some companies will give you stakeholders who actually do the work, and others will prefer to give you managers to work with. At my company, I work almost exclusively with the department managers. I have learned not to assume that the managers know the detailed business processes used in their departments. I make sure to get the ok to bring the people who do the work into necessary meetings or to give the manager specific questions to ask their team members.
9. Take time to get to know your project sponsors. Figure out what type of communication works best with them, what they do and don’t respond well to, how “in charge” they want to be, what level of change requests they want to approve (and what level you can assume approval for), and anything else that will help you work well with them. I didn’t come right out and ask these questions of my project sponsors. I analyzed the way they answered emails, the way they acted in group and one-on-one meetings, what made them happy and what didn’t, and then formed my own conclusions about what to do/what not to do.
10. Don’t push too hard on “best practice” or “industry standard” at first because your business owners and stakeholders may not be ready for this. Let them get to know you and the quality of your work before you try to put new processes in place. Once you build trust and they respect your ideas and abilities, putting processes in place will seem natural and fairly painless.

Don’t forget to leave your comments below.