Questions about CDTF.

CDTF is a systemic framework for understanding, designing, executing, and adapting complex organizational transformation. It helps practitioners look at the organization and the transformation together, including people, roles, structures, processes, governance, capabilities, technology, information, incentives, dependencies, and the interactions among them.

The purpose is to understand what is happening well enough to shape a transformation that fits the system, carry it out, learn from what happens, and adjust when the evidence changes. CDTF provides a common architecture for doing that work without assuming every transformation should follow the same sequence or use the same response.

Diagnosis, design, and execution are three connected forms of work in CDTF. Diagnosis establishes which conditions are present, how they are interacting, and what evidence supports that conclusion. Design uses that understanding to shape choices about governance, capability development, sequencing, ownership, coordination, measurement, engagement, technology, and other parts of the transformation.

Execution puts those choices into action and produces new evidence about how the system is responding. That evidence can confirm a design choice, require an adjustment, or reopen the original diagnosis. The movement can go back and forth as the transformation develops.

Start with the seven models and the questions they raise. The models provide the initial view of the transformation system. Dimensions narrow the investigation when an area needs closer attention. Individual constructs provide greater specificity when the evidence gives you a reason to go deeper.

You don't need to learn or assess the entire framework before it becomes useful. Start broad, investigate more precisely where the evidence points, and use what you learn to shape design and execution.

No. PRIME, FABRIC, SENSE, FORGE, VECTOR, ANCHOR, and EVOLVE are connected models, not phases. Several may require attention at the same time, and their relative importance can change as the transformation develops.

The models function as levers across diagnosis, design, and execution. A model that needs little attention early may become important later, and new evidence can cause work in a model to be reopened without restarting the framework from the beginning.

No. The full architecture is a reference map, not a checklist. Evidence determines which areas require attention. Some constructs may be active, others may remain inactive, and some may become relevant later as conditions change.

The nearly 80 constructs represent the specificity available within CDTF. They don't represent 80 required activities or 80 assessments. A construct may help clarify a diagnosis, shape a design choice, guide an execution response, or identify something that needs to be monitored as the transformation unfolds.

The seven models are the top-level levers of the framework. The 29 dimensions organize related areas within those models. The constructs name more specific conditions and mechanisms that practitioners can investigate and work with when greater specificity is useful.

That structure lets practitioners move from broad questions to more detailed ones without carrying the entire framework in their heads. The architecture stays consistent, while the evidence determines where to go deeper and how the findings should influence design and execution.

CDTF names the conditions it is designed to investigate and work with, making them easier to recognize, discuss, and compare. Each construct name provides shorthand for a condition or mechanism whose meaning, boundaries, evidence, and possible alternatives have been defined. This allows practitioners to refer to the condition without repeatedly describing it from scratch.

Consider how diagnosis works in medicine. A fever, cough, or shortness of breath is an observation. Those observations might be explained by several different conditions, and identifying which condition is present requires additional evidence. Medicine gives those conditions names because repeatedly describing the symptoms, mechanisms, and distinctions among possible diagnoses would make communication unnecessarily cumbersome. Once the condition is understood, that diagnosis also helps shape treatment and what should be monitored next.

CDTF uses construct names in a similar way. Considerable effort went into making many of those names descriptive and memorable, including the use of acronyms that reflect the condition they represent. They're meant to help practitioners recognize and retrieve concepts, not create another vocabulary that has to be memorized before the framework can be used.

A practitioner can begin with the seven model-level questions, narrow the investigation through the dimensions, and refer to individual constructs when greater specificity is useful. Familiarity with the construct vocabulary will naturally increase with use, much as terminology does in other professional fields.

Begin with observable evidence rather than a construct name. Look for patterns in what is happening, keep more than one explanation open, and use the model and dimension structure to narrow the investigation.

A construct becomes relevant when the evidence supports the condition it describes and helps distinguish that condition from plausible alternatives. Matching a problem to a familiar label isn't enough. Once a construct is established as relevant, it can influence how the transformation is designed, what actions are taken during execution, and what evidence should be monitored next.

Construct boundaries are part of the reasoning process. Closely related constructs are differentiated by asking what must be true for one explanation to fit better than another, what evidence would separate them, and whether each condition can exist independently of the other.

The framework's differentiation work includes nearest-neighbor comparisons, common misdiagnoses, and discriminating questions. The distinction is important because two conditions that look similar on the surface may call for different design choices or execution responses.

