Author: Scott Silvestro

In many organizations, a business analyst is often assigned to a project where they may have little to no background on the actual business process they are supposed to analyze.

The pressure to capture requirements quickly will mount as project timelines are often too tight. However, as a business analyst, carving out time to build a business workflow diagram will not only help with writing meticulous requirements, but will also enlighten stakeholders for more comprehensive requirements farming. Traditional business analysis calls for stakeholder engagement, planning and then requirements gathering. While most definitely adding more time sensitivity to your project plan, the business workflow mapping is integral to the quality of a project’s success. As BA’s, its not hard to see why a business workflow diagram is valuable, however this crucial step is often a ‘nice to have’ artifact or sacrificed altogether for the sake of the project timeline. Understandably the business workflow diagram is an easy target to trim the fat on a project time line, but I would argue that it is too critical to the quality of the success of the project to be brought to the sacrificial project alter.

The first step in solving a problem is to understand it. As I interview more and more stakeholders, I’ve realized that each person contains an understanding of part of the business process puzzle. Only when these pieces come together can you call a solution comprehensive. Creating this artifact early on in the project, will not only better flush out the problem, but will educate the entire project team on their own business process.

As a use case to support the critical value of the business workflow diagram, I was assigned to a project involving the replacement of a technology transfer application at a large academic medical center. Pre Google-search, I had never heard of “technology transfer”, so I started off trying to understand the business workflow. The business process diagram was particularly helpful in this example as many institutions manage their technology transfer processes differently. My customer had been working with a solution that was over 20 years old and their business process as a whole was in dire need of an update. After meeting with the stakeholders, a vision began to take form. I started using Microsoft Visio, adding in boxes, moving arrows, connecting the dots, watching this business workflow diagram grow and grow. Despite extensive workflow conversations, I often needed to circle back for clarity, only to hear “Oh yeah that’s right I forget we do send that out” or “Well yes, we do have to enter in those details, but that’s only when a particular type is selected.” Both of these instances illuminated a new part of the workflow which not only grew my diagram, but also the stakeholder’s understanding of their very own business process. After I was satisfied that I had successfully captured the workflow, I began circulating the diagram for sign off. I asked each stakeholder to review the workflow, respond with any edits or with their approval. Almost every stakeholder offered more edits, not because I had missed something per se (although admittedly that happened too) but because stepping back and looking at a comprehensive diagram made them realize something new. After a couple of rounds of edits, I finally received full approval from the stakeholders.

Now what? As I began the requirements gathering meetings, I presented my approved workflow on the conference room screen at every single meeting. Like a painting, I used the workflow as a talking point to guide the requirements construction for this new application. As we dove into the business requirements gathering sessions, we often took a pause to reexamine potential changes to our business model. As a business analyst, I welcomed the opportunity to reexamine current business processes and challenged my colleagues on their business process. As a project artifact, the business workflow diagram was memorialized in the appendix of the business requirements document and on some of the senior leaders cork boards.

Even beyond the project, the business can utilize the business workflow diagram artifact in so many other ways; from training, onboarding, reorganization and six sigma diagnostics. The artifact should be alive, challenged, changed, reexamined and updated whenever possible. The business workflow diagram not only enhances the quality of one project, but I would argue it will be a critical artifact for many projects to come.