Automation Technology & Business Operations

September 14, 2023 Comments off

Process automation can and does mean anything from data collection, repetitive manufacturing or maintenance task execution, service organization reporting, software testing and deployment and more.

For operations monitoring in particular, and for automation in general, there are three principles that should be followed as a guide to success.

  1. To successfully automate a task, you must understand in principle how to perform the work manually. With data collection, you need to have a clear picture of the thing or activity, its attribute, the type and units of measure, and the measurement method. Automation is a tool that allows one to perform the work of many.
  2. You must keep the focus on the ‘why’ of automating a manual process. In the case of data collection, does automation produce information that is more timely, more accurate and less expensive than other means?
  3. You must periodically audit the automated process from the ground up. With data collection, you need to audit the flow of data from the point measurement takes place, up through any rollups, summary statistics and reporting. (See #1)

Finally, with operations monitoring automation, remember that the goal is conceptual understanding and ideas that are useful/actionable. Don’t ‘bury the lead’ in pages and pages of unnecessary reporting, data analysis and out-of-context graphics.

Check out the case studies library for more on Automation Tech:

Software Project Management Callback

August 31, 2023 Comments off


“Waterfall” project management is a style of management best suited to the assembly and integration of proven processes and skills. In residential contracting, we work from plans, measure twice and cut once. The materials, techniques and skills required are known quantities. The quantities of steel, concrete, wiring, plumbing and fixtures can be estimated from the plans and established labor ratios can be applied to quantify the human component.

                The challenge in these kinds of projects is wise management of critical path, and the ability to adapt to early and late delivery, price surprises, material defects, resource scheduling conflicts, human error and project changes. In “waterfall”, the project manager is given an objective expressed as performance, time and cost and must optimize these three variables while considering project risk.

                As a tactical manager, the “go-to” skill in the face of challenges is the ability to re-deploy the available resources when and where they are needed! The hardest lesson for some is that attempting to schedule every task ASAP can make a project take longer!

                Software project management is different. By software development, I am not referring to the low-code/no-code projects where workflows are tweaked, data is recoded, and BI engine reports are created.  The alternative to waterfall is certainly an option for these kinds of assignments, particularly the first time they are attempted. Software Development at a means code and database creation and integration with other pieces of software.


                The conceptual alternative to “waterfall” can generically be termed “iterative development” and it is an approach that is decades old. It predates computer technology and code creation, and has many applications outside of IT.

                Fredrick Brooks, the well known UNC computer scientist and thought leader had some success with waterfall techniques when he redesigned the roles of a lean programming team. His original book, The Mythical Man-Month is a classic of software development, and gave us this guiding principle: (among others) “Adding programmers to a late project will make it later.”

                In subsequent editions of this book 20 years later, he explored the concept of iterative development. In simplest terms it builds on the lean programming team model and add iterative development constraints. A development cycle is a short, relative fixed time period where an application is constructed with only the functionality that the time budget allows. He calls this “growing a program”. This approach turns learning, discovery and invention into a manageable process.

                At each stage of development, the result is both a working product, and a prototype for the next iteration. With this approach, nuances of a new language or strengths/limitations of a chosen framework of building block functions can be explored and adjustments can be made as necessary.

                Project planning is developmental. Much like a curriculum development for first, fifth and 12 grade education, project planning has a vision, or outline, for what the product could look like at different stages of development.  You can see that this lean style of iterative project management is “baked into” the DevOp and CI/CD methods and tools offered by AWS cloud services.

                With either “waterfall” or “iterative” management one wants control and desires to avoid the pitfall of the illusion of control. Project management skeptics who are aware of such illusions sometimes ask why plan at all?

                I ask them to imagine productivity if we planned 100% of the time, (The answer is none.) and then I make the case that activity without performance-time-cost objectives will not deliver value. What is the value of the perfect wedding cake delivered a week after the wedding? What if the cake is cheap and on-time but looks and tastes awful?

                Without a sense of where we are going, where we are and an idea of how to get from here to there – the risk of failure is almost certain. A sweet spot of planning and control is somewhere in between no plan and an obsessive attempt of over-control. However, when we encounter those things we cannot control, we realize that plans must change; and that is ok.

                An interesting Twitter (“X”) post had detailed criticisms of SCRUM and other recent attempts to build management layers on the thirty-year old lean development framework of Dr. Brooks. The Twitter writer did not reference Mythical Man-Month, but the book certainly came to my mind when I read the on-line comments and replies.

                On reflection, it also made me remember the advice, “…things I can control, the things I can’t. The wisdom to know the difference.”

A Picture…One Thousand Words: Process

August 28, 2023 Comments off

How do you identify the most important business processes?

August 23, 2023 Comments off

At the highest level, a business is defined by its goals and strategies. (Ends and Means) Within that context, a process is a plan for creating a capability, a potential to produce. When executed, a good process plan delivers the correct product, consistently with measurable results.

The product could be that “widget” every book mentions – “we can produce 1000 widgets an hour from iron castings”. Product could even be an intangible like electric power or bandwidth – “we can provide energy for a 100 Kilowatt demand for up to 8 hours out of 24 from sunlight”.

Note the words “can” and “from”. Process improvement simply means improving our ability to make more with less. The “less” could mean less raw material, less expensive equipment, less time, less risk or less waste. (Every process has a product and a by-product.) 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. Knowledge is the key.

So, the question of most important process takes us in three directions.

First: It is good advice to “play to one’s strengths.” What are our strengths? What are the core competencies that we can develop and improve? What are those processes that should never be outsourced? Those are most certainly highest in importance.

Second: The Sustainment process. 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.

Third: The Learning process. Since accidents do happen, an incident should trigger a learning process. Was the consequence of the accident a good thing or a bad thing? Why did the accident happen? I like a simple classic approach to causal analysis.

A. Identify the immediate cause. – (The roadway nail that caused a flat tire.)

B. Look for a causal chain of events. – (The carpentry truck ahead with the open toolbox. The speed bump. The speed at which the carpenter drives.)

C. Examine human action. What choices and decisions could have been, and will be different? – (Lock the toolbox. Slow down for speed bumps.)

Finally, don’t wait for accidents to happen. A fire drill is sustainment. An experiment-day is a controlled and managed “accident”, a way for us to learn what makes a process better or worse.

A Few Thoughts about “Problem Solving”

August 10, 2023 Comments off

Among other techniques, I have encouraged teams to begin an analysis with the immediate cause of a problem, and work backwards along a causal chain. This form of analysis documents two components of causality: 1) causes (things) acting inevitably in accordance with their nature. and 2) decisions and choices (root causes) made that could have been different.

