Operation Improvement Inc.

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.