One question I regularly ask myself as a program manager is: If I were no longer managing this program tomorrow, would it continue to function effectively without me?
It is a simple question, but it has shaped much of how I manage.
I manage a Third-Party Program in local government, a regulatory program that depends on people, processes, technology, data, policy, and external stakeholders working together. Through my involvement with SPQA and my experience with the Baldrige Excellence Framework, I have gradually found myself using the Framework in my everyday work. I am not sitting at my desk going through the Baldrige Criteria. Instead, the questions and concepts have simply become part of how I think about the program, particularly when I am trying to understand where we are, where we need to go, and how we create a path between the two.
Our program has significant opportunities for improvement, and many of the results I want us to achieve are still ahead. The beauty of the Framework is that it gives me a way to think systematically about how we get there.
When I ask whether the program would function without me, I am really asking how deeply our processes are established. Does the process live in the program, or does it live in someone’s head? Can another person understand it, follow it, and produce a reasonably consistent result?
There is another question behind it that is equally important to me: Would the process produce a reasonably consistent outcome regardless of who is administering it?
In a regulatory program, consistency is also a question of fairness. Every person brings judgment, experience, assumptions, and biases to their work. When a process leaves too much room for individuals to decide which steps to follow, when to follow them, or for whom they should apply, those individual differences can begin to influence the outcome. A systematic process creates a common path for evaluating cases, applying requirements, documenting decisions, and reaching outcomes.
Professional judgment remains an important part of regulatory work, and that judgment can operate within an established process where the same requirements and fundamental steps apply consistently from one case to another. For me, formalizing and operationalizing processes therefore serves several purposes at once: it creates continuity, supports consistency and fairness, and reduces the extent to which the outcome of a process depends on the individual administering it.
That thinking has led me to formalize processes through policies and standard operating procedures, then reinforce them through training and repetition until they become familiar ways of working. Over time, I have taken that thinking one step further by building many of those processes into the digital applications we use to operate the program.
While an SOP establishes the process in writing and training establishes it as a shared practice, a well-designed application can establish it as part of the operation itself. The application guides the user through the process, captures the information we need, and creates consistency in how the work moves. Once the process is built into the application, changing it requires an intentional decision. Someone has to identify the need for a change, define what should work differently, and modify the system accordingly. The process therefore has a certain durability; it can still evolve, though its evolution becomes deliberate rather than dependent on individual interpretation or memory. Over time, the application becomes part of how the organization preserves the process itself.
I also think about how we know whether the process is working?
For each process, I try to think about the result it is intended to produce and what we could measure to understand its performance. What is the metric? What does the trend look like over time? Are we moving in the direction we intended?
When results are measured consistently, we begin to create a history of the program. At this stage, I am primarily interested in whether we can recognize change over time. Are we seeing more or less of something? Is the direction changing? Is a pattern emerging that we could not see from individual cases or day-to-day experience? As those trends are reported consistently to senior leadership and, where appropriate, shared publicly, we establish a baseline and gradually build enough history to recognize when something begins to shift. That change gives us something to investigate, learn from, and eventually act upon.
There is also a longer-term purpose: continuity. A future manager does not have to reconstruct what happened from individual experiences or institutional memory. Instead, they inherit a record that shows how the program has changed over time. The process tells them how the work operates, and the data tells them how the program has been evolving.
Of course, measurement also exposes the distance between where we are and where we want to be. I find that valuable. The purpose of the metric is to help us see the system clearly enough to improve it.
I have intentionally created feedback loops with our stakeholders through monthly Forums and ad hoc focus groups. These sessions give stakeholders a place to tell us what they are experiencing, identify friction in a process, question assumptions we may have made internally, and help us evaluate possible improvements. They help me answer another question: How are people experiencing the process?
The people who interact with a process experience it from a different vantage point than the people who designed or administer it, and that perspective can reveal gaps, unintended consequences, or opportunities that may be difficult to see from within the program. Their experience also helps us understand the meaning behind some of the trends we observe in the data. A change in a metric may tell us that something is happening, while the conversations with stakeholders can help us understand what may be contributing to that change.
The monthly Forums and focus groups also allow that information to accumulate over time. When the same concern appears repeatedly, or when different stakeholders describe similar experiences, we can begin to distinguish an isolated issue from a broader pattern. That gives us a stronger basis for deciding where to focus our attention and which processes warrant a closer look. The exchange also gives us a place to explain what we are seeing, share changes we are considering, hear how stakeholders respond to those ideas, and return to the conversation as the process evolves. Stakeholders can see how their experience informs the program, while the program gains an ongoing source of information for evaluating its own decisions.
When we consider that experience alongside the trends we are measuring, we begin to see the process from different perspectives: what the process was designed to accomplish, what the data shows is happening over time, and how the people interacting with it actually experience it. Together, those perspectives help us identify where the process should evolve and give us a more informed basis for deciding what to improve next.
This is where the influence of Baldrige becomes clearest for me. I do not see the Framework as a description of where my program is today. I use it as a way of thinking about where the program needs to go.
Is the process systematic? Is it repeatable? How widely and consistently is it being used? What result is it intended to produce? Can we measure that result? What do the trends tell us? What are our stakeholders experiencing? What have we learned? How does that learning make its way back into the process? Each question leads naturally to the next, and the connections among them are where I begin to see what organizational excellence looks like. A process becomes clearer and more systematic. Its operation becomes less dependent on individual knowledge. Its results become visible over time. The experience of stakeholders gives those results context. What we learn from both gives us a basis for improving the process again.
For me, that is the practical value of the Baldrige Excellence Framework. It gives me a way to look beyond the problem immediately in front of me and ask what within the system allowed that problem to emerge in the first place. Instead of moving from one emergency to the next, I can begin to recognize patterns, understand what is producing them, and make changes to the processes that shape those results.
Over time, that changes the nature of management itself. The goal becomes more than solving today’s problem. I am trying to build a system in which processes are understood and consistently applied, decisions are grounded in established requirements, results can be observed over time, and the experience of stakeholders continually informs what we improve next.
Eventually, the program should carry more of this responsibility within itself. Its processes should preserve how the work is done. Its data should preserve the history of how the program is evolving. Its feedback mechanisms should help it continue to learn. The program becomes increasingly capable of sustaining and improving its work regardless of the preferences, memory, relationships, or individual way of working of the person who happens to be managing it.
And if I have done that work well, the answer to the question I started with—Would this program continue to function effectively without me?—should increasingly be yes.
Mayda Colon
SPQA Board Member