Let’s assume you’ve done your homework and scoped a project that meets specific business needs or objectives. It’s easy to take a deep breath, kick back, and relax…waiting for the implementation of these great ideas to see themselves through to completion.
But your work as a business analyst is only half-way done – you are at step 5 of the 8-step business analysis process. The task at hand is to engage the technology team in actually solving the problem. Without a focused and engaged IT team you’ve got a well-defined problem that may never be solved.
I hold a firm belief that everyone deserves the opportunity to understand the larger context of the work they are doing. This doesn’t mean that everyone will get it or even care, but the opportunity should be there. It simply does not make sense to close off information about the value a project provides to an organization or the real problem you are trying to solve.
In even the smallest of projects, you will probably engage multiple people at different stages of the project…think about it…development leads, quality assurance, developers, database administrators, infrastructure folks. While a project kick-off meeting is valuable and important, it won’t get the whole job done. Providing business context should become part of your DNA when talking with an implementer.
I am passionate about this today, because I stumbled over myself on this one last week. A new member was added to the team to complete a relatively discrete data task. I had nearly perfectly detailed requirements documentation about what needed to be done and we talked through them. I completely forgot to step it up a level and communicate why we were doing this and what I knew about the data and users. As a result, the new team member spent a few hours wrestling with what he rightfully assumed was a real issue which, once we talked through it, had a simple solution.
So, don’t get task oriented and forget to share your knowledge. Before walking through detailed requirements, take a moment to consider the perspective of the other person. Are they new to the project? Are they already engaged in a piece of the project to which this can be related? What would you want to know if you were in their shoes?
>> Work Better With Technical Stakeholders
Here are some articles from the archive about working more effectively on the technical aspect of a project:
>> Learn the Business Analysis Process
An essential element of succeeding in a new business analyst job role is understanding the business analysis process. We walk you through an 8-step business analysis process in the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations, how to create a timeline for a new business analyst assignment, and be prepared to handle the more common issues BAs face on new projects.