Operation Improvement Inc.

Early in my consulting work, we were doing a series of Quality training classes at a plant in Tennessee. My associate, James, asked the class about “scrap”. The class said we don’t have a scrap problem, and James held up a little tip of rubber – a trimming from a finished product that amounted to a significant quantity every month.

Every process has a product and a by-product. The “product” of an operation is often subjected to inspections, reporting and analysis that we call “burnt biscuit reports.”. Even if a facility is fortunate and has no “burnt biscuits”, there are still opportunities to learn and improve by, for example, examining the by-products of production.

Of course, Statistical Process Control looks at the processes that -make- the biscuits. It moves the focus from biscuits to baking. When we are “baking”, “mixing”, “pouring”, “cooling”; we want metrics that we can quantify critical aspects of those actions in addition to those of the product.

Finally, the input of every process is the output of a predecessor. A “Walkabout” style visualization pulls together the important relationships between incoming product, process, outgoing product metrics, and by-product!. We describe it as a way to “learn, share, teach and improve”.

Some call this style of documentation, a “functional block diagram”. It is really just our early development of what is today called “value stream”. Our use of the technique began by understanding its traditional use for “divide and conquer” signal tracing in the electronics industry. We then adapted it to latex form and mold manufacturing, hydraulic valve machining and assembly, chemical baths and plating, IT support processes, call center/telephony processes, and more.

If you find this approach helpful, check out these books: The Abbott Walkabout Series & Thirtysevenideas.com

What is It? Where is It? What Does It Do?

How Does It Work?

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 Keyence.com case studies library for more on Automation Tech: https://www.keyence.com/solutions/case-studies/

WATERFALL PROJECT MANAGEMENT

“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.

ITERATIVE DEVELOPMENT

                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.”