Process Improvement (CMMI, Six Sigma, SPICE, etc.)

Informed business analysts know that one of the secrets to producing a high-quality process model is to establish a clear mission for each model. To be successful, you should mindfully establish the mission of your next process model within the business process management, information technology, or regulatory compliance project that the model will serve.  You will then tailor your elicitations of the model’s content and configuration to meet project needs. Part of your process model mission-setting elicitation agenda will include asking and answering this important question: What is this model’s required degree of abstraction?

Taking a product from an abstract idea to an item that’s widely available in the marketplace demands a hands-on approach to prevent things from falling through the cracks. A technique that goes back nearly a century, product lifecycle management (PLM) has for decades been used to improve the efficiency of product development and design.

In recent years, however, a growing number of organizations are realizing the capability of cloud-based PLM software to drive fulfillment benefits. There is a recognition that you can strengthen your supply chain management by deploying PLM from product conception to multi-faceted fulfillment. As your product approaches maturity, it necessitates changes to workflow, supply chain, and fulfillment processes as a means of attaining sales objectives and driving overall business strategy.

But before we get into that and how PLM affects fulfillment, first a definition of PLM.

A change request (CR) is basically any change in the initial set of signed-off requirements. So, typically in a waterfall model implementation, the requirements phase ensures that all the requirements (features/functionalities/functional and non-functional) are agreed upon and documented before development starts. After that, any new scope brought or requested by clients becomes a change request. There is an additional cost associated with implementing a change request.

Even in the agile model of working, although there is flexibility in the implementation of the project, vendors ensure that a high-level set of requirements are discussed and agreed upon. The iterative way of working ensures that clients have their eyes on the product as it is developing and can suggest corrections or alignments. However, no vendor can work with entirely flexible requirements. It's not feasible from a budgeting standpoint.

Business analysts, process analysts, systems analysts, and process owners use Business Process Normalization to more effectively elicit and perceive, unequivocally define, and model sound, modern business process structures, and workflow configurations. Proficiency with this analysis technique benefits their process management, digital transformation, and regulatory compliance projects.

A diagram is a 2-dimensional representation of a story, which shows elements and their relationships on a single canvas. An element is shown on a single diagram. (To show the same element information on a 2 diagrams, the element is duplicated.) When the properties of a diagram element are changed, the change is reflected only on that diagram.

A model is a 3-dimensional representation of a collection of related stories, which captures diagram elements as model components. A component includes all element properties and relationships between different elements on all diagrams. A single model component can be shown as elements on several diagrams. A change to the properties of a diagram element or model component is reflected on every diagram where that component is displayed.

A model does not necessarily need to include any diagrams. Diagramming is the most common method for creating and maintaining model components, but the diagrams can be deleted without changing the model.

If a picture is worth a thousand words, then a diagram converts those words into a story. A model organizes those stories into a book.

Despite significant investments of time and well-intended stakeholder effort, many business process models still end up being not very useful for their intended purposes. Too many do not reflect the business accurately enough to be useful, do not have sufficient key stakeholders’ buy-in for real decision making, or do not include the kinds of process information that the model’s readers are looking for. Some even confuse their readers with complex or incongruous graphical notation.

Business process mapping is the most indispensable technique for performance improvement and technology innovation initiatives. More than just boxes and arrows, the process map reveals the “magic” and wisdom of how and why work gets done.

Sadly, too many professionals give process mapping short shrift. Here are 10 tips that will ensure process mapping helps you achieve full potential from your improvement/innovation project.

No-one (in their right mind anyway!) ever sets out to design processes that qualify in the above categories, so why then do we end up with them?  This might be because of tight deadlines, not starting with the customer in mind, not testing the processes with the target audience or even not updating implemented processes once they are found to be sub-optimal or S.U.C.K.’y… Whatever the reasons, we should seek to prevent the creation of processes like these by all means.

Perhaps you’ve seen a sign at an auto repair shop that asked, “What do you want: good, fast, or cheap? Pick two.” While humorous, the sign is also wise: it acknowledges the reality of trade-offs. You generally cannot optimize every desired outcome of a given situation.  The notion of such a “triple constraint” or “iron triangle” appears throughout project management. The problem is that I have seen numerous representations of the triangle with various parameters on the triangle’s vertices—size, cost, time, or scope—and various assumptions made about what is being held constant, such as quality or functionality. I’ve also seen diagrams that show four project dimensions. So, in my view, the traditional “triple constraint” is wrong, although the concept of constraints and trade-offs is certainly valid.

In Part 1 of this series John Seddon argued that Agile, as practiced, is bereft of knowledge, hence its ubiquitous failure. Here he argues that ‘get knowledge’ is the starting-place for effective change.

Part 2: Knowledge: the prerequisite for profound change

It may seem heretical to suggest that we make change without knowledge, but, as Deming pointed out, experience is not equivalent to knowledge; you can spend 20 years in an organisation without knowing how to change it for the better. Leaders, clients and stakeholders describe requirements or problems to solve on the basis of their current world view, governed by information from their current control systems, but what if their world view is flawed? What if there are bigger and different problems to solve?

Five S can be applied in any work environment and prepares a work area for a follow-on Lean process improvement effort. In this case, 5S prepares my garage for Lean process improvement in doing home activities like automobile maintenance, appliance repair, and hobbies like gardening and woodworking. But, remember the preparation benefit is only realized if 5S is sustained. As I said I am the worst (ugly) in keeping the “new world order” in my garage.