This video discusses some of the issues that can surface when you create the cross-functional flow diagram, as well as common mistakes that can be made when developing the model and how you can avoid them.
- If you're going to do it right, do it right the first time. No truer statement has been made as you start delving in to the lower 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 are trying to document. This is an easy trap to fall in to. 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 sub-process or process flow chart 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 sub-process 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 flow chart 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 iterations, re-works, 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. 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.
- Using common modeling tools
- Determining when to use a particular modeling diagram
- Avoiding the pitfalls associated with each diagram
- Creating diagrams
- Leveraging key stakeholders