Introduction

This paper presents a graphic framework or model of customer/supplier interactions in very mature environments. It is built on a graphic framework presented at last year's 3ISQC conference in our paper, "A FRAMEWORK FOR MEASUREMENT PROGRAMS.". We have found that the ideas presented here can be used by anyone, whether management or practitioner, to improve the effectiveness of measurement and improvement programs.

Our position for this paper is that the success of improvement programs is ultimately tied to the maturity of the consumer of your products and services and the health of the communication paths between supplier and customer.

The models presented in this paper have been used over the past several years in an environment of engineers, engineering management, software developers and business management. We have seen the models used many different ways to interpret different project management programs. It is often used as a shorthand to explain a sometimes foreign and complex process. It is also used as a graphic checklist of components and attributes required for improvement activities. Once the model has been presented and used once, the graphics allow people who are swamped with information, to quickly recall the fundamental concepts. In this way, they can get down to the important issues without having to relearn the basic concepts each time metric, improvement, and communication issues are presented.

However, these models are not intended to represent physical organizational structure. The concept of having a separation of process improvement and process usage is important because they are two separate tasks that need to be managed. They may or may not be done by the same people. Also, the models do not attempt to characterize how organizational memory or the resulting Professional Practices are stored, accessed, maintained, and archived.

This paper explains the models and concepts in much the same way as we do. We call the basic model the "Single Engine Model" and always present it first. We present an extension oriented toward process memory. This extension we call the "Two Engine Model". The "Four Engine Model" is used to describe the importance of having sound customer communications and relations. The model is extensible and we have been amazed at the different ways people use it as a fundamental building block. Because the Single and Two Engine Models where discussed in detail last year, we will only briefly review their most important features.

Single Engine Model

PROCESS is where the needs and constraints of the customer are translated into deliverables. It is monitored by MEASUREMENT and its behavior is influenced by ACTION.

CONTROL is the decision making mechanism which uses MEASUREMENT and external Business Objectives and Constrains to direct ACTION. The Trigger signal is used by CONTROL to know when to start and stop the engine.

The MEASUREMENT meter indicates that there are a variety of ways to collect evidence regarding the state of the target PROCESS, the product it creates and results or satisfaction of the use of the deliverables.

If any of the components of the Single Engine Model are missing or not working, the model can't effectively operate as a feedback loop. In other words, it can't correct for observed error or performance. This can either be caused by not knowing the current state of the PROCESS (no MEASUREMENT) or not issuing corrective actions (no ACTION ).

Organizational Memory

One such repository is in the experiences of the practitioners. We refer to this as "individual professionalism". Unfortunately, this is not a reliably shareable memory. An obviously superior repository of lessons learned is a documented statement of Professional Practice for the group or organization. This documented description can be shared between workers and rationally analyzed. However, the notion of organization must be larger than a group of people doing a task or project. Projects have the tendency to come and go. Figure 2 illustrates that an organization needs to be defined in such a way as to retain past experiences (to have a memory). The use of documented professional practices can be an instance of "organizational professionalism".

Figure 2. Organizational memory.

The projects in Figure 2 represent those of the past and of the present. Lessons learned, a body of experience based on organizational practices, constantly accumulates in the organizational "memory" of documented professional practices.

Figure 3. The Two Engine Model

Two Engine Model

The block diagram in figure 2 can be thought of as a simplified Two Engine Model shown in Figure 3. Figure 4 shows this relationship. For the purpose of clarity in this paper, we will use the block diagrams. However, the complete graphic is used when we use the model in detailed discussions. The block diagram also illustrates the leverage of a single organizational improvement effort over many development efforts.

Figure 4. Detailed vs. Block Two Engine Model

Four Engine Model

Figure 5. The Four Engine model

An interacting pair of Two Engine Models now becomes what we call the Four Engine Model. This model represents two mature organizations, each producing product and each using the constant improvement of professional practices based on the lessons learned in their use.

To show the connections and relationships between these two high maturity organizations, we will use block diagrams to make the communication and product flows clearer.

