From Process to Discipline

by Geof Lory

In my previous article (Measure What Matters) I spoke about the concept of interacting based on relationships versus transactions. I believe teams and families function more effectively (optimizing performance and personal satisfaction) when relationships are the foundation of our interactions. When these relationships stem from an underlying base of trust (Vulnerability-Based Trust) the stage is set for a more dynamic level of communication.

The primary purpose of any team is to get work done in the most effective manner and achieve outcomes that add value. Ultimately, the result of the work is the value proposition and the interaction is just the means. But, so much of project management is about how the work gets done within the constraints of the project, not which work has been selected for the project. That is why there is so much focus on process—the flow of work and information within the project. There is a belief that if we improve the process, better work will get done faster and use less resources, which is the Holy Grail of Project Management.

Unfortunately, with this belief in process comes an attempt to apply a single, though arguably flexible, process—a customizable, one-size-fits-all approach. I find this to be somewhat of an oxymoron to project work, which is by definition "a temporary endeavor undertaken to create a unique product, service, or result." It seems only logical that the more unique the effort is, the more the processes would have to be different.

So, what makes a project unique? First of all it is the level of uncertainty of the outcome; meaning how clearly the final results are defined. Do we know exactly what the outcome should be (as might be the case in repetitive installations of a product into a known environment)? Or, are we discovering the intended outcome within a set of cost and time boundaries as the project unfolds? Secondly, how often will the project or applied process be repeated? What is the frequency or reusability of the process?

Taking these two dimensions—and admittedly ignoring for the moment the other dimensions of time and money—I created a graph of possible project scenarios under which differing levels of process would apply. Since there is an inherent trade-off between the two dimensions, the process curve might look something like this. The appropriate amount of process (value added for process applied) for each unique project would be at some point along this curve.

I have used this graph many times to help clients and project teams understand that the level of process applied to a project is as important as the type of process. Applying process when it's unnecessary incurs wasteful overhead costs. Not applying process when it's appropriate again wastes precious resources, risking inefficiencies and compromises quality. If the goal of project management is to maximize the productivity of the team to produce the greatest value, choosing the right amount of process is absolutely critical.

In the graph above, Project A produces a well-defined product or result and the plan could be used many times to consistently produce the same or similar outcome with each project. The processes to produce these outcomes are reusable and applicable with a high degree of frequency. Operational projects or assemblies of known parts are prime candidates for a process centric approach. Most System Development Life Cycles with templated project plans and sign-off approval stagegates operate under this framework. Here, the goal is to reduce rework by and improve quality by continually removing any inefficiencies or latency in the processes. However, the farther down the process curve, the greater the investment in process. The cost of process has to be justified by the need for consistency or the savings from repeating the process. Installing a phone system in multiple locations where each location is considered a project is an example of where a high degree of process would provide savings and improve quality.

On the other hand, Project B is in a state of discovery, and the team is defining the outcome as the project progresses. This project is not without its processes, however they are lighter and more flexible (sound like the definition of agile?) and are subject to continual ad hoc revision as the situation demands. Here a process may be situational or feel more like a recommendation or best practices.

At the extremes of this curve, absurdity or delusion reigns. That is the nature of extremes. Beyond Project A lies wasteful bureaucracy and process gridlock. Beyond Project B is rogue chaos. But, somewhere along that curve, for every project, lies the point where process enables productivity. That's the sweet spot a project manager needs to find and apply. When trying to find the best place along this curve to operate there are many things to consider, but of particular interest to me is the degree to which the team or organization can operate transactionally or relationally.

When planning projects, thinking of work as a series of transactions is simpler. Transactions appear to work better than relationships because the commitment level is clearer and more defined. Transactions operate within an input-processing-output (IPO) or transformational model. It is the same model used for engineering or a production line. Feed something in one end, process it, and you get an expected output. If your project is looking for repeatable processes that produce the same outcome every time, thinking within this paradigm may be fine.

On the other hand, relationships are muddy and difficult to clarify, at least when compared to the transformational or mechanistic model above. But too often, we approach relationships as transactions because the uncertainty of relationships disturbs our sense of control. This results in the players trying to reduce their activities down to further elaborated transactional agreements before they attempt to get something done. These agreements create at best a faux-relationship that will forever require greater and greater levels of reduction to be effective. Each level of reduction further erodes the efficiency of the work and challenges the underpinnings of the relationship, not to mention how it creates the misperception of control and predeterminism. This is evidenced in a detailed work breakdown structure (WBS) approach to planning-using detailed work efforts for each task in an attempt to replace the need for a relationship as work is transactionally handed off.

I work with a lot of customers who used to ask for process; they felt they needed to move down the process curve toward methodologies or models like CMMI, SPICE, or Six Sigma. But they struggled with the implementation because too many of their projects were more like Project B. So these clients have decided to "go agile" because they believe agile doesn't require so much process. Usually what they get is chaos. They removed the rigid process, but failed to implement the high degree of personal and team discipline needed to successfully execute without it. This is when I change the label on the curve and call it the "discipline curve" instead, to emphasize the need to build disciplines not just throw out process. It's not that process doesn't require discipline, it's just a different way of looking at discipline.

A traditional definition of discipline is to correct to a set of rules or norms. This applies a thermostatic control model where the expected outcome is clear and static and all actions are "disciplined" to correct the variance and return to the desired state. This may work for machines, or even for people when applying static legal or social norms, but it doesn't work well when the outcome is uncertain or in a state of flux or discovery. This approach sounds similar to how transactions operate; there is an expected adherence to a set of external rules and external governance is applied to control the variances.

I prefer to use a different definition of discipline when working in relationships: doing what you know needs to be done to keep a commitment even when it is inconvenient or uncomfortable. Under this definition, the commitment replaces the rules, and it is not static but rather a fluid and negotiated outcome between both parties. The governance is internal instead of external, and the discipline includes the desire by both parties to continually seek the fulfillment of the commitment. Here, the commitment is part of the relationship and they enable each other.

On my teams and in our family, I like to think that discipline reigns—well, most of the time. I love being a dad and a project manager. I'm not so fond of being the household or team policeman. Sometimes parenting requires a little of both, but given a choice, I prefer to be Dad. I think my daughters and my co-workers appreciate it too. Well, most of the time.

Making and keeping commitments is a required discipline if you are going to try to operate further up the discipline curve. It is an essential element of high performing teams and a staple of my approach to parenting. Building a culture or relationships based on a discipline of commitment is not easy and requires its own level of internal and personal governance. In the next article, I'll explore ways to develop a Discipline of Commitment on project teams.

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy