Top tips for enhancing technical business analysis:
Be thorough with requirements gathering
- Confirm requirements with all stakeholders and anyone perceived to have a direct or indirect role on the project and/or finished product. This includes entry to senior level members. One way to do this is to have focus groups. Each member will have something important to say, and the more people one talks to, the better their requirements will be.
- Requirements should be written and visual (i.e. wireframes and diagrams such as business flow diagrams). This helps to confirm requirements as some people are more visual and vice versa.
- Never assume. Detailed requirements are important, especially ones that cover all bases. For example, a synchronization requirement can be interpreted as one way or two way. Expressing two way synchronization can save time and money. In addition, if conducting a technical study, consider ALL systems, software platforms, software, and configurations possible. Even virtual/remote systems.
- Offer to ‘shadow’ or work a ‘day in the life of position ______’ to best understand a person’s role. This provides an additional perspective.
- When comparing other solutions, be fair. Perform an ‘apples to apples’ comparison. Many vendors tend to use creative marketing terms to describe their features. Drill down and understand what these actually mean for the comparison. By the time the analysis is complete, the Business Analyst’s knowledge should be comparable to the vendor’s Salesperson or Solution Architect. This helps prepare for any questions that may arise from upper management.
- Remember the basics of any requirements gathering: answer the who, what, why, when, where and how.
Effective project management is key
- Hold regular face to face checkpoint meetings (or virtual, if face to face is not possible) to ensure everyone is still on board / contributing on time. Keeping people engaged is important, especially for long term projects. ‘Stand-up’ meetings are valuable as each member shares what they completed in the previous day, what they are working on now, and raising any concerns/challenges within roughly a minute’s time. Anything longer, ask for them to take offline.
- Always record meeting minutes (or delegate a scribe) – indicate the purpose of the meeting, date, start and end times, and who said what in meetings, including details on what was expressed (including tone/highlighting topics discussed in length). Distribute meeting minutes within 24 hours and ask people to clarify/add missing points within 48 hours after sending them or else they will be assumed final and agreed upon.
- Hold people accountable – always have project components assigned to the right people, with deadlines agreed upon by project members. Ownership needs to be clear, especially when working with vendors. Stress the importance of raising questions ASAP if they arise to prevent delays.
Politics are everywhere, learning to deal with this is critical for success
- ‘Push back’ is expected. Not everyone a Business Analyst talks to will be on board with the project. Some may fear a new project threatens their job (especially if it is a process streamline initiative). Or others might prefer a different solution as it offers more job security. The Business Analyst’s job is to hear these concerns, take them seriously, and reduce or mitigate these concerns by highlighting a top 5 for each focus group and trying to have everyone agree. Never dismiss a concern as invalid as it might come back later.
- Respect is earned, never given, and people’s valuable time is limited.
- Learn to ask the right questions with proper context.
- As the Business Analyst convinces others that they are a valuable asset to their team and company’s goals, they will have more support. This takes time.
- In some top tech companies with high levels of competition, standing up for an idea is critical.
- Always maintain composure and back an idea with hard facts.
- Be open to positive criticism. Try to understand all feedback/criticism. If someone has a good point, and adjustments are necessary, take note.
Present the findings – it helps reinforce concepts
- While frustrating, emails and detailed documentation are not always read, or read in detail. People are busy and may see these as a formality.
- Never stumble in presentations – the Business Analyst should know what they are going to say. Having a PowerPoint presentation ready in advance is helpful and helps one look more prepared. Cater all presentations to the audience. For example, if presenting to senior management, keep it short and to the point. Prepare for questions on risk, cost, return on investment (ROI), benefits and competitive advantage, etc. A poorly delivered presentation will be remembered and it will take a long time to regain trust and respect.
- Always answer questions up front and honestly. If a Business Analyst does not have an answer (these cases should be limited as the they are looked upon as an expert), they should tell this to the person asking and get back to them ASAP – preferably within 24 hours.
Continue to improve the solution
- Once implemented, the Business Analyst’s job does not stop there, even after all phases have succeeded.
- For a company to be truly competitive, a solution needs continued refinement. Consider what went well and what did not go so well.
- A solution should be shared in other areas of the company and offer/be open to ideas for improvement.