I sat down with some of DOOR3’s BA team to discuss the business analyst’s role in the process of a technical discovery. On the call with me was Bart Michalak, our business analyst practice lead, as well as senior analyst Amy Lo, and junior BA Zev Gottdiener. We jumped straight into our conversation about what exactly a business analyst does at DOOR3.
“A Business Analyst’s role is to serve as the primary bridge between IT and the business,” said Bart. “Using a variety of analysis techniques, we aim to assess processes, identify both technical and functional requirements and to define really what it is to have the MVP stage of a project get completed. On top of that we collect a series of additional requirements which we would then use to build upon that system in a natural and intuitive way. So that it enhances capabilities.”
Much of what the BA strives to do is to make sure there is constant communication and delivering of recommendations to the stakeholders based upon input and feedback collected as a team. With clear communication, a BA can ensure that a clear and unified vision for the project and its purposes is agreed upon.
An additional factor in this liaison responsibility that BA’s hold is the reality that the client may not have a dedicated software development team to provide technical management of the project, leaving project managers resourceless to deliver the vision they reached out to DOOR3 to realize. Business analysts may act as a sort of proxy for our clients, to make sure that the deliverables align with both the client’s vision and technical needs.
“We are in the unique position of being able to take your ideas and your goals and help reduce risk and common pitfalls so you can get a better sense of what opportunities and types of value you can add through using your ideas as building blocks.” said Zev.
Working with building blocks implies that a business analyst’s role with the client has an early onset, but just how early could a client expect to begin working with a business analyst?
“The earliest junction would be when we undertake a discovery track,” says Bart.
Discovery tracks at DOOR3 are oftentimes used as a preliminary stage to the implementation of any project. These tracks are used to learn more about the client and to identify specific business needs. It’s an opportunity for a client to get to know the DOOR3 process and people that will help develop and deliver the product.
“It’s an opportunity to make sure that we have all of the details on the table so that we can help you both organize and also strategically plan out what you’d like to do.” Amy added. A business analyst for an agnostic business analysis company like DOOR3 is likely to become a subject matter expert in specific industries based on their work experience. This is one of the primary reasons that the BA for a client may join the process very early on in the interactions between a client and their primary consultant. Oftentimes a client will have a lot of different directions they can go in order to complete the objective they initially reached out to us with. The BA can step in to provide their expertise on the matter to help select a direction for the project based on their previous experience.
As part of the technical discovery process, a BA will take their findings and use them to analyze what the final deliverables of the project might be. These deliverables may manifest as use case diagrams, backlogs of prioritized features and functionalities, roadmaps and timelines for execution, etc.
As Bart lays it out: “We’ll run through the discovery, analyze the workflows, identify opportunities for improvements of those workflows, and then define the deliverables through a variety of different forms.”
These deliverables may be adjusted as the process to finished product continues, but they should at least be able to move the project out of the preliminary stage and into the implementation stage.
A DOOR3 Technical discovery may take the form of a three to five day workshop where both our team and yours sit down at the table to really understand what your needs as the client are. Nothing is predetermined when it comes to the development of bespoke solutions, so there’s nothing that is “taken off the shelf” so to speak, during these meetings. Dynamism is key, and the business analyst’s role in these meetings is to listen to the conversation and focus on where the best discussion points are appearing to develop process flows into the final solution. At the end of the day a high level draft may be produced as something to reflect on, and then the next day is revisited and pulled apart to gain more specific insights.
Returning back to the ideas of BA’s acting as proxies or liaisons, another responsibility in these meetings for the BA is to referee all the different ideas coming out from different perspectives within an organization.
“on any one given flow, there’s a number of user types that might be involved. Each individual may have a specific perspective on the importance and the outcomes of a given flow. And a large part of our job is to hear from each and every one of those perspectives and make sure that the flow that we come up with is one that identifies and serves each individual perspective.”
At the end of the discovery process, everyone will hopefully walk away with a list of prioritizations for the project.
While the process of a technical discovery is a tried and tested way to break down the needs of a client, it’s not without its challenges, and some challenges arise more frequently than others. More often than not, these challenges can live within implementation and prioritization of a solution.
“A big challenge is simply that since a discovery is part of the planning phase, you don’t necessarily know what’s going to happen during the implementation when you actually start developing things”. Zev added. “there’s a number of different changes and sort of constant challenges.”
While diversions from a plan may ruffle feathers after a technical discovery, what’s more likely to present a challenge is a lack of clarity on what prioritization actually means from a development perspective. There are minimums to what a system needs to be able to accomplish in order to fully achieve its purpose, and what a system needs is not always in alignment with what a client wants.
“I think a challenge that I faced in the past is a lot of times you are dealing with high level sort of business stakeholders and they have really strong opinions and views about what exactly the solution needs to be” Amy shared. “Sometimes we have to assist with working back to what exactly the business direction is”.
Of course no one can fault business executives for having expectations of how their custom solution will operate, but sometimes the business analyst’s role is to steer business leaders to what’s achievable and beneficial to the end user based on the resources available to them.
The discovery has ended, the deliverables have been defined, so now what? Is the prospective client now pushed into a contract with DOOR3, even if they aren’t certain about the capabilities of the team?
“Definitely not.” As Bart explains,
“You basically have a neatly tight package where you can go and then use that to shop around with other builders, and in most cases that’s the sort of thing we encourage. We really do back up the analysis work that we produce to back up our estimates.”
The purpose of a technical discovery is not to lock a company into an engagement they do not want to be in, but to get a feel for the team and our processes in a non-committal way for a lower price.
“You’re not just getting on a call with the sales team right?” Amy asked.
“What we offer is really a multidisciplinary approach. You’re getting the BAs who eventually may very well be on the project with you, for the long haul. You’re getting an award-winning UX design team giving you insights and feedback. And then you’re also getting our experienced technical teams and technical architects that are able to assess and provide you options.”
Companies who go through the process of a technical discovery have the capability to begin implementation immediately, shop the deliverables around to other companies, or scrap the whole discovery entirely. The next steps are entirely left up to the client. Regardless of what choice they make, there was one final rule of thumb shared by practice lead Bart which he gained from his upbringing.
“When I was growing up my dad was a carpenter. He would always tell me that the number one thing that you have to do is think about the problem that you’re solving, and then always make sure to measure twice so that you only have to cut once. And there’s lots to be said for that.”
We are thrilled to announce DOOR3 has received the GDUSA American Digital Design Award for our website and mobile redesign work for our client, Retrievr. The GDUSA American Digital Design...
Do you have goals for your product or service, but you aren’t sure how to get there? Consider a UX audit, through which you can identify usability issues, uncover their...
يسرنا في «دور 3» للأنظمة الرقمية أن نعلن لكم عن إفتتاح فرعنا الجديد في منطقة الشرق الأوسط وشمال إفريقيا من خلال وجودنا في الرياض بالمملكة العربية السعودية. وتأتي هذه الخطوة...