How to Manage a Business Analyst’s Top 5 Challenges when Changing Industries
In 2008, after I had been in the financial industry for 25 years (with a decade as a Business Analyst), the economy collapsed. I moved from New York City where I had been working for one of the world’s largest banks, to the Washington, DC area in search of a job. I joined a small information technology firm focused on federal government contracting, but switching industries, sectors, and company size involved many changes. If you are contemplating a change from one industry to another, here are the top 5 challenges you may face as a business analyst, along with tips on successfully managing the transition.
Challenge #1: Financial vs. Information Technology Industry
The immediate challenge when switching industries is the steep learning curve involved in mastering a different discipline. Most of my career had been in wealth management. Not only did I lose my status as a Subject Matter Expert/Super-BA, I had to learn a new vocabulary and, at times, a new approach to gathering requirements. My colleagues were no longer business line professionals; they were now technology professionals. Having crossed the “bridge,” I sometimes sensed the question from my new colleagues: Who’s side are you on, anyway?
- Corporate Assets: Have lunch with a senior BA in your new organization to learn as much as possible about your company’s culture and how you fit in. Ask lots of questions – How many other BAs are there in the company? Does the company have a repository of document templates? Does the BA have samples of recent requirements documents? Are there any BA-focused activities, learning opportunities, or periodic meetings held by the company?
- Industry Culture: Google! (Or your search engine of choice.) Search for “business analysis [name of your new industry],” and you’ll be surprised how much helpful information you will find. Check the International Institute of Business Analysis (IIBA) website for members who work in your new industry. Find a few who are willing to share a few words of wisdom and experiences they have had.
- Industry Vocabulary: If the first and second bullet points above don’t get you what you need, do an internet search for industry terms or vocabulary. For example, for the federal government, I found GovSpeak and for Information Technology, I use Gartner’s IT Glossary .
- Collaboration: As with any new job, listen and learn before trying to teach. Ask the project manager on each new project how she or he likes to handle the requirements gathering sessions. Be prepared to make suggestions when asked. Use your soft skills!
Challenge #2: Private vs. Public Sector
My new employer, although a private company, was competing for contracts from the federal government. This shift to the public sector presented my second challenge. In the private sector, my duties and responsibilities changed frequently. Although primarily a Business Analyst, I had a variety of transient responsibilities depending on the needs of the organization. In the world of government contracting – proposals, re-competes, contractual restrictions, efficient spending, and government shutdown – I found that I had to be much more focused. Occasionally, this meant dealing with frustration as I learned what was, and what was not, my responsibility.
- Contract Work: If you are new to contract work, especially for the federal government, take an hour or so to learn about the proposal and contract award process. Even a high-level view will go a long way in helping you make the transition. I found this document from the Federation of American Scientists particularly useful Overview of the Federal Procurement Process and Resources.
- The Contract: Knowing what services are covered by the contract you’re working under is critical. Ask the program or project manager if you can read the proposal that the company submitted, or the contract itself, to better understand the services and deliverables you are responsible for. Ask if there are any performance standards that you must meet, and also ask if there is any historical information or political landmines that you need to be aware of. Find out the expiration date of the current contract, because you will be called upon to help when the contract comes up for re-compete (i.e., goes back up for all contractors to bid on).
Challenge #3: Traditional vs. Agile/Iterative Project Management
Finance is a very traditional industry. Wealth management is particularly conservative, so I practiced a methodical, traditional, waterfall method of requirements documentation. IT, on the other hand, is the anti-documentation capital of all industries. Developers need the freedom to be creative and to experiment with software and system design. Finance is heavily regulated, and documentation is regularly audited and must be compliant. The Federal government rarely undergoes audits. Documentation of business requirements is, at best, iterative and a may not be completed until after the project is well underway. Scope creep is standard operating procedure.
- Iterative Requirements: Be flexible with your method of gathering requirements. Be prepared to break your documentation into phases, since breaking a project into smaller iterations may work better in the public sector where funding is limited and more strictly controlled.
- Agile Terminology: Familiarize yourself with User Stories vs. traditional business requirements by attending webinars or reading articles. The IIBA now provides an Agile version of the Business Analysis Body of Knowledge (BABOK®) guide, and free webinars are offered regularly.
- Be Flexible: Adjust your thinking to expect that not all requirements may be known upfront. Rather than thinking of new requirements as scope creep, think of them as next-iteration enhancements.
Challenge #4: Internal vs. External Stakeholders
Stakeholders are king (or queen)! This holds true regardless of industry. In the transition from employee to contractor, however, the stakeholders I worked with were no longer fellow company employees. They were now external customers from federal government agencies with an alphabet soup of acronyms for titles, divisions, offices, legacy systems and business processes. As a BA, customer satisfaction is always a top priority, but as a contractor, understanding and meeting stakeholder needs becomes a matter of life or death. Well, at least life or death for the next contract re-compete opportunity. I worked with stakeholders who signed my company’s paycheck, so more was at stake (no pun intended) than with internal stakeholders.
- Industry Vocabulary: Revisit your sources in Challenge #1.
- Know Your Customer: Now more than ever it’s critical to understand customer needs, expressed and unexpressed. Visit the section of the customer website that is most pertinent to your stakeholders to get a better history and understanding of what they do on a daily basis. Do they manage grants? Are they tasked with outreach to the general public? Are they scientists and researchers? Knowing your customer is more than half the battle in understanding what they need.
- Communicate, Communicate, Communicate: Establish a standard method of communication that works for your stakeholders and stick to it. Administrative staff is limited in today’s world, so you may be responsible for meeting agendas and minutes. Choose a template and be consistent. Consistency promotes efficiency, both for you and for your stakeholders.
Challenge #5: Independent vs. Collaborative Elicitation
Often in the private sector, I did most of the BA planning and execution on my own, or with a management colleague. In the public sector, and especially working with an IT firm, I regularly found myself in a secondary role. Stakeholder meetings involved team members from the federal government, other contractors, and project managers or developers from my own company. Eliciting requirements during a meeting where numerous roles and purposes were represented may have been the most challenging aspect of the transition.
- Listen: Plan on gathering many of the project requirements as someone else leads the meeting. Take copious notes. If you have the opportunity to re-state a requirement or ask a question for clarification during the meeting, do so.
- Requirements vs. Solution: Separate requirements from the technical solution options in your own notes by having a column or page for each. Differentiating between these up front will help to keep the developers focused on the actual customer needs and acceptance criteria as the solution is designed.
- Follow-Up Emails: Expect that you may have unanswered questions after a stakeholder meeting. Meetings that have a large number of participants often run overtime, and the key stakeholders or subject matter experts may not have time to chat afterward. Note your questions and follow up by email for clarification. Include the email responses as an appendix to your documentation.
By following these tips and preparing yourself for your industry change, you will find that your transition will be easier and more productive.
Don’t forget to leave your comments below.