Scope is the discipline of writing down what the project will not do. A doctoral design document should state its population, its setting boundary, its time window, the part of the workflow it touches and the things it deliberately leaves alone, in language specific enough that somebody could tell whether a new idea belongs inside it. Most projects that stall did so because scope was never written, only assumed. Your section may print this as NR 730 or NR730; 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-730 Week 3 asks for
Watch what happens to an unscoped project in an intensive care unit. It starts as a delirium screening improvement on one twelve-bed pod. A physician suggests adding sedation interruption, because the two are related and he is right that they are. The pharmacist offers to include a medication review, which would be valuable. The educator proposes a simulation refresher for new nurses, which everyone agrees is needed. Six weeks later the project has four interventions, three data sources, no clear outcome and a doctoral student who cannot say what she is evaluating. Nothing unreasonable happened at any single step. What was missing was a written boundary that made each addition a decision rather than a courtesy.
The written work at this stage typically involves a scope statement, an inclusion and exclusion definition, and a feasibility analysis. Inclusion and exclusion criteria are worth particular care because they do double duty: they define who the project touches, and they define who the data will describe. A project on early escalation that includes every admitted patient will drown in denominators. One that includes adult telemetry admissions with a documented early warning score during the study window is workable, and the criteria themselves have become part of the design.
Feasibility at this stage is not a paragraph of optimism. It is an inventory of dependencies: data access, sponsorship, the people whose behavior must change, technology that would need configuration, education time that would need scheduling, and the calendar. Doctoral readers are experienced at spotting the dependency a student has not noticed, usually an electronic record change or an approval body that meets monthly. Writing the dependencies out is how you find them before they find you.
Expect a deliverable that mixes prose with defined criteria, possibly as part of a growing design document. Whatever the shape, this is the stage where a navigator conversation most often narrows a project, and narrowing is progress rather than loss. If a discussion runs alongside, post the exclusion you found hardest to accept and why you accepted it, and write it as final copy since posts do not reopen after submission in Canvas.
The NR-730 Week 3 method, step by step
Seven moves for setting a boundary that holds under pressure.
-
Split the rubric into definition rows and justification rows
Stating scope is quick. Defending each boundary against the alternatives is where the marks concentrate. Find out which rows expect a rationale before you allocate words to describing your setting again.
-
Write the population with criteria a stranger could apply
Adults admitted to the telemetry unit, aged 18 and over, with a length of stay beyond 24 hours, excluding comfort-care admissions and direct transfers from the operating room. Every criterion should be checkable from a record without judgment.
-
Justify each exclusion in a clause
Exclusions are analytic decisions, not conveniences. Say why: comfort-care admissions are excluded because escalation is not the appropriate response, not because they complicate the data. A reviewer will ask, and the clause answers it in advance.
-
Draw the workflow boundary explicitly
Name where the project starts and stops in the sequence of care: from the moment a qualifying observation is documented to the moment the escalation is acknowledged, and nothing after that. Workflow boundaries are what prevent well-meant scope creep.
-
Write the out-of-scope list as a real list
Three to six items naming things people will suggest and you will decline: staffing ratios, the electronic record's alert logic, the rapid response team's structure. This list is the single most useful paragraph you will write for your own sanity later.
-
Inventory dependencies and name their owners
For each dependency, say what is needed, who controls it, how long approval typically takes and what you will do if it is refused. A project depending on an approval body that meets quarterly has a timeline problem that must be visible now.
-
Lay the project against a calendar and see whether it fits
Preparation, education, implementation, data collection and analysis, each with a duration. If the arithmetic does not fit inside the terms available, shrink the intervention or shorten the measurement window deliberately rather than discovering the collision later.
A layout and word budget for a scope and feasibility section
Our frame for scope with a feasibility analysis, sized for roughly 1,100 to 1,400 words. 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 |
|---|---|---|
| Scope statement | What the project will change, for whom, where, and across what window, in one paragraph. | 110 to 150 |
| Inclusion and exclusion criteria | Criteria a stranger could apply from a record, each exclusion carrying its reason. | 200 to 260 |
| Workflow boundary | The start and end points in the care sequence that the project touches. | 150 to 200 |
| Explicitly out of scope | The named things the project will not attempt, with a sentence on why each stays out. | 160 to 210 |
| Dependency inventory | Data, sponsorship, technology, education time and approvals, each with an owner and a lead time. | 250 to 320 |
| Timeline test | The phases with durations, against the terms available, and what gets cut if the fit is tight. | 200 to 260 |
Evidence craft for scope writing
Base your criteria on something published where you can. If a guideline defines the population for which an intervention is recommended, use that definition and cite it. Criteria that mirror the evidence base make the later argument for the intervention much easier to sustain.
Size the population before you commit to it. Say roughly how many patients or events the criteria will produce in your window, from actual volume figures. A project whose criteria yield eleven eligible patients per month has a measurement problem that scope work is supposed to catch.
Describe approvals as processes, not outcomes. Write that a determination will be sought from the relevant review body, describe the route and the typical timeline, and stop there. Predicting the decision is a claim you cannot support, and the same applies to site agreements that are still being discussed.
Distinguish assumptions from facts in the dependency list. If you believe the informatics team can build a report but have not asked, label it as an assumption with a date by which it will be confirmed. Assumptions are acceptable; unlabelled assumptions are what make a feasibility section unreliable.
Do not describe hours, logs or site paperwork as project content. Whatever clinical or practicum hours accompany your program are your own record and your site's, verified by them and never drafted, reconstructed or estimated with help. The design document covers the written and analytic work: scope, criteria, dependencies, timeline.
Five mistakes that cost points in this week's territory
- Criteria that require judgment. Patients at risk of deterioration cannot be applied consistently by anyone, which means the population is undefined no matter how it reads.
- No out-of-scope list. Without one, every good suggestion becomes an addition, and by the fourth addition the project has no evaluable outcome.
- Feasibility as reassurance. A paragraph saying the project is achievable with support from leadership names nothing, owns nothing and predicts nothing.
- A timeline with no phase durations. Projects fail on the calendar more often than on the design, and a timeline that is not tested against the terms available is decorative.
- Predicting an approval. Stating that the project will be determined to be quality improvement claims a decision that belongs to someone else.
Before you submit
- Inclusion and exclusion criteria could be applied by a stranger from a record
- Every exclusion carries a stated reason
- The workflow boundary names a start point and an end point
- An explicit out-of-scope list appears with reasons
- Each dependency has an owner, a lead time and a fallback
- The phase durations have been added up and tested against the terms available
Scoping your project for NR-730?
Send the rubric and your concept out of Canvas. A premium original draft comes back in 24 to 48 hours with criteria a stranger could apply and dependencies named with owners, and revisions run until the grade lands.