Resources

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.

Is your improvement project failing? Depending upon which study you reference, roughly two thirds of projects fail to produce their promised outcomes. Such failures result in a tremendous waste of resources and even more unfortunately – lost opportunities to seize advantage over competitors. Looking deeper, we often find failure is almost preordained. Projects are pushed out of the chute armed with confusing directives and inadequate resources. Once a team is assigned to address an opportunity, invariably the first task is to translate leadership intentions into a realistic deliverable. Such translations can be overly challenging to make. In the name of expediency, project teams are routinely asked to run out on the ice before strapping on their ice cleats. Without stable footing, epitomized by a well-defined mission and clear field instructions, they lack the foundational necessities to hit the ground running.

When looking at BPM there appears to be two distinct worlds Pegasystems Inc. and one that is more standards-driven that includes vendors, such as, IBM, Appian, etc.  BPM using Pegasystems’ PRPC versus BPM proscribed by this latter set of vendors represent two very different philosophies on how to implement BPM systems. However, I would say that the one thing that all vendors appear to agree with is that an enterprise-grade BPMS is a truly disruptive technology, since its tactical mission is usually to:

• Extend the functionality of existing apps, 
• Enable disintermediation between applications, 
• Tightly-integrate processing gaps among disparate applications
• Provide opportunistic business application behavior that takes advantage of new technologies and techniques in order to deliver superior functionality

There are many ways to ‘do’ business process improvement projects. It’s best if the company has a methodology from BPM, Lean, Six Sigma, Reengineering or some other methodology. Here’s the one I use, starting with selecting the project and ending with monitoring and sustaining the project; ‘doing’ the process improvement project means completing the section in the middle from Chartering and Staffing to Implementation Plan.

Companies use a number of methods to conduct the BPM project from using a Six Sigma Black Belt as an expert, to having a Business Analyst do interviews with subject matter experts and developing the as is model and to be map, to using different half day workshops for different phases of the process with the appropriate stakeholders. The one I highly recommend and have used with over 100 different processes is a team-based method.

Anyone who has worked on waterfall projects knows the challenges:  The lack of communication between the business users and the developers; the predetermined (and immovable) requirements; the quality issues that are not evident until you are too close to the release date to safely address them; and the frustration of having to wait months (and sometimes years) before your efforts result in a live working solution.

When you make the move from waterfall to Agile projects, you have two choices:  You can choose to either block out your waterfall experience altogether (like any traumatic event!) or you can choose to leverage your experience to make yourself an even more effective Agile team member.  Here are three ways that you can use your waterfall experience to your advantage: 

Process management is at present one of the most often implemented methods of management within organizations (Armistead, Pritchard & Machin, 1999), though it is not a new concept in and of itself. Its foundations have been set as far back as 60 years (Deming) or even perhaps 100 years ago in Taylor’s work (F.W. Taylor) (Deming, 1986). Traditional process management assumes that processes cannot be altered by process performers in the course of their performance (Gartner IT Glossary, 2016). Within the traditional model, the performance of processes is tied to the decisions of the management of a given organization, which are reflected in standard process models (often in the form of rules and regulations or procedures). But as numerous research demonstrates (Kemsley, 2009a; Pucher, 2010; Ukelson, 2010; HandySoft, 2012), traditional BPM is useful in 20% or perhaps 30% of processes of the organization.