Operation Improvement Inc.

The attempt to dissect responsibilities into “strategizing”, “improving” and “doing” is an unworkable over-simplification.

The broadest distinction is created by acknowledging the limitations imposed by “available means”.  For decades we have been calling this limited authority: “Tactical”.  Tactical responsibilities are those that we expect to accomplish with available means. In the case of process work, it means the available facilities, machinery, tools, automobiles, funded staff positions, computers and so on. “Tactical” means the monthly, quarterly, and annual P&L budget.

There are a lot of ways that these finite resources can be assembled and deployed. For example, in the context of process work, a budgeted line item for process improvement gives managers and front-line workers the leeway to try, evaluate and migrate to better workflows, work setup methods, etc.

In the context of project work, an IT project manager may spend budgeted funds on cloud resources or on enhancements to on-premises equipment. We call these discretionary decisions lower case “s” strategy, since a project manager, for example, may decide to proceed with either iterative or waterfall development. Nevertheless, the project management duties of organizing tasks, resource and time to meet an objective are still tactical. Projects are constrained by a budget of resources and time.

Program Management is different. A Program Director or executive is not constrained by available means. A Program Manager may have a portfolio of projects and multiple objectives that are weighted by value and risk, and then resources are allocated accordingly. The authority for providing resources to tactical teams is what we call “Strategic” responsibility.

Strategic decision makers provision available means while weighing value and risk. These decision makers have “Balance Sheet” authority. Not limited by “available means, the strategist can decide when and where to borrow or pay off loans, increase or decrease office and manufacturing floor space, upgrade equipment and technology, change the staffing plan

At the highest (“Policy”) level, Strategic decision makers are the final arbiter of “who is our customer”; to whom and how will the company seek provide products and services. (Government, Wholesale, Retail, Market Segment, Geography, Low Cost, Premium, Luxury)  

“Quality begins with the intent, which is fixed by the management.” – Deming

In summary, we say that tactical managers and front-line workers are responsible for correct and consistent execution of work – given the available means. Strategic decision makers (Directors, Executives) are responsible for providing facilities that are capable of meeting and exceeding the customer’s expectations. Together, Strategic and Tactical need each other to produce a quality product or service.

At all levels of responsibility, there should be “doing” even though the difference in degree of responsibility results in a difference in the kind of doing.

As a placeholder for an additional article: let me mention the “red zone”, the bridge between the strategic and tactical. This role is often a gap in an organization’s resources as it requires both subject matter expertise and the ability to think about the business from both the strategic and tactical perspective.

IT work can be generally organized as:

1) Process (Things we know how to do),
2) Development (We need to learn, research, experiment, try) and
3) Project work (We assemble #1 and #2 into something new.)

The management of these three requires different tools.

1) Tier I support should be organized as a process. Think and manage and staff using concepts of demand, capability and capacity. Integrate staff into the process with a “career path” approach that allows them to become productive quickly and then handle more complex support requests as they learn. Implement sustainment training. Well managed ticketing systems are the proper tool here.

2) Development work should be organized around small teams of 2-6 completely responsible for an objective or sub-objective. Use iterative project management (now called “agile” by many) – the simplest being a task board approach: A) TBD, B) Planned for this iteration, C) Done. Every big problem can be broken down into smaller ones.

(If you have never done this: each iteration is a relatively short and fixed block of calendar time. It is similar to the classic time management approach and the prioritized daily actions list, but the time window of each can be a day, a week, or more depending on the nature of the work. )

Choosing an appropriate interval to pause, assess, and plan the next iteration is probably the single most important skill in managing this type of work, keeping focus and making progress without falling into the “micromanaging” trap.

Avoid the illusion of control offered by “buzz word” and overly complex management tools. Keep review and tracking simple. Developers justifiably hate when the work management system is too bureaucratic. Don’t over-complicate this! Just judiciously use the best knowledge-base, version control, sharing and team building tools you have available today.

