Pitfalls of cross-functional diagrams

- If you're going to do it right, do it right the first time. No truer statement has been made as you start delving into the lower-level details of the way an organization undertakes their daily activities. Modeling these activities and collecting them together create a valuable reference library, though the library may be of no use if you stock the shelves with languages that you can't read and understand. Cross-functional flow diagrams are most commonly used to capture the flow of activities throughout the end-to-end business process cycle. This is because they provide a great overview of how work flows between functional areas and usually have enough detail to be useful in analyzing gaps, inefficiencies, and complexities. Because of this, there is a tendency for business analysts to start here without truly understanding the full context of the functions that they're trying to document. This is an easy trap to fall into. If you don't do your homework, you will find yourself chasing your tail, validating and cross-checking and, in some cases, having to untangle and redo hours of work. Make sure that you always start with a context flow diagram, even if you think that you know your organization well. This could save you time and your reputation. Cross-functional flow diagrams are also often the main deliverables requested from key stakeholders and project managers and who may not necessarily understand the background work involved in producing an accurate version. A good business analyst will educate and involve those stakeholders early on in the process. This is incredibly useful when needing to sell ideas or options down the track. Another question I'm commonly asked by analysts from all over the world is, what level of detail do I need to include in my swim lanes? This one is a little tricky to answer without context. However, a general rule of thumb is to create a subprocess or process flowchart if you think that a series of steps can be grouped into a single action. The last thing you want to do is clutter the diagram. It's also important not to over-clutter or confuse your diagram with unnecessary detail. Your diagram will remain clear and concise if you simply include a subprocess rather than providing all the detail at this level. There's a rule of thumb that you should not exceed 16 activity boxes on any one sheet. White real estate around the shapes in the models also enables great readability and understanding. This all comes back to educating your project team and stakeholders. If you've been tasked with providing process maps, ensure that you are all on the same page and that expectations are aligned. Take a moment to walk through the types of business process models from the context, functional flow, cross-functional, and detailed flowchart diagrams. Understand what your end deliverables need to be and the process to get you there. This way, you'll have the support of your project team and stakeholders, and the process will be more streamlined. Of course, most importantly, whatever you decide, the key is be consistent across all of your cross-functional flow diagrams. With modern modeling software, there's an avalanche of available symbols, graphics, and shapes to select from. My advice is to limit the options in what shapes you will use as the last thing you want to create in any misinterpretation of what you are trying to share. As you finalize your cross-functional flow diagrams, begin socializing them with your stakeholders. When doing this, there are a few really important things that you should be aware of. Firstly, plan for interactions, reworks, and additional discussions. Don't expect that you'll have it documented right first off. A common problem is not allowing enough time for adequate walkthroughs. Secondly, understand timings of reviews. The walkthrough process always takes longer than you expect, especially if you have a number of stakeholders. Sending documents out prior to the walkthrough session and requesting attendees come prepared with questions can speed this process up. Next, maintain good version control. Ensure the models are the most current as you make any changes so as to ensure everyone is working off the correct version. And finally, authority to validate and provide sign off. It's important that stakeholders who attend verification meetings have the authority to validate and provide sign off if necessary. By following these guidelines and creating consistency in your modeling practice, you'll have a library that is valuable for years to come.