Four Engine Connections

For instance, based on experience, the customer has determined that it takes X units of resources to do certain tasks when the current Professional Practices of the software user's organization are used. An improvement team had estimated that they can reduce the amount of resources for the process if software is used. This is the information passed to the software development organization. The requirements come from the desire to improve the customer's organizational performance.

Figure 6. Software Requirements

Of course, not only business requirements flow on this path. Customer required standards, detailed specifications and constraints also flow along this path.

If the software supplier builds the software that will satisfy the customer requirements, what path does the software take? In high maturity organizations, the product flows on the path in Figure 7. The software is developed by the software supplier using his organizations professional practices, delivers the software to the customer's process improvement engine where it is delivered to the customer's value added development processes as new Professional Practices.

Figure 7. Software Product

The result of the end-use of the software is communicated back to top engine of the mature customer. If changes need to be made to the software, requirements are again communicated to the software supplier as in figure 6.

A third line of communication is used when the software supplier has the goal of improvement and wants an answer to the question "how well do our current professional practices work"? While the data and satisfaction from developers is important, the results of their use in practice can only come from the user of the software, the customer. Figure 8 shows the "Results and Satisfaction" flow from the top improvement engine of the customer to the corresponding top improvement engine of the supplier.

Figure 8. Software Improvement

In the same way that organizational memory is important in the Two Engine Model, remembering the results of usage of the software product is important in accurately answering the question "how well does our software work in meeting the needs of our customers"? Without this formal organizational memory on the customer's side, customer satisfaction and usage information will be limited to either a subset of current usage, or the loud voices of individuals who might not represent true usage information.

Maturity Transitions

When a low maturity supplier and user interact, the result is low customer satisfaction and constant problems for the supplier. Since there are few (if any) organizational professional practices, problems are blamed on individuals. In this environment, success (when it comes) is usually attributed to the heroic efforts of a few key individuals. Success and failure is determined by individual professionalism (or lack thereof).

When a high maturity supplier interacts with a low maturity user, the customer is unhappy. Unable to understand why the high maturity supplier does things the way they do, the customer has the perception that the supplier is interested in "bureaucratic nonsense". The customer attributes this behavior to many things. Of course, the supplier sees no end to stream of changes to requirements and the inability for the customer to speak with one voice.

If the tables are turned and the customer is high maturity and the supplier is low maturity, the customer is still unhappy, but for different reasons. Because the customer is accustomed to organizational professionalism, he becomes annoyed at the seemly endless variation of the suppliers support. The software supplier is constantly struggling to live up to the expectations of a customer who seems to "have his act together." Eventually, the mature software user is likely to dump the supplier. In any case, if the parties stay together, somebody will change.

A broken relationship is not always the outcome of partners of different maturity. One of the parties can change. If a software organization really wants to improve their organizational maturity, they should find a customer with a high level of organizational maturity. Of course this is not always easy. Customers who have obtained high levels of process maturity have probably learned that low maturity venders cause problems.

High maturity software organizations should also stay away from low maturity customers. There is always the possibility that interacting with a low maturity customer will have the effect of eroding the organizations Professional Practices. In any case, when the software supplier and software user are of two different organizational maturities, if they stay together, someone will change.

Four Engines or One Team?

Ownership Roles

Figure 10. Management Roles Figure 10 suggests that the top engine of the Two and Four Engine Model, describe the roles and responsibilities of a "Process Owner". These processes are part of the Professional Practices that are used in the bottom engines by "Process Managers".

The working definition of a process owner and a process manager are never clearly described and communicated in immature organizations. The detailed two engine model clearly describes the activities and scope of a process owner.

Conclusion

For improvement to happen, an organization needs to be able to evaluate their current maturity and have a framework to build upon. The success of an organization to improve is tied to the maturity of the customers you have. It is not enough just to have customer involvement. Without this infrastructure, lessons learned are never remembered and an organization repeats the same mistakes over and over again and can actually degrading current practices by sapping organizational morale, energy, and resources.