2. Strategic Scoping: The MetaPower Design Model
Scoping in the MetaPower Design Model
Negotiating Alignment
Design Within the Connections
Scope Control in a Complex Enterprise
If processes interface operationally with each other through data, and consequently share the same data vocabulary, a higher perspective is required to understand why processes and their interfaces exist.
Processes also have strategic connections within the business enterprise, consisting of these shared data definitions and their business rules. Business rules govern why data are created and changed within each process.
The strategic plane has to do with the purpose of the process: why has the process been configured as it has? For example, a financial institution may be changing their process for setting lending rates. Looking up, the why might be: in order to be the first to market with the lowest rates. Looking down, the how might be: hook all the branch offices to headquarters via a virtual private network so that changes in rates are instantly reflected globally.
MetaPower analyzes the enterprise into five design tiers: strategy, program, process, tools and data all built on the foundation of data flow and data vocabulary. Each has its own behaviors, expectations, and design authority. The further up the design model one ascends, enterprise changes become more radical; as one descends, the changes become more incremental.
Scoping in the MetaPower Design Model
Proper scoping can only occur if the five design tiers are understood and kept separate. For example, if a process is broken, discussions will frequently bounce up to the program tier without recognizing it. But generally those working on a process do not have the authority to alter the program. Change projects can become stalled as issues bounce between tiers without the authority to bring resolution.
If, however, the change project is scoped explicitly within one of these tiers, the parameters of the change can be clearly defined, resulting in accurate scoping and successful change. Further, if the process cannot be fixed without altering the program, then that too becomes clear and the change project itself changes. Instead of redesigning a process, you're now faced with arguing for a change in program, a very different task.
Negotiating Alignment
A change project must therefore negotiate with the tiers above and below.
Negotiation involves explicit buy-in by the people responsible for bordering tiers. This is not only for political reasons (although political reasons are important), it is also to ensure that the proposed change fits with the panoply of programs or tools that may be affected.
Negotiating up
Programs don't give processes data; they give them business rules, the rules that dictate why the processes create, delete, or change data. If a process design is being changed, the owner of the program that gives the process its business rules must agree to the proposed change.
Negotiating down
Process change may require changing the tools being used in the process. The owners of these tools must agree to the change, determining how the process will be implemented. Any change in the nature or timing of data shared across tiers must be explicit and agreed to by all parties.
Anything short of this negotiation, both up and down, isn't planning; it's target shooting in what may be a crowded room.
Design Within the Connections
Negotiation means negotiation! This is not a license for the change project to impose its design on the interfacing processes or aligned programs and tools. To negotiate means to seek to understand constraints and to clearly express issues.
The result of negotiation is typically de-optimizing the process design for the sake of the connections. Can this be right? This issue is at the heart of the most common change failure. For the sake of correctness in process design, connections are compromised and associated programs, processes and tools are compromised. Our focus on the process change, exclusive of the connections, dooms us to failure.
Rather, the change design must be compromised to meet the connection imperative! This is a fundamental law of the Science of Change; optimizing the system will require de-optimizing the system components.
Bear in mind that successful change can only be designed within a single tier. Failure to recognize when a project is changing tiers is one of the most common ways projects and their subject processes fail to meet objectives. When this happens, we stop negotiating, we start imposing, and we lose our context of connections.
Scope Control in a Complex Enterprise
Seems simple enough! When changing a process, explain your suggestions for program changes to the program owner. If it makes your process better, he will need to change. Right?
Wrong! The design model understands that a program affects many processes. Many programs likewise affect a process. This many-to-many relationship between tiers is fundamental to understanding scope control during negotiations.
For example, the sales order process finds the engineering data required at order entry to be time consuming and error prone. Therefore, they want to change the program rule that requires entry by the salesman at the time of order. But the "program design" needs to capture this information at this time because it is the most efficient time to complete customer negotiations. If the collection of this data is postponed to the engineering process, customer expectations are usually compromised. Additionally, the engineering process would have to be re-vamped to collect this information.
Therefore, the negotiation is settled not from the process perspective, but from the larger view of the program and its impact on many processes. The sales order process design must meet this negotiated program requirement. Perhaps the skills of the sales people can be enhanced. Perhaps technology can provide better tools for the selection of engineering options. However, in order to achieve the program objectives, the problem must be solved; the order must contain the engineering data.
Back to Top
Previous / Next