Written and maintained by CASRAI Editorial Board
Last updated
Implementation Mapping is a systematic, five-task process for designing implementation strategies that are matched to the specific determinants blocking or enabling adoption of a program, practice, or policy — rather than selected because they are familiar, cheap, or what the last project used. It was introduced by Maria E. Fernandez and colleagues in a 2019 Frontiers in Public Health paper as an extension of Intervention Mapping, the established protocol for designing the health-promotion interventions themselves. Implementation Mapping expands Intervention Mapping’s Step 5 (Planning for Adoption and Implementation) into its own full five-task protocol, purpose-built for the separate problem of getting an already-designed, already-effective intervention actually adopted, delivered as intended, and sustained in a real-world setting.
That distinction matters because it is where a lot of implementation planning goes wrong: teams often pick a strategy — training, a reminder system, an audit-and-feedback cycle — by convention or intuition, without first specifying which barrier that strategy is supposed to remove. Implementation Mapping forces the barrier (determinant) to be named before the strategy is chosen, and ties every strategy back to a specific determinant in a documented matrix, which is what makes the resulting strategy selection auditable rather than a plausible-sounding list.
Implementation Mapping is a design process, not an evaluation framework. It sits in the same subfield as the Consolidated Framework for Implementation Research (CFIR), which diagnoses determinants, and is a distinct tool from the RE-AIM framework, which measures outcomes once something has been implemented — the difference between these tool types is covered in more detail below.
The problem Implementation Mapping is built to solve
Most implementation efforts fail for a specific, identifiable reason: a real barrier that was never named, so no strategy ever targeted it. A hospital unit that mandates a new screening protocol without addressing clinicians’ workflow-integration concerns, or a research office that rolls out a new data-management requirement without addressing PI unfamiliarity with the underlying standard, is picking activity (training, a memo, a kickoff meeting) without first specifying the mechanism that activity is supposed to change.
Implementation Mapping’s core move is to insert a determinant-identification step between “we have an intervention we want implemented” and “here is our implementation strategy,” and to document the link between the two. The output is not just a strategy list; it is a set of matrices that show, for each thing an adopter or implementer needs to do, which determinants make that difficult, and which strategy targets each determinant. That traceability is what a grant reviewer, IRB, or internal evaluator can actually audit — “why this strategy” has a documented answer instead of a plausible-sounding one.
The five tasks
Implementation Mapping runs as five tasks. Like Intervention Mapping itself, the tasks are presented in sequence but are meant to be revisited iteratively as new information about adopters, settings, or determinants emerges — a planning team frequently loops back to an earlier task rather than treating the process as strictly linear.
Task 1 — Conduct an implementation needs assessment
The team identifies who the actual program adopters, implementers, and maintainers are — often several distinct groups (e.g., clinic leadership who adopt, front-line staff who implement, and an operations team that maintains the program after the initial rollout) — and assesses the barriers and facilitators each group faces. This is a needs assessment of the implementation context, separate from and in addition to whatever needs assessment justified the underlying intervention itself.
Task 2 — Identify outcomes, objectives, determinants, and change objectives
The team states adoption and implementation outcomes, breaks each outcome down into concrete performance objectives (the specific things an adopter, implementer, or maintainer must do), identifies the determinants that affect whether each performance objective happens, and crosses performance objectives against determinants to produce matrices of change objectives — statements of what needs to change about a given determinant for a given performance objective to be achievable. This is the task that produces the artifact described in more detail below.
Task 3 — Select theoretical methods and design implementation strategies
For each determinant named in the Task 2 matrices, the team selects a theory-based change method (a mechanism with an evidence base for changing that kind of determinant — for example, modeling, tailoring, or persuasive communication, drawn from behavior-change and organizational-change theory) and translates it into a practical, deliverable implementation strategy. This is the step where a published strategy taxonomy is often useful as a menu rather than a starting point — the widely-used ERIC compilation of implementation strategies (Powell et al., 2015, Implementation Science) is commonly drawn on here, but Implementation Mapping’s contribution is requiring that whatever strategy gets selected be justified against a specific determinant from Task 2, not chosen from the menu on its own appeal.
Task 4 — Produce implementation protocols and materials
The team turns the selected strategies into concrete design documents and materials — training curricula, job aids, reminder-system specifications, audit-and-feedback templates — ensuring each piece of content is aligned with the theoretical method chosen for it and tailored to the actual adopter/implementer population identified in Task 1, not a generic version of the strategy.
Task 5 — Evaluate implementation outcomes
The team assesses whether the implementation strategies achieved their intended adoption, implementation, and sustainability outcomes, using process and implementation evaluation. This is where a measurement framework such as RE-AIM, or Proctor’s implementation-outcomes taxonomy (acceptability, adoption, appropriateness, feasibility, fidelity, implementation cost, penetration, sustainability), typically supplies the actual outcome measures — Implementation Mapping specifies that this evaluation has to happen and against what it should be measured, but it is not itself an evaluation framework.
The performance-objective matrix, worked as an illustrative example
The scenario below is a hypothetical, illustrative walkthrough constructed to show the mechanics of Task 2 and Task 3 — it is not a documented case study attributed to any real institution, program, or published source.
Suppose a research-administration office wants a new data-management-plan (DMP) review checklist actually used by grants administrators before proposal submission, rather than treated as optional guidance. Task 1 identifies grants administrators as the implementers and the research-office director as the adopter who authorizes making the checklist mandatory. Task 2 states one performance objective for implementers: “the grants administrator completes the DMP checklist for every proposal before routing it for signature.” Interviews and observation surface three determinants that make this inconsistent in practice: administrators are not confident they can evaluate a DMP’s technical adequacy (a capability/self-efficacy determinant), the checklist adds a step to an already-tight routing deadline (a workflow/environmental-context determinant), and there is no visible consequence if the checklist is skipped (a reinforcement determinant). Crossing the performance objective against each determinant produces three change objectives: administrators can correctly apply the checklist’s criteria to a real DMP; the checklist step fits inside the existing routing timeline without requiring extra turnaround days; and skipping the checklist is visible to a supervisor before the proposal is submitted.
Task 3 then matches a strategy to each change objective rather than proposing one generic “DMP training” strategy for the whole problem: a short applied-practice session with real (de-identified) DMPs targets the self-efficacy determinant; redesigning the checklist as a 5-minute embedded step inside the existing routing form, instead of a separate document, targets the workflow determinant; and adding a checklist-completion field that a supervisor sees on the routing dashboard targets the reinforcement determinant. Each strategy in this example traces back to a specific, named determinant — that traceable link, not the strategies themselves, is what the matrix produces and what makes the resulting plan auditable.
How Implementation Mapping relates to CFIR, RE-AIM, and ERIC
These four names show up together often enough in the implementation-science literature that conflating them is a common mistake. They are different tool types, meant to be used together rather than as substitutes for one another:
- Implementation Mapping is a design process — the five tasks that take a team from “we have something we want implemented” to a documented, determinant-matched implementation strategy.
- CFIR is a determinant framework — a structured list of the domains and constructs (innovation, outer setting, inner setting, individuals, implementation process) a team can use inside Implementation Mapping’s Task 1 and Task 2 to name determinants systematically, instead of relying on an unstructured interview.
- RE-AIM is an evaluation framework — it supplies the outcome measures (Reach, Effectiveness, Adoption, Implementation, Maintenance) a team can use inside Implementation Mapping’s Task 5.
- ERIC (Expert Recommendations for Implementing Change) is a strategy taxonomy — a published compilation a team can draw candidate strategies from inside Task 3, after the determinant that strategy needs to target has already been named.
None of the four replaces another. A team can reasonably run Implementation Mapping as the overall process, use CFIR to structure determinant identification in Task 2, pull candidate strategies from the ERIC compilation in Task 3, and report outcomes using RE-AIM in Task 5 — each tool doing the job it is actually built for.
Frequently asked questions
Is Implementation Mapping the same as Intervention Mapping?
No. Intervention Mapping is the broader protocol for designing the health-promotion or behavior-change intervention itself, across six steps. Implementation Mapping expands specifically on Intervention Mapping’s Step 5 (planning for adoption and implementation) into its own dedicated five-task process, for use once an intervention already exists and the problem is getting it adopted and sustained.
Do the five tasks have to be completed in strict order?
They are presented in sequence, but Implementation Mapping is meant to be used iteratively: findings from a later task — for example, discovering during Task 3 that no feasible strategy exists for a determinant named in Task 2 — commonly send a planning team back to revise an earlier task rather than forcing the process to be linear.
What’s the difference between a determinant and a change objective?
A determinant is a factor that affects whether a performance objective happens — a barrier or facilitator, such as low self-efficacy or a workflow constraint. A change objective is what has to change about that determinant, stated for a specific performance objective, so that the objective becomes achievable. The determinant names the obstacle; the change objective states the target for removing it.
Does Implementation Mapping require using CFIR to identify determinants?
No. Implementation Mapping does not mandate a specific determinant framework. CFIR is a common and convenient choice because it gives Task 2 a structured construct list to work through, but a team can identify determinants through other means — theory-driven interviews, existing needs-assessment data, or a different determinant framework — as long as the determinants are documented and carried through into the matrices.
Is Implementation Mapping the right tool for a systematic review of implementation strategies?
No — Implementation Mapping is a prospective design process for planning a specific implementation effort, not a method for synthesizing findings across published studies. A team looking to systematically review or synthesize evidence on implementation strategies should use an evidence-synthesis methodology instead.