If I imagine dealing with a mechanical product failure, one could learn about (1) the strength, durability, duty cycle, etc of a particular material or component; or (2) the many alternatives, including different materials, that could have been chosen in the product design.

However, a thorough understanding of a problem should begin with a clear understanding of the purpose that cannot be achieved due to an obstacle. Sometimes we can become so fixated on the next immediate objective that we forget about the ultimate goal. Can we go “over, under, around” or must be work through the problem in order to succeed?

Years ago, someone asked me for help with a spreadsheet issue. Their computer was complaining about running out of space and they wanted to know how their computer could expand. I asked them how many of these huge spreadsheets they had, and the answer was one! They only had -one- spreadsheet!

The rest of the story…
When the computer was new, they started their first calculation in row 1, column 1 – and kept going. It never occurred to them to open a second or third file for subsequent projects! When we talked about how multiple projects can be organized into multiple spreadsheet files, they immediately realized their “problem” was not the size of their computer – but their inexperience with the new software.

If you are experienced with office software suites and had a little laugh over this story – don’t forget that sometimes we all have these moments where enlightenment from a “Brilliant Flash of the Obvious” (a BFO) makes an apparent problem vanish and we get a clearer picture of how to proceed.

Check your assumptions!

AWS Lessons Learned

June 12, 2023 Comments off

In every field of endeavor today, the need for continuous learning and self-improvement never ends.

“Hybrid” skills – knowledge that spans traditional HR silos and categories have always created opportunities for me. So, I always take the opportunity to expand in new directions.

After my own business requirements led to dabbling in Amazon Web Services for email delivery, cloud desktop services and small cloud web servers, I decided to try the AWS certification tests, starting with what they call the “Cloud Practitioner”.

The certification programs also most certainly bring Amazon more business. For example, I quickly learned that the domain registration and name server services at Amazon were quite superior to the service I had used for years – and I have already begun the migration of the first four of many domain names to Amazon’s Route 53 service.

