Force field analysis maps what helps and what hinders a specific change. Put the proposed change in the center, identify the forces on each side, and decide which conditions you can strengthen, reduce or investigate. The result should lead to actions, not just two columns of opinions.
This worked example examines a fictional community group replacing scattered room-booking messages with a shared booking board. You will see drivers, barriers, optional strength ratings and a trial plan. All incidents and scores are invented for teaching; none predicts the success of a real change.
Define a change rather than a broad ambition
“Improve coordination” is an ambition. “Trial one shared room-booking board for two weeks while retaining a phone route” is a change you can inspect. It names what will differ, how long the test lasts and an access condition that must remain.
MIT’s Force Field Tool emphasizes identifying helpful and hindering forces and lowering barriers. That last point matters: adding more pressure to adopt a change can be less useful than removing a condition that makes adoption difficult.
Start with the current situation, desired situation and boundary. If participants are imagining different changes, their ratings will describe different decisions. Agree on the proposal before debating how strongly anyone supports it.
The fictional community-room situation
A small community center has one shared activity room. Organizers currently request times through several message threads, and the caretaker maintains a paper calendar. In this practice scenario, two requests have overlapped during the past month. No reliable annual conflict rate is available.
The proposal is to trial a single shared booking board for two weeks. A named caretaker would confirm bookings. Members could still telephone the caretaker rather than use the board directly. Nobody has approved the trial or tested whether it reduces confusion.
The aim is not to force everyone onto a new tool. It is to make the confirmed room status easier to inspect while preserving a usable way to request a booking. A public planning board must not display private contact details; that is a design requirement, not a benefit to trade away.
Map the driving and restraining forces
| Driving force | Why it may help this change | Current evidence status |
|---|---|---|
| Organizers want one confirmed schedule | A shared reference could reduce checking across threads | Stated preference in the fictional brief |
| Caretaker can confirm requests | A named owner could keep booking status consistent | Capacity still needs checking |
| Recent overlap is visible to the group | A concrete problem gives a reason to try an alternative | Two fictional incidents, not a trend estimate |
| Restraining force | Why it may hinder this change | What needs checking |
|---|---|---|
| Some members prefer telephone requests | Direct board use may exclude them | Whether caretaker entry preserves access |
| Nobody owns updates during absence | The board could become stale | A backup and handover arrangement |
| Several calendars may remain in parallel | Conflicting records could reproduce the original problem | Which record counts as confirmed |
| People are unsure what information appears | Privacy concerns may prevent participation | Minimum fields and visibility rules |
These labels describe conditions, not types of people. “Difficult members” is not a helpful restraining force. “Some members cannot use the proposed access route” identifies a condition you can respond to without dismissing the concern.
Use ratings only when they improve the discussion
Suppose the group chooses a subjective 1–5 scale, where 1 means a weak influence on this particular trial and 5 means an influence likely to block or strongly support it. This is a discussion convention for the exercise, not a measurement standard.
| Force | Illustrative rating | Why it receives that rating |
|---|---|---|
| Desire for one confirmed schedule | 4 | Directly related to the current confusion |
| Caretaker available to confirm requests | 3 | Helpful, but actual workload is unknown |
| No update owner during absence | 5 | Could make the trial record unreliable |
| Telephone access not yet defined | 4 | Could exclude some current participants |
Do not calculate a success probability from these values. A 5 does not mean five times the causal influence of a 1. Two factors may overlap, and a score may reflect one participant’s perspective rather than a shared assessment.
If people disagree, keep both ratings and their reasons. The disagreement may reveal different experience with the current process. Averaging it away can hide the very information the exercise was meant to surface.
A mandatory condition belongs in a separate requirement check. Privacy, permission or a required access route cannot be declared acceptable merely because the driver column has a larger total. Subjective scoring cannot authorize a change on its own.
Turn barriers into actions before adding pressure
1. Make the telephone route explicit
Keep telephone requests available during the trial. The caretaker enters an approved request into the same confirmed schedule, so the alternative route does not create a second competing record.
Assign who answers, what happens outside their availability and how the requester receives confirmation. “We will help people” is too vague to inspect. This action should address access, not require participants to surrender the route they need.
2. Name a backup for updates
Before the trial starts, identify a backup who can confirm changes when the caretaker is absent. Define when responsibility transfers and where pending requests sit. A board without an owner is a display, not a reliable booking process.
If no backup is available, reduce the scope or postpone the trial rather than mark the barrier as solved. An action plan should record a condition that remains unmet, not hide it behind a completed checkbox.
3. Agree on one confirmed record
Write what “requested,” “pending” and “confirmed” mean. Do not let an unapproved note look like a reserved slot. During a bounded transition, make clear which record people should trust and who reconciles discrepancies.
This is a human process design, not a claim that a whiteboard automatically prevents double booking. CodePic can help visualize the plan; it is not being offered here as a reservation system with automatic conflict detection.
4. Minimize visible information
Choose fields needed to understand room availability, and keep private contact information outside the shared planning view. Verify who may see or update the real record before using it operationally.
The force field does not replace those decisions. It identifies that uncertainty about visibility is a barrier and assigns a concrete check. If the actual arrangement needs specialist review, obtain it before proceeding.
A small trial plan with honest success conditions
For this fictional exercise, the group proposes the following plan, subject to approval and the requirements above:
| Item | Proposed arrangement |
|---|---|
| Scope | One room, two weeks, existing activity organizers |
| Owner | Caretaker, with a named backup before launch |
| Observe | Requests received, confirmations, discrepancies and unresolved questions |
| Access check | Telephone requesters can still complete a booking |
| Review | Compare the records and participant feedback at the end |
| Stop or revise | No reliable update owner, unclear confirmation or unresolved privacy requirement |
Do not use the two earlier overlaps as a statistically meaningful baseline for a percentage reduction. A short trial might have no conflicts because few requests occur. Record the number of requests as well as the number of problems, and explain the limits of the comparison.
A useful first result may be learning that the backup arrangement fails or that members interpret “pending” differently. That finding can improve the next version even if the initial idea is not adopted. Do not rewrite the original goal after seeing the outcome to make every result look successful.
Force field analysis versus a pros-and-cons list
A pros-and-cons list can compare attractive and unattractive features. Force field analysis asks what is currently helping or hindering movement toward one defined change. Its practical value comes from identifying where an action can alter the situation.
For example, “the new board is convenient” is a broad benefit. “The caretaker can maintain one confirmed record, but needs a backup during absence” points to a condition and an action. A SWOT analysis may help explore wider context, but it should not replace the change-specific map.
If the group is still generating possible solutions, use SCAMPER or brainwriting first. If the disagreement concerns motives inferred from limited behavior, the ladder of inference can separate evidence from interpretation before scoring forces.
Common mistakes to catch at the review
A vague center: If the proposal keeps changing, rewrite it and check every force again. A barrier to a permanent rollout may not apply in the same way to a two-week trial.
Scores without reasons: Keep the observation or assumption beside each rating. A large number without an explanation is difficult to challenge constructively.
Only strengthening drivers: More reminders may not fix missing ownership or access. Ask what would make the change easier before asking people to push harder.
No follow-through: Finish with owners, checks and a review date. Keep unresolved requirements visible. The useful artifact is a plan for changing conditions and learning from the result, not an impressive-looking balance of arrows.
Keep a record of the decision
At the review, retain the original proposal, the concerns raised, the actions actually completed and the observations from the trial. If a barrier remains unresolved, say who will investigate it and whether the trial can continue within its existing limits. Do not erase the earlier rating simply because the group has changed its view. A dated note explaining the change makes the map useful for the next discussion.
