Taking a Step Back

Normally in business when we mention the phrase “taking a step back” people immediately think of accepting a position or assignment with a perceived lower title or lower set of responsibilities. That may well be the case, but that is not the step back that I want to discuss here.

In business we all have our areas of responsibility. These normally come in the form of job descriptions and objectives. Simply put these are the things we do and the targets we are supposed to achieve. We are provided directives and incentives associated with them. We are incited to focus only on our specific pieces and parts of the business. With all that focus it is very easy to become somewhat myopic with respect to the overall business or organizational picture.

Sometimes all of us need to take time out of our ever more hectic days, take a step back and look at the overall business picture and what our specific part or role in it is, to see if what we are doing or have done is still fully aligned with the greater good.

As an ever more refined and specific business process is viewed as the clear path to greater efficiency and more profits, the incentive for each participant in that process is the ever refine and narrow their focus to their specific role in that process. As this structure evolves, organizations end up trying to create integrated end to end customer solutions out of ever more discrete and individualized work components. As the number of hand-offs in the process increases, the disconnection between the solution components increases as well.

In the extreme you can end up with a number of disconnected groups performing discrete unrelated activities (all while following a “process”) that results in a final work product that may not meet any of the requirements that were initially assigned to it. Everyone may have done everything that they were responsible for doing, but the final result doesn’t meet the need.

I think that much of today’s process orientation has originated in the Project Management discipline. (I have gone through the Project Management Institute PMP (Project Management Professional) training and certification process and do have a PMP accreditation.)

Part of the process of managing a project is to create what is called a Work Breakdown Structure (WBS). Creating a WBS is the process of subdividing project deliverables and project work into smaller, more manageable components (A Guide to the Project Management Body of Knowledge (PMBOK Guide) 4th Ed., pg. 103). It is described as the decomposition of the work to be executed by the project team to accomplish the project objectives.

But isn’t that essentially what every process is? Isn’t every process a series of work components that at the end of the process are supposed to deliver a finished work product or solution?

So enough of the esoteric discussion of the similarities of projects and processes. Where does this all get us and what does it have to do with the position I have put forth about taking a step back?

In a project there is a project manager. That person is vested with the responsibility of managing that project from end to end. As Harry Truman would say: “The buck stops there”. It is the project manager’s responsibility to make sure that all work components are aligned and additive in the direction required to complete the project.

In today’s organizations where parts are globalized, parts are regionalized and other parts are verticalized, all in the name of greater efficiency, it is almost impossible for someone to call themselves the “owner” of a process that spans multiple organizational structures. Organizations and people within those organizations may own pieces of the process, but there are precious few with the purview of a project manager who can review the process from end to end.

Once the process has been decomposed into its smaller work components, and those components are distributed to different organizations and groups, it seems the overall end to end view of things gets lost. Responsible parties seem to focus only on their specific work component. They perform their task and pass it along to the next responsible group.

It has been shown that when dealing with a uniform process all tolerances or margins for error are more or less normalized out. What that means is that in a uniform environment there will normally be additive and subtractive variances. Estimates will normally be either a little high or a little low, but on the average they will cancel each other out. This is the model that is used when the process is created.

When the process is decomposed into its component functions and then distributed into different and somewhat unrelated organizations, it can no longer be looked upon as a uniform process. It is probably more accurately defined as a “Random Variable” process. This is a process that is not uniform and where the variation in one group performing a work component has no effect on the performance of another group performing a different work component.

Okay, so what does this mean?

What is means is that when a process is no longer uniform the variances associated with the various work components no longer have the tendency to cancel each other out. They have a tendency to add together to create ever larger variances.

The net result is the creation of a process that by its very nature will not deliver a desired solution. Each group that is responsible for a work component can and will provide an acceptable output, but the sum of these outputs will invariably not be an acceptable solution.

A good example of this phenomenon can be seen in the creation of cost structures. In a project that is controlled by a single project manager, some costs will be estimated high, and some will be estimated low, but on the whole the costs will balance out. In a cost process where there is no single owner and multiple groups and disciplines involved, all costs will be estimated high (in an effort to make sure that all individual contingencies are covered) with the final cost estimate being unacceptable to the customer.

As I noted, in a project environment the project manager has oversight and control of the costs and processes associated with the project. Costs and activities must all fit within the overall envelop associated with the project and the project’s profitability. Variances within any specific group are then viewed from the point of the overall project. This ownership and oversight does not usually exist within the decomposed process. It is due to this comparative lack of oversight that a uniform process can devolve into a random variable process over time.

It is due to this sort of inertial force associated with process decomposition that we all need to periodically (read “frequently”) take a step back and review our roles and deliverables. In a greater scheme of things all that we do can be viewed as part of the ongoing business process. There are pieces that we can control and pieces that we must rely on others for. We need to make sure that we are in fact maintaining our alignment with the overall organizational goals and not just maximizing our specific work products.

It may sound a little counter intuitive. The idea should be that if we all maximize our work products, then the final deliverable should be maximized. In theory it should work. However when the goal is to minimize, or reduce or drive greater efficiency, sometimes maximizing does not work as well or drive the desired solution.

Take a step back and think about it.