Recently I was running an online coaching session with a guy from Florida and he asked me how to approach building process maps for smaller projects.

This is a good question so I will share some of the elements we discussed live, hoping they will also be useful for you.

By the book it would be best idea to start building process architecture top-down (Burlton&Harmon style). However this will take some time and require the resources (just think about stakeholder analysis, workshops, agreeing the process architecture and process goals)

You can also try to make the process faster by applying some process frameworks like APQC PCF to avoid reinventing the wheel.

However what should you do if you are running a mid-sized project inside the organization and just want to make sure there is some order in the way you approach your models?

Here are some tips:

1. Try to identify what processes are in scope of your project. Ideally – try to connect them with the high level architecture or at least try to figure out what is above (how does it fit your company value stream). For the time being those can be just names of the processes, so it should not take you more than 15 minutes if you have appropriate people available. Easy? So move on.
2. Now let’s think what are the processes before and after those of your interest (they are sometimes called upstream and downstream). Here we are trying to see the connections and dependencies (more on this in the points below). 2 minutes per process perhaps?
3. For each of the processes document the most important elements. Apart from name of the process (by the way – it makes sense to have some naming convention for your process models with identifiers) you should at least capture:
   a) Who is the process owner. This person will likely have authority to decide when some important changes are needed and can help you connect with proper people who know what is going on in the process. In a perfect world – 5 seconds. In less-than perfect world – sometimes minutes (few mails and telephones ), and sometimes days (few workshops) may be needed to find a person that identifies as a process owner.
   b) What is the process goal. This is super important, because if you know why do we run this process, you can filter improvement ideas and make better design decisions. Again – it can range from minutes to days.
   c) What is the process scope. I personally more and more like IGOE approach in which you identify Inputs, Guides (e.g. company strategy, policies, …), Outputs (e.g. products) and Enablers (all the resources that allow your process to transform inputs into outputs). This can take you some time (but during few workshops I could do it in less than 10 minutes per process, but it is really helpful later on. Additional bonus – if you start with IGOE it is much easier to identify the start and end events of your process, which obviously helps when you need to do detailed modeling.
4. Now the fun part You need to recall what is the goal of your project, how much time/resources do you have and decide which processes deserve to be modeled in detail and which ones do not need a model. This last point actually deserves an additional post, so stay tuned.

Now it is your time. How do you approach creating (mini) process architectures in your projects? Put your experiences in comments!