3) Major project work usually calls for Gantt Chart/Critical path resource assignment, baseline tracking, leveling, materials cost, Earned Value calculations, etc. Network, Infrastructure, facilities build-out, etc. are all examples of projects typically require waterfall project management.

You need a software tool that handles all these and advanced scheduling methods (ASAP, ALAP, Start and Finish dependencies Leads, Lags, etc.) Look at Project Plan 365 or Microsoft Project. Other popular “big name” tools are missing some of these features. Everyone needs to see the big picture. Not everyone needs to see every detail.

Let’s start with the really big picture – think about improvement over decades and longer. What has changed since the eighteen hundreds, the sixteen hundreds, or even longer spans of time?

Here is a hint to the first driver: “The wood and stone age. Tin. Copper. Iron. Steel. Aluminum. Plastics. Semiconductors.” New Materials!

Formal scientific method is relatively new, but inquiring minds have been exploring the field of materials science for millennia. Advances and discoveries of new materials have defined and delimited what was possible in human history. Today, these advances in materials come every couple of decades.

Every new advance (graphene, perovskites, nanomaterials, metamaterials, etc.) opens new possibilities for the second driver: invention, engineering, and automation.

While some products, for good reasons, are still made in the tested and traditional manner; new technologies periodically replace the old. We have a saying in our approach to quality and improvement. “Management provides the facility and is ultimately responsible for process capability, IF Operations runs the facility correctly and consistently.”

If both parties of this division of labor work together, processes can produce excellent products – and each can contribute to the goal of producing more with less in the future.

Management can commission engineering to rebuild processes with the latest inventions, materials, and technology. Operations can continue to expand their knowledge beyond the “user manual” – and fully master these new tools. This brings us to the third driver of continuous improvement: operations excellence and operations sustainment training.

An important component of operations management is continually training, reviewing methods, correct use of tools and technology, safety protocols, and so on. Professional athletes, performers and musicians never stop practicing and rehearsing.

Improvement only happens by accident, or when we learn something. The reverse is also true. Process performance worsens sometimes by accident or when we forget. Accidental improvements are temporary. Retained and applied knowledge is the key.

(Definition: Tactical management is management of -available- means to an objective.)

The “micromanaging” topic always begs the question, “how often should tactical managers check in on the progress of a project or task set?” Any intervention by a manager (whatever the form) generally amounts to: Communicate, Coordinate and Re-deploy resources as necessary. You change assignments and reallocate available resources.

To find a balance between time used for talking about work and time actually working, I generally follow the following guideline:

I ask, how many opportunities for action should I budget in order to make project adjustments? Of course, you want to place as much trust in the team as possible, and not frustrate them by signaling a too frequent change of priority and direction.

So, ask yourself, what is the “pace” of the project? If an objective is 16 weeks in the future, can I adapt to any issues and unforeseen surprises if I review monthly? That gives me only three opportunities to act. Given what I know about my team and our objective does that seem enough? Can you count on your teams to “send up a flare” if they encounter un-foreseen issues?

What about management in a crisis, where we are trying to contain a serious problem in hours, and not days? How often is too often to check status?

Let’s explore the example of the 16-week project. After 4 weeks and 1 review, one fourth of the budgeted resources have been spent and there are only two remaining reviews before deliverables.

With only three fourths of the time and money left, are the remaining resources (if judiciously redeployed) going to be sufficient to bring things back on track? In most scenarios, this seems a little tight. 6-12 checkpoints seem like a better minimum for most projects, depending on the team of course.

Of course, tactical management of -processes- is a different topic, and totally different approaches are needed. Many technology project managers use an iterative development process and a pace established by weekly or bi-weekly “sprints”.

Guided by a rendering, or “wireframe”, each iteration is intended to produce an incremental deliverable which will either converge on a finished product or continually improve an existing one. A week or two is typically long enough to add and test a couple of features, and short enough to keep the scope of very abstract work conceptually manageable.