Business Process Analysis Template

Business analysis is a vital function for technology projects and sometimes I view it as an art as much as a science because there are a lot of dynamic (and sometimes creative) aspects to doing it well.  Sometimes we can operate informally, without documentation to track and verify requirements.  Other times, descriptive documents, matrix documents, diagrams, and other tools are needed.  Sometimes we have set expectations of content and format of business analysis inputs and outputs, while, other times we can discover and develop as we go.

Business analysis and requirements definition tend to require more formalized approach when some of the following circumstances are true:

• The business has formal obligations to another party
• Performance requires contextual business knowledge
• Participation includes a high number stakeholders/team members/resources, third-party participants, or virtual teams
• Project environment is complex
• Solution is complex
• Project has many moving parts
• Low risk tolerance
• Tight budget

When developing requirements, understanding the business needs very well up front is essential for ensuring capabilities being delivered are scoped and prioritized properly.  I find it helpful to take a business process centered approach to requirements.  This ensures that we will be solving the correct problems for the business because our focus is on the inputs and outputs of the process, not focused on intermediary challenges that exist with the current state that may be irrelevant in the future state.  Secondly, it helps us to minimize many of the communication challenges related to requirements definition.  Using documentation to capture the business process details helps ensure that the team understands the requirements the same way.  Consistently referring to the requirements as either "Business Requirements" (non-functional, needs and wants) vs. "Solution Requirements" (functional) helps baseline communication and makes it easier to determine if something relates to "current state" vs. "future state" (see also General Business Requirements vs. Solution Requirements).

I'd like to share a tool I use, that I refer to as the Business Process Analysis Template.  I initially developed this tool in Excel in 2005 for an enterprise wide CRM initiative and since that time the tool has undergone many iterations.  Lately, I've been using Word.  When I begin a new software development or systems implementation project, I do discovery and gather requirements using the template.  I fill in one Word document per business process/stakeholder.  In other words, I may have several Word documents for a single process because I am seeking independent feedback from each stakeholder.

Once completed, I gather the documents and consolidate the information to one Word document per process, marking up the source and qualifying some of the feedback collected.  I store the collection of these business process documents in a SharePoint site and refer to these as I begin design activities.  These write-ups become extremely helpful when writing the Solution Requirements (e.g. User Roles/Personas, User Stories, etc.) and when prioritizing deliverable for each development sprint.

Business Process Analysis Template:

The Business Process Analysis Template has worked well for software development solutions as well as large, enterprise system implementation projects such as Customer Relationship Management (CRM), Enterprise Resource Planning (ERP), and Enterprise Search and Discovery.  Of course, the tool can be adapted and used for many other purposes.


Reference

Bisciotti, N. (July, 2010).  General Business Requirements vs. Solution Requirements.  Retrieved April 5, 2017 from http://njbblog.blogspot.com/2010/07/general-business-requirements-vs.html.