The diagnosis changes. CDTF treats a diagnosis as a conclusion that must remain open to new evidence rather than as a label that becomes permanent once assigned.

A strong reasoning process looks specifically for evidence that could rule out the leading explanation. If that evidence appears, practitioners return to competing explanations and revise the diagnosis. Design and execution should change with it when the new evidence affects what the transformation needs to do.

That's expected. Conditions in a complex organization often reinforce, constrain, or amplify one another. CDTF allows several constructs to be active while they occupy different states across diagnosis, design, and execution.

The work is to understand the relationships among those conditions rather than assume every active construct has equal importance. Dependencies, consequences, available evidence, and the effect of one condition on others can shape design priorities, sequencing, ownership, intervention choices, and what needs to be watched during execution.

Diagnosis is useful only if it changes what the transformation does. In CDTF, diagnosed conditions become design inputs. A governance problem may require changes to decision rights or escalation paths. A capability problem may change how development is structured. Incompatible assumptions across workstreams may require a different coordination mechanism. Weak evidence may require the measurement system itself to be redesigned.

This is why two organizations pursuing a similar transformation may need very different designs. The technology, process, or stated destination may look similar, while the organizational system around it creates different requirements for how the transformation should be built and carried out.

No. A construct helps define the condition that needs attention, but the response depends on the organization, the other conditions that are active, the stage of the work, available capabilities, constraints, and the evidence about what is causing the problem.

CDTF provides design logic rather than a fixed recipe. The same construct can lead to different responses in different settings, and the response can change as new evidence appears. This keeps the framework from forcing every organization through the same set of activities simply because the transformation has the same label.

Yes. Two organizations can implement the same technology, pursue a similar operating model, or undertake the same type of merger and still face very different transformation conditions. One may have a capability problem, another may have conflicting governance, another may have incompatible interpretations across functions, and another may be relying on temporary external support that the organization can't sustain.

CDTF keeps the architecture consistent while allowing the transformation design to change with the system. This helps practitioners avoid treating different organizational realities as though they were the same.

CDTF remains active after implementation begins. Execution generates evidence about whether the design is working, how people and processes are responding, where dependencies are appearing, what risks are emerging, and whether the organization is developing the capability the transformation requires.

That evidence can change sequencing, governance, capability development, coordination, measurement, engagement, technology choices, or other parts of the response. Execution is therefore a source of learning as well as delivery. The framework is designed to keep the transformation responsive to what the system is actually doing rather than protect the original plan from new information.

When several conditions are active at the same time, CDTF doesn't assume they all deserve equal attention or that they should be addressed in the order they appear on the wheel.

Start with the conditions that are creating the greatest risk, preventing you from understanding what's happening, blocking other work, or making other fixes difficult or impossible. Sometimes addressing one underlying condition will reduce several other problems at once.

The order depends on how the conditions are connected, what depends on what, and what could happen if a condition is left unresolved. That logic can shape the sequence of design decisions as well as the order of execution.

CDTF is designed to help practitioners distinguish among different kinds of change. Some adversity is a reason to persist because the destination and the approach are still sound. In other situations, the destination remains valid but the route, timing, sequence, governance, or other parts of the approach need to change. There are also situations where new evidence challenges the destination itself and the future state needs to be reconsidered.

CDTF refers to this as transformation wisdom: knowing when to persist, when to change the approach, and when new evidence requires reconsidering the destination. Keeping diagnosis, design, and execution connected allows the transformation to adjust without forcing a restart and allows the future state to be reopened when the evidence is strong enough to justify it.

Yes. A construct can be inactive early in the work and become important later because the organization, the transformation, or surrounding conditions have changed. A condition that was previously addressed can also return.

This is one reason CDTF is evidence-responsive rather than stage-based. A newly active construct can reopen diagnosis, change a design choice, alter execution, or create a new monitoring requirement without requiring the transformation to start the framework over.

CDTF treats sustainment as a design concern before the program closes. ANCHOR focuses on whether the new way of operating can continue after temporary program support fades and whether the organization has removed the dependencies that would cause the change to weaken or reverse later.

Those dependencies can include consultants, a few key individuals, temporary governance forums, unusual levels of management attention, workarounds, incentives, or other support that exists only while the program is active. The goal is to leave behind organizational capability and operating conditions that can support the new way of working without the program continuing to prop it up.

