How to Figure the Detail of Process Models

I love that a fellow analyst asked me a question as they were having trouble being asked about putting “narrative on their process model.” 

We started with the first question – WHY?   Simple, yet seriously, we’re so good at OVER analyzing and getting into analysis paralysis that sometimes just trying to figure out what is going on can save others (but especially us!) LOTS of valuable time!

With the first question, the answer was easy – they want more information.  Okay, so then the next questions is then about what the PURPOSE of the model is?  What are you trying to accomplish with your process model?

Good foundational, IIBA® BABOK® Guide v3 (2015) states that the purpose of process modeling is to provide a “standardized graphical model…to show how work is carried out…as foundation for process analysis.”  So are we showing ONLY how work is carried out?  Or are your stakeholders asking for much more?

We have data models and stakeholder RACI matrices and other valuable tools because they’re great at what they’re used for!  They each have their own purpose!  So ask yourself if you’re ever having difficulty with your process model because you’re trying to do WAY more than model a process?

---

---

This is the analysis skill – identify what questions are being asked or needing to be answered and facilitate getting that information to the needed decision makers.  If people ask lots of questions about who is doing what on your process, then maybe we do need greater detail on the stakeholder ownership.  Perhaps there is no ownership?  Or don’t overanalyze and just add a new swim lane if it makes the users happy (and of course understand better!).  If people ask lots of questions that revolve around data, do we need a data dictionary and some data modeling or data flow diagrams?  This is common when you meet with stakeholders of different levels of focus.  Too often process steps, decision points, data elements, stakeholders and end products are thrown at the analyst.  Do not feel compelled to write everything on the process model.  Write PROCESS on the process model and make notes on the side.  Then look at your notes.  Are all the notes about data?  Then your own notes tell you that you need some data definition.  And don’t be afraid to acknowledge that there’s a mix of high-level overview requests mixed in with the “give me the technical details down to the line of code” demands.  Just then make your model flow so that each view or screen or page is only showing ONE level.  Then with technology today just link it to the page with the lower level of detail.  Don’t over complicate it trying to take a full course on modeling software or anything.  Simply list high level functions with overall business areas on your main page.  Then for each one of those functions, create a “clean page” with just that function’s information.  And then you can work WITH your stakeholders to define as much information as they at that deeper level, while keeping everyone on the same page at that higher level.  Even better, with this approach, you just created a strategic, overview perspective as well as tactical or operational details.  Now you’ve helped multiple groups from starting with a single model!

See what information comes up from the stakeholders on what is missing or needs to be added to make the process model USABLE.  You are creating a process model for OTHERS to use.  If the level of detail is high and you’re not sure it’ll work – ask!  Share it out and see if people have questions.  If they have none, then you’ve done what is needed to help others get things done!  Analysts process model to facilitate, not own.  The model is the stakeholders’, teams’ or client’s.  It’s for them to get their work done, complete projects and create great new products.  If they ask lots of questions, then help them get the answers.  And as you do, always think what is the most efficient and effective way I can get them the answers.  Just because they want all the information on the same visual, does not mean that it will help them answer their questions.  But to know what to capture appropriately on process models, means you need to know what everyone is trying to accomplish by using your process model.  Make it an actionable document.  Anything you produce should be reusable over and over again – from decision making to operations and troubleshooting – and by people other than you!  That’s the true value! 

So next time someone tells you that your process model is lacking lots of information or needs other data and elements added, ask why and get clarity on the stakeholder’s need and what they hope to accomplish WITH your model.  Then work with them to help develop a model that answers their questions and supports their decision making.