Ask process improvement experts (which I have done over the years in teaching and consulting with such people) what is the hardest part of doing a process improvement project and they tend to say analysis. And in fact, it’s not just among process practitioners that you will hear people say that analysis is their most challenging activity: training program developers, organizational effectiveness types, change management coaches, etc., also tend to cite analysis as the toughest aspect of their work.

Do you experience these challenges in trying to create a current state process model?

• The team gets mired in process problem details
• People have ideas for improvements but you are not really ready for solutions yet
• Some groups do the process one way and others do it a different way.
• Some people think it’s a big problem but you don’t know for sure.

Here are two techniques that will really help you out and make life much easier.

1. Start with a single process instance
2. Keep the I-4 Lists as you document

Start with a Single Process Instance

Begin by selecting a single process instance that the team will follow. Capturing one instance of a real completed process makes it easy to complete the model in 90 minutes or less, and it won’t have the spaghetti look of a process model showing all the exceptions.

For optimum results, pick an instance to start with…

When doing process work, attention is rightly drawn to the detail: the 43 steps in the process, the tests for waste, the flow bottlenecks, the measures of variation and so on. How, therefore, does a process expert keep connected to the strategy? How does he or she avoid optimising a process only to find that there are unforeseen negative consequences for the larger organisation?

The traditional answer to this question is “by focusing on the customer”. But, in my experience this is insufficient. First, it is the strategy that decides which customers to focus on and what value propositions to provide. So a good understanding of the strategy is necessary even to know whether the process work is focused on the right customer or the right service proposition.

The “Big Picture Thinker” and the “Aspiring Developer”

Every Agile team has experienced the frustration of working with a Product Owner who is very well intentioned but unable to provide the clear requirements that the team needs to build the most valuable business solution.

This is the first of two articles that address the specific challenges that you may be facing (or will most likely face) in your work with Product Owners. In this article, the focus is on two of the most common types of challenging Product Owners: The “Big Picture Thinker” and the “Aspiring Developer.”

The “Big Picture Thinker” Product Owner is an epic thinker, able to give the Agile team a high level description of their requirements but unable to describe (or to decide on) specific system behavior. Their inability to provide the team with adequate detail could be due to several factors, including their limited depth of knowledge and their fear of being responsible for decisions.

At a recent engagement, I encountered several departments that asked me to help write their departmental policy on a particular subject. When I inquired as to the governance process for changing existing company policy, they looked at me blankly and said no, I didn’t understand – they needed a new policy, just for their department. After a little probing into the governance of their company policy (this enterprise had a single policy covering everything), and some further discussion, we ultimately settled on writing a new procedure and developing accompanying forms and workflows. I ended up helping this department rewrite their documents into the appropriate format, and working with them to better understand the hierarchy.

This got me to reflecting on how many times in my career I’ve heard confusion about policies, standards, procedures, and guidelines. Reasonable people will differ in their definitions, but here’s how I understand them to work best.