No. CDTF is deliberately designed to serve as an expert toolbox rather than a step-by-step method that assumes the same approach will work in every situation.

The framework gives practitioners a structured way to understand what's happening, consider competing explanations, make their reasoning visible, shape the transformation around what they learn, and adjust design and execution as new evidence appears. It doesn't remove judgment. It gives judgment a stronger foundation.

That flexibility is important because transformations don't unfold under identical conditions. A fixed sequence can encourage people to apply the same activities regardless of what the organization actually needs. CDTF lets evidence determine where attention should go and what type of response the situation requires.

CDTF can help less experienced practitioners ask better questions and investigate a transformation more systematically. It gives them a structure for looking beyond the most obvious explanation, considering alternatives, identifying what evidence they need, and connecting what they find to design and execution choices.

Experienced practitioners benefit differently. CDTF gives them a way to make reasoning that may otherwise remain largely intuitive more explicit. It can help them distinguish between conditions that look similar on the surface, test assumptions, identify relationships among problems, explain why they reached a particular conclusion, and make the logic behind design or execution decisions easier for others to follow and challenge.

Experience still helps. No framework can substitute for judgment developed through working with organizations and complex transformations. CDTF is designed to support that judgment and make it easier to question, communicate, and revise as new evidence emerges.

Yes. The architecture is designed to remain consistent while its configuration changes to fit the transformation and the organization. That can include digital and ERP transformation, enterprise AI adoption, mergers and integration, operating-model redesign, regulatory change, workforce transformation, and other large organizational changes.

The framework shouldn't produce the same configuration in every setting. Evidence determines which models, dimensions, and constructs require attention and how they should influence diagnosis, design, execution, and sustainment.

Organizations often draw on a range of disciplines, methods, and structured approaches to support transformation. Some focus primarily on individual understanding, engagement, and adoption. Others focus on mobilizing the organization, managing delivery, redesigning processes, developing capabilities, or implementing technology.

CDTF takes a more systemic view by looking at the organization and the transformation as an interconnected system. That includes people, roles, structures, processes, governance, incentives, capabilities, technology, information, decision-making, workstream dependencies, and the interactions among them. It uses that understanding to shape how the transformation is designed, carried out, monitored, and adapted over time.

CDTF is designed to work alongside other useful disciplines and methods when the evidence indicates they're needed. It doesn't assume in advance that the same type of intervention will fit every situation.

CDTF is designed to complement the disciplines already supporting a transformation. Program and project management organize delivery. Technology disciplines design and implement technical solutions. Change-focused disciplines support communication, engagement, adoption, and other people-related aspects of change.

CDTF's diagnostic orientation is strongly aligned with the Organization Development tradition, particularly its emphasis on understanding the organization before selecting an intervention. Organization Development draws on areas such as systems thinking, group dynamics, culture, structure, power, learning, participation, and Action Research to understand how organizations function and how change occurs within them.

That diagnostic orientation is one part of a much broader theoretical foundation. CDTF also draws from complexity theory, sensemaking, learning and reinforcement, organizational design, measurement, resilience, capability development, and other established bodies of research. It brings these perspectives together within a systemic architecture for understanding the people, processes, structures, governance, capabilities, technology, information, incentives, dependencies, and interactions that shape a transformation, then connects that understanding to design and execution.

CDTF helps connect these different forms of work to evidence about what's happening across the system and what the transformation should do in response.

CDTF is built on a broad body of established research and practice developed over roughly the past seven decades. Its foundations span multiple disciplines concerned with how organizations function, how people interpret and respond to change, how systems behave, how capabilities develop, and how evidence can be used to guide decisions.

For readers interested in the framework's academic foundations, that work includes systems thinking, Organization Development, Action Research, sensemaking, organizational learning, adult learning, reinforcement theory, organizational design, culture and power, complexity theory, measurement and construct validity, resilience, dynamic capabilities, cybernetics, and forecasting methods.

The framework doesn't claim to replace those bodies of work or present them as new. Its contribution is to bring them together within a common architecture for diagnosing transformation conditions, shaping design choices, guiding execution, and revisiting decisions as new evidence emerges.

The models, dimensions, and constructs were then developed through structured definition, comparison, boundary testing, differentiation analysis, scenario-based examination, and repeated refinement. Considerable effort went into reducing conceptual overlap, clarifying what each construct represents, and distinguishing conditions that may look similar on the surface but require different responses.