Article

By Cathy Dew

If you’ve been following along, we have gone through almost all the major steps and templates for business process analysis projects.

We started this series with an overview with Winning Big with the Right Business Process Analysis Templates: Start Here. Then we provided a handy matrix to determine what business process analysis templates work best based on your project type. From website to Intranet, this article explains Which Business Process Analysis Template Works for What Type of Project. From there we moved on to focus on specific templates for Survey, Interview, Persona, Process Flow Diagram, Data Flow / IPO, Requirements and RFP.

Now we really, truly are wrapping up this initial series with a discussion (and free downloadable business process analysis template) to dig into the document that will assist you with a development of your application or complex website or intranet – the Functional Specification. Building an application is a huge investment – getting the team coordinated and aligned on the features and function of the application is critical to a successful project.

Getting Everyone on the Same Page

Whether you take on the development effort yourself, with your internal IT department, or you work with a development partner firm, you want to be sure that you know what you are building and are able to communicate that to the developers – the coders, database specialists, engineers and programmers that are responsible for bringing your design to fruition.

Reviewing the documents generated so far (Survey, Interview, Persona, Process Flow Diagram, Data Flow / IPO, Requirements) is an excellent way to get folks oriented to the project. But let’s face it – that’s an awful lot of information to review, and read. The requirements provide the real meat of what the new system must deliver. These are typically narrative descriptions of features and functions which can be hard to imagine what the application would look like or how it will behave. This is where wireframes, static or interactive, can be enormously helpful. The visual is invaluable, but to communicate the entire “picture” a good functional specification includes information about the data elements on the screen and the interaction expected on the screen, which may be different depending on who is access the screen. A well narrated screen, in language that is sufficiently detailed but not technical, can be an excellent way to make sure all stakeholders in the project are on the same page regarding the new system.

Your Blueprint for Success

The Functional Specification is a blueprint of the desired application. It is a living breathing document that speaks to business users, management and developers, ensuring that all parties participate in the design of the application. This includes system features and functions, visual navigation, user interaction, and information delivery environment. This document is the centerpiece of a cooperative and iterative process of reviewing, documenting, prototyping, review, and refinement involving the entire design team, developers and key stakeholders.

Effective communications, buy-in and building a community of champions starts well in advance of launching the new product.

The functional spec is another opportunity to engage and build trust with the user and other stakeholders. It is an opportunity to clearly confirm that you understand the challenges and pain points of the current process and that you have incorporated direct input for the people closes to the process in creating the new process. You can have confidence that you are have the best solutions for the most critical problems.

Work It Out on “Paper” First

As you might imagine, as soon as the design team starts developing wireframe depictions of screens, the business users start engaging more specifically and effectively. Once you can “see” the interface a different level of review and feedback is possible. This is critical to getting to a solid design of your application. 

The wireframes not only serve the business users’ understanding, they also help the technical development team understand the desired system. With the addition of the data section, the technical design of the database can begin. The interaction section informs the code required for transformations, calculations and other data-based updates.

Disclaimer

• Wireframes do not represent visual design.
• Wireframes typically do not represent interaction design. The point of the wireframe is to understand the function and the data and a snapshot of the flow.
• Wireframes are an excellent tool for nailing down data, labels and overall purpose of a screen.
• Here is a downloadable template of a wireframe taken from a functional specification. It is for reference purposes only.

Schematics can be implemented statically, as pictures on paper, or they can be online with some level of interaction. Simple interaction might be navigation between screens and sections of the application. More sophisticated examples of interactive prototypes provide the illusion of executing the underlying function. This might include submitting a form, adding a new item to a list or error checking. Making the wireframes more interactive makes it feel like a real system, which is good. It also takes more time making it more expensive. For complex functions the investment may be well worth it.

Regardless of the medium (paper or online), you should expect several rounds of revisions to the schematics. This process is when the real value of this business process analysis template pans out. Get as many issues identified and resolved before technical development begins.

Making changes to wireframe (paper or interactive) is significant cheaper than revising code.

Beyond Wireframes

While wireframes are the centerpiece of the functional spec, there are other sections of this business process analysis template that provide real benefits to your project. This is also the place where the project team can describe aspects of the system that are overarching and not specific to a single screen or functions. This might include:

• Summary description of the application, the primary purpose, target users, etc.
• Navigation across the application including what is global and what may be specific to a section
• Error processing, validation checking and the resulting message can be centralized into one location and referenced throughout the document.
• Primary business processes and workflows can be described holistically to provide a context for the overall solutions which may include statuses for the entity being tracked, e.g., an application for a permit.
• Notifications critical to the overall processing including how (manual or automatic) and when (scheduled or triggered by an event)

Advantages of the Functional Specification

I know you’re convinced that this truly is the centerpiece business process template for the development of an application. But just in case, lets recap the benefits:

1. Allows participation across the team and stakeholder community
2. Builds consensus and buy-in
3. Allows business users to see their future
4. Provides a platform for continuous review and improvement
5. Allows management and executives to understand and endorse the project
6. Gives the technical team an understanding of the business case for the project

In the End

This concludes our introductory series on business process analysis templates. We hope you have a good understanding of the suite of tools, when to use then why to use them and you even have some tangible examples to jump start your project. If you need more information or want help with your project, please don’t hesitate to contact me.