Follow-up on processes: When money is not enough - a public sector example

Recently (February 2015) I saw a local TV report [1] on the lack of timely pothole repair in the city Houston – a common complaint in every big city. However, in this case something flashed on the screen that caught my eye – a business model depicting the hiring of new street repair crews (i.e., a UML [2] activity model with swim lanes).

The reporter, Ted Oberg (abc13 KTRK-TV), stated that even though the city allocated an additional $10.8 million for pothole repair and set pothole repair as a priority, it still took the city 5-7 months to hire a new street repair crew. Eight months had passed since the city mayor stated, “I have done what I’ve needed to do,” [1] and only 20% of the funds was actually used. Even worse, pothole repair was down 45 percent with citizens complaining – an indication of an ineffective process. In comparison, the county government surrounding the city of Houston locks in street repair crews with on-call contracts and hires new crews in less than half the time.

Note: Not all problems are resolved by just “throwing money” at it.

See the reference [3] for the existing Houston process model for hiring new street repair crews; it consists of 26 tasks along with 5 reviews, 7 sets of documents, and 2 approvals.

In the context of the above situation, let’s imagine ourselves as business analysts working for the city and how we would approach Houston’s hiring new street repair crew process challenge.

Changing a process whether it be by redesign or incremental improvement is typically done within a four phase cycle: (1) definition, (2) analysis, (3) implementation, and (4) control. Note even though the phases are numbered, process change is a never ending cycle since things continue to change: the environment, the market, competition, customer demands, management (business rules), etc.

The most importance phase, of course, is definition. It’s a good practice when starting a process redesign/improvement project to find out the:

1. Organization’s value chains – processes that produce a customer product/service. In this case, we are fortunate; we have a documented process [3]. Note: organization charts show who is functionally in charge and their relationships, but not how the organization produces products/services.
2. Owners of processes – authorities who manage and approve changes to processes. Here, the organization charts are useful, but possibly even more useful are activity models with swim lanes. Swim lane actors are good individuals to start searching for process owners.
3. Owner expectations – process performance goals: time, cost, quality, flexibility, controls. Owners typically monitor process performance via a dashboard of measurements advising if the process is meeting expectations. No dashboard means no control; more on this when we review the control phase of the cycle.

Assuming we know the above three things, we now start a dialogue with our project sponsor. What is the problem/opportunity? Given that, what is the sponsor’s goal? Is the focus to reduce time/cost, gain quality/flexibility, and/or tightening controls? Given the goal, what is the measure of improvement? In the case of our pothole project, we need to reduce the total time it takes to hire a new street repair crew (i.e., produce an approved contract). Of course the question is by how much: 10%?, 20%?, 50%?, 80%? Note the goal is quantified; the amount of improvement is the difference between deciding on a process redesign or an incremental improvement project.

Redesign is a judgment call and is typically accompanied by a goal demanding a dramatic change due to a product innovation or a threat to the business. For this project we decide that anything above a 50 percent improvement goal demands a radical change – a redesign. A radical change then implies a product-based design approach [4]:

1. Ignore the existing (As-Is) process
   1. Decompose the customer product (an approved contract) down to its data elements.
   2. Form a team and design a new process to produce the data elements of the customer product.
2. Optionally, conducting a benchmark study; in this case there is an opportunity with the county. Note the result of benchmarking typically is a clone of the partner’s process rather than an innovative design.

But suppose the project sponsor sets a goal of a 20% improvement. This is within the realm of non-radical change. This implies an incremental process improvement approach:

1. Use the existing process
   1. Validate the existing process (As-Is) model with stakeholders.
   2. Ensure the process encompasses the entire value chain.
   3. Document all assumptions and decision business rules used in the existing process.
   4. Establishing a performance baseline for the existing process – to be used later in building a credible business case.
   5. Determine if all process tasks add customer value (controls are exceptions), sequenced appropriately, and evaluated for possible parallel processing.
   6. Analyze the existing process metrics in order to identify where there are process delays and/or opportunities to speed the process (Lean/Six Sigma techniques).
   7. Conduct a root cause analysis to identify why there are process delays (Fishbone/Five Why techniques).
   8. Challenge all assumptions and decision business rules.
   9. Develop and validate a set (To-Be) of proposals based on different levels of risk. Along with the proposals, plan a resistance strategy (needed for all projects).
   10. Build a credible business case for each proposal (i.e., compare proposal with the existing baseline.) Since this is the public sector, the justification is efficient use of resources and an effective customer product rather than profit.
2. Optionally, conduct a benchmark study; in this case there is an opportunity with the county.

With the definition and analysis phases behind us, we now focus on implementation and control phases. Regardless of what analysis approach (redesign or incremental) we used, we now need to:

1. Validate and justify our solution with the process owner and other stakeholders.
2. Ensure that the process change is supported by the necessary organizational structure, technology, and training to be successful.

But hold on, our project is not done. We need to ensure that the owner can maintain the process – control. Our legacy to the process owner is a dashboard of control and trend reports with leading and lagging indicators [5]. These indicators advise the process owner when investigation is necessary to ensure that the process continues to meet expectations. As I stated in the introduction, this is a continuous cycle.

As of this writing, the city of Houston is still struggling with their pothole process. The point of this article is not to recommend a solution, but a path to resolution and a profound lesson learned. Not all problems are resolved by just “throwing money” at it. In fact, the lack of a budget being used is an indication of a process problem. Check the process through the established metrics; is the process meeting the owner’s expectations? It may be time to conduct a redesign or an incremental improvement project.

Author: Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials. He holds an Advanced Master’s Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) International and the International Association of Facilitators (IAF).

Mark is the President of Monteleone Consulting, LLC and author of the book, The 20 Minute Business Analyst: a collection of short articles, humorous stories, and quick reference cards for the busy analyst. He can be contacted via – www.baquickref.com.

References:

1. http://abc13.com/traffic/houston-road-repair-goes-down-a-pothole-wormhole/504700/
2. http://www.uml.org/index.htm
3. https://purchasing.houstontx.gov/docs/Formal%20ITB%20Contracts%20Process-Over%2050K%20v6.pdf
4. Monteleone, M. A., (2015): Redesigning Business Processes Using Product-Based Design. Modern Analyst
5. Monteleone, M. A., (2010): A Baseball Analogy – Monitoring Processes through Leading and Lagging Metrics. Modern Analyst