15.1 Why Tailor: Design Factors

Quick Answer: There is no one-size-fits-all COBIT. Design factors are the enterprise conditions that shape the governance system: they change which of the 40 objectives deserve more attention and at what target capability. That is how COBIT operationalizes tailored to enterprise needs and dynamic governance system. Variants and focus areas also tailor components. The home publication is the COBIT 2019 Design Guide. The classic exam trap is implementing the whole core model equally.

Designing a Tailored Governance System is 7% of the 75-question COBIT 2019 Foundation exam — roughly five items. Those items are cheap if you remember the idea, the eleven names, and the four-step workflow. They are expensive if you treat COBIT as a 40-objective poster you stand up at the same capability everywhere.

This section is the why. The next section names all eleven factors. The last section walks the official design workflow and the toolkit. Do not skip the why. Every later trap — “implement all 40 equally,” “start the Implementation Guide before you have a design,” “drive every process to capability 5” — is a failure of this concept.

Why one COBIT cannot fit every enterprise

COBIT 2019 is a framework, not a finished building. The 40 governance and management objectives are generic. A cost-leader foundry, a first-mover digital bank, a municipal water utility, and a twelve-person professional-services firm can all use the same core model. They must not end up with the same governance system.

Think of a building code versus a finished building. The code is shared. The hospital, the warehouse, and the apartment tower still look different because the site, the occupancy, and the risk are different. Design factors are the site conditions. Tailoring is how you get a building you can occupy without wasting steel on floors nobody will use.

The purpose of enterprise governance of information and technology (EGIT) is value from I&T through a balance of benefits realization, risk optimization, and resource optimization. Treating every objective as equally urgent burns the resource dial and delays the benefit dial. Tailoring is therefore not a luxury for large enterprises. Small enterprises have more reason to tailor, because they cannot staff a copy of a global bank’s committee stack.

COBIT 5 already said the framework should be applied to the enterprise. COBIT 2019 made tailoring a first-class governance-system principle and then published a design-factor toolkit so the principle is not a slogan. Principles taught that tailoring is required. This domain teaches what a design factor is and why it is the mechanism.

What a design factor actually changes

ISACA’s definition is operational, not poetic. A design factor is a factor that influences the design of an enterprise’s governance system and positions it for success in the use of I&T.

Two levers move:

1. Priority among the 40 objectives. Some objectives become more important. Others recede. A digital first-mover will raise APO04 Managed Innovation, APO03 Managed Enterprise Architecture, and APO02 Managed Strategy. A cost-leader manufacturer will raise APO06 Managed Budget and Costs, BAI09 Managed Assets, and DSS01 Managed Operations.
2. Target capability. The same objective can be “important enough to exist” in one enterprise and “must be quantitatively managed” in another. Priority and capability are related but not identical. A bank can decide APO13 Managed Security is both high priority and high target capability. A quiet manufacturer can keep security in scope at a lower target capability than the bank without pretending the objective does not exist.

Design factors do not add a forty-first objective, invent a sixth domain, or retire EDM, APO, BAI, DSS, or MEA. They re-weight the core model. After the design, you still have the same 40-objective spine. You have a profile, not a different framework.

Keep that table in your head. Tailoring is a profile over the published model. It is not a rewrite of COBIT.

Two principles this domain makes real

Chapter 5 already taught tailored to enterprise needs: there is no single correct COBIT implementation. This domain is that principle with a workflow and a toolkit attached.

The companion principle is dynamic governance system. Tailored is design-time: use the factors to build a system that fits this enterprise. Dynamic is change-time: when one or more design factors change — strategy, sourcing, threat landscape, regulation, size — the enterprise must consider the impact on EGIT. A one-time design workshop that is never revisited is tailored once and then frozen. That fails the dynamic principle even if the original workshop was excellent.

Keep the pair straight on the exam:

• Tailored answers “why don’t we implement all 40 equally?”
• Dynamic answers “what do we do when a factor changes?”
• This domain answers “how do we actually design the system?”

If a stem describes a retailer that moves overnight from insourced IT to multi-cloud, the principle in play is dynamic. If the same stem then asks how the enterprise should decide the new priority profile, you are back in this domain: re-run design factors rather than copy last year’s system.

Variants and focus areas also tailor

Design factors are not the only tailoring tool.

Variant components are tailored expressions of the same seven component types — processes; organizational structures; principles, policies and frameworks; information; culture, ethics and behavior; people, skills and competencies; and services, infrastructure and applications. A small credit union and a global bank can pursue APO10 Managed Vendors with different structures, different policy formality, and different skills. The objective is the same. The component realization is not.

Focus areas apply a lens to the core model for a topic such as small and medium enterprises, information security, DevOps, or I&T risk. They are optional overlays. They do not replace the 40 objectives and they do not add Foundation exam domains. An enterprise can use variants even without adopting a named focus-area publication.

Together, design factors, variants, and focus areas are why two faithful COBIT implementations can look different and both be correct.

The Design Guide is the home publication

The COBIT 2019 Design Guide owns this domain. It contains the design-factor descriptions, the four-step workflow, and the design toolkit — a spreadsheet that scores the 40 objectives through initial, refined, and concluded design.

Do not park this content in the wrong book:

• Introduction and Methodology introduces the idea of design factors and the product architecture. It is not the design workshop.
• Governance and Management Objectives is the detailed 40-objective core model. It is what you tailor, not how you tailor.
• Implementation Guide is how you get from the current system to the designed target through a seven-phase continual-improvement lifecycle. It is not a substitute for design.
• Design Guide decides what to implement and at what capability.

Foundation candidates do not have to operate the spreadsheet. They do have to know that the toolkit exists, that it lives in the Design Guide, and that its output is a prioritized, capability-targeted governance system — not a project plan.

Exam trap: implement the whole core model equally

This is the highest-yield trap in the 7% domain.

Wrong instincts:

• “A complete COBIT program means all 40 objectives at the same capability.”
• “Skipping or deprioritizing an objective is always non-compliant.”
• “Design factors are optional decoration for large enterprises.”
• “The same RACI and the same committees work for every enterprise.”
• “Start implementation first; design is paperwork you fill in later.”
• “Drive every process to capability level 5 so nothing is missed.”

Right instincts:

• There is no one-size-fits-all COBIT.
• Design factors change which objectives matter more and at what target capability.
• Completeness means the right objectives at the right capability for this enterprise.
• Variants and focus areas further tailor components.
• The Design Guide is where the design happens; the Implementation Guide is how you get there.

Picture two workshops. In the first, a consultant prints the 40-objective poster and assigns a capability-5 target to every row “so the board cannot be accused of gaps.” That is not rigor. It is a refusal to design, and it will starve the objectives that actually create value. In the second, the same consultant walks the design factors, raises innovation and architecture for a first-mover bank, raises budget and operations for a cost-leader plant, and sets different target capabilities. Both enterprises still use COBIT 2019. Only the second one has a governance system.

When a stem offers a one-size-fits-all program, reject it. When it offers design factors as the reason two enterprises can both be faithful and still differ, take it.