Next up for me is the Amazon Architect program. Fortunately, there are many hours of free preparation materials available at the Amazon web site. There is also much that can be learned from sample tests that are offered by third party training organizations. These free tests are an enticement to sample their website and consider their fee for training programs.

Here are some tips for others who may want to explore Amazon AWS services and certifications.

  • Think big. Really REALLY big!

On the one hand, AWS has services for small organizations and their “only pay for what you use” pricing lets almost anyone experiment with web servers, cloud telephony, email, cloud data storage and more for tens of dollars per month and not thousands.

On the other hand, consider what would be involved in configuring and launching thousands of servers in dozens of data centers – while sharing and securing data between these centers and millions of end users. No “on premises” data center experience prepares you for the scale, the “wholesale” mindset you must develop to effectively use AWS for substantial workloads.

  • Don’t Panic!

AWS services are modular and are intended to be loosely connected to produce a resilient and highly available result that can be evolved in small iterations to continuously improve. However, you must first break the “code” of AWS naming conventions.

If you have programmed, you may be familiar with concepts such as “objects”, “structured code”, “event driven routines” and more. When you pick up a new programming language these elements and common built-in functions are typically available if you can “google” the new language terminology for the familiar code building blocks. (Do arrays start at zero or one? Does this language use Braces or brackets? Indented structure blocks of reserved words. Etc.)

AWS often makes creative names for functions and services that you must work to match up conceptually with functions you may have encountered before. On top of this new nomenclature, AWS condenses these names to acronyms, and one must remember and retain the difference between SES, SNS, SQS or ELB, ALB, NLB – and so on.  When you expand the acronym and “translate” the service name you often find something familiar.

Of course, there is much you will find that is new and much that is arcane. Overall, you will find the AWS view of “good architecture” is logical, secure, and labor and time saving if used properly. Ask yourself, “if I were designing AWS itself – how would I do it?”

  • AWS is always changing.

The “free” sample tests and training videos on the web are not 100% accurate in their scoring. One test heavily emphasized the “access control list” for security, while AWS now prefers resource policies unless ACLs are the only option. Another list marked an answer wrong claiming AWS did not support a particular option or feature – but that was “old news”. New features often change the way cloud applications are designed and deployed.

Training and improvement Tools

April 28, 2023 Comments off

Learn, Share, Teach, Improve

March 13, 2023 Comments off

Some years ago, I saw a clever poster that diagrammed systems of the human body. It was the most complex flow diagram with dozens of boxes and lines representing the interaction of electrical and chemical activity and their effects on the whole.

This diagram was presented as a “wholistic systems” view of human anatomy, but it was mind-stopping in its complexity. Such an analysis might be appropriate as input for a computer simulation, but it did not conceptualize anatomy and biological process in a form that was suitable to learn, teach and share knowledge.

I have seen this same kind of complexity in business. I have seen telephone routing protocols that make it impossible for a human being to predict where calls will be delivered, who will be overloaded and who will be left idle.  I have seen workflows in service and manufacturing operations with a multitude of steps, loops and IF-THEN-ELSE forks in the road that would leave workers uncertain how to proceed.

From cross-discipline experience in many different work environments we derived a different method of describing work that is suited to learn, share, teach and improve business processes.

You know that humans need conceptual structure. Sentences can’t run too long. Articles benefit from paragraphs. Social Security numbers and phone numbers are hyphenated so that they can be remembered as three things instead of 10.

For example, we think of the first three digits of a phone number as an area code. Applying a conceptual structure, grouping, and naming things of like kind is what empowers human thought and decision-making.

Did you ever try to assemble a jigsaw puzzle as a child? The first step was always to group. Pieces of a certain color were pulled aside and in our mind we said “sky”, or “grass”, “people”. Our process dependency diagrams are approached the same way.

At a high level, we group the inputs, outcomes (nouns) and process steps (verbs) into a mentally manageable number that can be presented on a single page. This “umbrella” process diagram shows the overall dependencies for a successful outcome. Each earlier process step is usually earlier in time, but it is definitely a prerequisite for success.

Each process step is broken down onto a detail sheet and more details about the inputs and outputs emerge as well. A process guidebook organized in this way makes it easy to access the level of detail that the user needs for their level of experience.

