The seventh stage is where the separate pieces of the session get assembled into a designed program, and the instrument that does the assembling is a logic model. Resources produce activities, activities produce outputs, outputs produce short-term changes, and those produce the population outcome you have been tracking since the first stage. The doctoral demand is that every arrow in that sequence be defensible: an assumption you can name, an evidence base you can cite, or a condition you can state. Your section may print this as NR 704 or NR704; it is the same course. Chamberlain publishes no syllabi outside Canvas. The placement here is our teaching judgment from the course's catalog arc; your section's rubric decides what your week actually asks.
What NR-704 Week 7 asks for
The most useful hour we ever spend with a student at this stage is the one where we make them read their own logic model backwards. Start at the population outcome, and ask of each preceding box: is this genuinely sufficient to produce the next one. A model that reads plausibly left to right often falls apart travelling right to left. Four education sessions delivered to charge nurses at a long-term care campus is an output. It is not sufficient to produce a change in how a medication reconciliation happens at transfer, because nothing between those two boxes ensures the behaviour is triggered, supported or noticed. The missing box is usually a change in a workflow, a prompt or an accountability, and finding it is the entire value of building the model.
The territory of this stage is program design for populations: taking the burden you quantified, the determinants you mapped, and the preventive best practice you appraised, and organizing them into an intervention with a stated theory of change. Deliverables at this depth are typically a written program plan, often accompanied by a logic model diagram or table, and sometimes an implementation timeline. Where a discussion runs alongside, it often asks you to critique a peer's model, which is genuinely useful practice and, as always, posts do not reopen once submitted in Canvas.
Two doctoral disciplines belong here. The first is the distinction between an activity and an outcome. Delivering training, distributing a tool and holding meetings are activities; they belong on the left of the model and never on the right, and models that place them among outcomes have confused effort with effect. The second is stating assumptions as assumptions. Every model rests on beliefs about staff capacity, competing priorities, data availability and organizational stability, and a model that lists those explicitly is more credible than one that appears to have none.
Keep the practice-doctorate frame steady while you design. You are translating existing evidence into a delivery system for a defined population, not testing a hypothesis. The logic model's purpose is to make the translation inspectable so that other people can find its weak arrow before implementation does. Written that way, it is a working document rather than an academic ornament, and it reads as such to a grader.
The NR-704 Week 7 method, step by step
Six moves for building a defensible program logic on paper.
-
Reduce the rubric rows to verbs and check whether a figure is required
Design, justify and align each ask for different work, and an alignment row usually means the model must connect visibly to the problem statement and outcome you established earlier in the session.
-
Write the outcome column first and work leftwards
Begin at the population outcome, then ask what short-term change must precede it, then what output produces that change, then what activity produces the output. Building right to left prevents the most common structural failure in these models.
-
Test every arrow for sufficiency
For each pair of adjacent boxes ask whether the left one alone could produce the right one. Where the answer is no, insert the missing box rather than widening the arrow. Missing boxes are usually workflow triggers, accountability or feedback.
-
Distinguish outputs from outcomes in the wording itself
Outputs are counted: sessions held, tools distributed, assessments completed. Outcomes are changes in state: proportions reconciled, rates of events, functional status. Use countable nouns on the left and rates on the right and the distinction enforces itself.
-
Attach an evidence citation or an explicit assumption to each arrow
Some links are supported by literature and should carry the citation in the narrative. Others rest on local judgment and should be labelled as assumptions. A model where every link looks equally evidenced is less credible than one that admits the difference.
-
Name the resources honestly, including the ones you do not control
Staff minutes, access to a report, a committee's approval, a data extract someone else has to run. Inputs a project cannot secure are the most common reason program plans stall, and naming them is design work rather than pessimism.
A layout and word budget for a program design paper
The frame our tutors keep beside a program plan and logic model submission, sized for roughly 1,500 to 1,800 words plus the model itself. It is our own outline rather than anything the university issues, and your week's rubric outranks it wherever the two disagree.
| Section | What belongs in it | Word target |
|---|---|---|
| Problem restated as a gap | The population, the outcome, the current rate and the achievable rate, expressed as the distance between them. | 150 to 190 |
| Theory of change | One paragraph saying, in plain sentences, why this program should move that gap and through which mechanism. | 190 to 240 |
| Inputs and activities | Resources including staff minutes and approvals, then the specific activities with their frequency and owner. | 260 to 320 |
| Outputs and short-term change | What will be countable, and the behavioral or process change each output is expected to produce. | 240 to 300 |
| Outcomes and the arrow tests | The population outcome, the intermediate outcomes, and an explicit walk through the weakest arrow in the chain. | 280 to 340 |
| Assumptions and threats | The beliefs the model rests on, plus the two conditions that would most plausibly break it. | 200 to 250 |
Evidence craft for program design writing
Cite the mechanism, not the program name. Where the literature supports a link in your model, cite the study that supports that specific link rather than a general endorsement of a similar program. A citation attached to the wrong arrow is worse than no citation, because it looks like support and is not.
Quantify the gap in the same units as the outcome. If your outcome is a rate per 1,000 resident-days, the current level, the achievable level and the target should all be expressed that way. Mixing counts, proportions and rates across the design makes the model impossible to evaluate later.
Distinguish an adaptation from a deviation. When you modify an evidence-based approach to fit your setting, say which component you changed, why, and whether the change touches the active mechanism. Adapting delivery format is usually safe; adapting dose or the responsible role often is not, and a doctoral reader will want to see that you know the difference.
Write assumptions in falsifiable language. Staff will have time is not an assumption anyone can check. Charge nurses have approximately ten uninterrupted minutes during the afternoon handoff window is an assumption that can be observed and disproved, and it makes the rest of the model honest.
Five mistakes that cost points in this week's territory
- Training listed as an outcome. Sessions delivered is an output, and placing it in the outcome column tells a grader the model's grammar is not yet understood.
- An arrow that leaps. A tool distributed does not produce a change in a rate on its own; the boxes between them are where the real design work lives.
- No assumptions section. A model with no stated assumptions reads as one whose assumptions have not been examined rather than one that has none.
- Unowned activities. Every activity needs a named role attached, because activities belonging to everyone in general belong to nobody at the point of delivery.
- A program disconnected from earlier work. If the design does not visibly address the determinant and the failure point you established earlier in the session, the alignment row is lost.
Before you submit
- The model was built from the outcome leftwards and reads coherently in both directions
- Outputs are countable nouns and outcomes are rates or proportions
- Every arrow carries either a citation or a labelled assumption
- Each activity has a named owner and a stated frequency
- Inputs include the approvals and data access you do not personally control
- The weakest arrow is identified and discussed rather than hidden
Designing your NR-704 program plan?
Send the rubric and your earlier submissions out of Canvas. A premium original draft comes back in 24 to 48 hours with a logic model built backwards from the outcome and every arrow tested for sufficiency, and revisions run until the grade lands.