Decisions are handled by referencing what we call factor tables. We either know in advance the decisions that will be made in a process or not. If not, the work is “out of process” and needs to be reviewed at a higher level; a supervisor, manager, or engineer – depending on the operation. This feedback is a crucial part of the improvement process.

The result: ideas about work and results are presented in a linear, easy to understand format without loops and branches. We describe work conceptually, and not in the fashion a computer requires.

Reports Are Not The Same As Data!

June 24, 2020 Comments off

At the start of a new operations process development or improvement effort, I typically want to see two things firsthand.

It is important to have a personal view of the work presently being done, as well as the methods and the tools or resources available at the place of effort. It is also vital to get an early look at the process metrics and performance outcome data that the workers and their management think is actionable. These first steps allow us to start with a clearer picture of the objective (the deliverable) and begin to develop a vision and implementation plan for a better way.

What I frequently get in response to my requests is one or more reports instead of data. Where once there might have been actual data, its source and method of capture is undefined and cannot be audited. What began as  observations systematically compared to a standard has been digested into predetermined narratives with implicit and often wrong conclusions.

Data means measurements, with the method of measurement totally transparent and always open to constructive critique, caveat and refinement.

As an example, telephony systems have not always left audit trials for call center operations.(And many today do not meet the standard of measurement above.) In the systems that do have call detail databases, much time and effort is spent trying and failing to reconstruct the “state of the business” at some past date and time.

I approached this problem on an older system by taking and saving periodic real time snapshots of the PBX system state. (Calls in queues,  current wait times, etc.) These frequent “state of the business” measurements gave us actionable data and  helped us to monitor performance as we made changes and introduced new methods and tools to call center agents.

The entire chain of logic (observation, data grouping, statistical summation) and graphical reporting was presented in a form that not only provided actionable information, but also communicated the answer to this most important question, “How Do We Know?”

Of course, measurement in the service sector has the same issues of measurement variability as precision measurement in manufacturing. The solutions to this challenge are similar, but that is another topic.

“If we don’t have a clear picture, then we don’t act!” ** – Organizing Product and Process Knowledge

May 22, 2020 Comments off

For centuries, people took for granted that the sun and heavens moved around the earth. Against that night sky was the surprising, independent and often retrograde movements of the planets. How does one make sense of that? How does one grasp, in principle, that contrary movement?

Of course you know the answer, as does every child who grew up with a ceiling-mounted mobile of our solar system. We now think of the (1) sun as stationary. We (2) imagine circular motion around the sun, and then refine that new conceptual model by adding more knowledge. We learn that those planetary orbits are (3) elliptical. Then, we discover that (4) not all planets orbit in the same horizontal plane. (Mercury and “sometimes-a-planet” Pluto are tipped a bit.)

As we learn more,  the mental picture does indeed become clearer. If our job is to launch a spacecraft to another planet, this clear picture is vital. We need as complete an inventory as possible of what is known about the solar system and its moving parts. We don’t stop at four metrics. Organized Knowledge is power.

Businesses can often make quantum leaps in their ability to deliver value, if someone takes an independent and  objective look at how workers and managers think about their jobs. If product and process learning has slowed or stopped, you may need a fresh approach that “puts the sun at the center” of your thinking.

Take a look at the difference a clear picture makes:

  • A tech support team dreaded every phone call. A fresh look at their processes led to change, and they were confident in their job after a week!
  • A metal machining operator reduced job setup time from four hours to 15 minutes when a fresh look at the process reduced the setup of hundreds of parts to just a dozen or so basic configurations.
  • The wrong mental picture caused a service desk to deliver worse performance while their metrics showed improvement! A fresh look at their metrics turned this around immediately.

It is hard to make things easy.

Your high school English teacher probably warned you about too long sentences. Many people will not get a clear picture unless you break ideas down into manageable sentences with nouns and verbs. Product and process knowledge should be organized in absorb-able chunks for similar reasons.

We often say that properly organized process and product knowledge is a mechanism to learn, share, teach and improve. It documents dependencies between ends and means – what are the prerequisites for successful results.

We call this approach to improvement: factoring. We have been coaching, teaching classes, writing books and running on-site improvement projects based on these methods for over two decades. If you see opportunities to apply this in your operation, we are here to help.


** “If we don’t have a clear mental picture, then we don’t act!” This is one of the most memorable gems from Dr Charles R. Hobbs, but there is more to unpack than the surface meaning.