A charter is the document that makes a project a project rather than an intention, and in a course that pairs role immersion with formal project management it is the artifact everything else hangs from. The territory here is scope with a written out-of-scope list, a named sponsor, stated decision rights, success criteria that can be measured, and the constraints you are accepting rather than wishing away. Charters are graded on precision, and the out-of-scope list is where precision is easiest to demonstrate and most often skipped. Your section may print this as NR 640B, NR640B or NR 640-B; 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-640B Week 3 asks for
What kills more informatics projects than bad technology? Undefined scope, by a wide margin. A project to standardize the depression screening workflow at one community clinic becomes, over three well-intentioned meetings, a project that also fixes the referral tracker, adds a language field to intake and revisits how the behavioral health team receives handoffs. Each addition was reasonable in the room. Together they guarantee that nothing finishes, and in an eight-week practicum nothing finishing is the difference between a completed course and an incomplete one.
So a charter does its most valuable work in the negative. The in-scope statement tells people what you will do; the out-of-scope statement is what actually protects the project, because it is the document you point at when a request arrives in week five. Writing four or five explicit exclusions, each phrased as a real thing somebody might reasonably ask for, is the single highest-value paragraph in the entire artifact and the one most students leave out.
Sponsorship is the second pillar. A sponsor is not an interested colleague, it is a role with the authority to release resources and to resolve disputes between the people whose work your project touches. The charter names that role, states what they have agreed to provide, and identifies who makes which decisions. In informatics that last piece is unusually important, because decisions about a build, a data definition and a clinical workflow frequently sit with three different governance bodies, and a charter that has not mapped them is describing a project nobody can approve.
Success criteria complete the frame. They should be checkable at the end of the session by somebody other than you, and they should distinguish deliverable completion from outcome improvement. Producing an approved standard operating procedure is a deliverable criterion. Reducing duplicate entry on one workflow is an outcome criterion. Practicum projects usually can promise the first and can only begin to demonstrate the second, and saying so honestly in the charter prevents an evaluation section that promises more than the timeline allows.
Where our help stops and your practicum begins
The practicum hours in this course are yours and cannot be delegated. We do not attend meetings, negotiate scope, speak to sponsors, contact your mentor, your informatics governance bodies or your organization, complete hours, or produce site documentation. Hour logs, activity records, mentor and preceptor evaluations, learning agreements and any signed or verified form are your own record, never drafted, reconstructed or estimated with our help. A charter that will be signed inside your organization is a real document you author and own.
What we work on is the writing: how a scope statement is bounded so it holds under pressure, how exclusions are phrased so they are usable, how decision rights are expressed without overstating what anyone has actually agreed to, how success criteria are made checkable, and how the whole artifact is proportioned so it reads as a professional document rather than a template with the blanks filled in.
The confidentiality rules run through this stage as everywhere else. Clients never appear in identifiable form. Sponsors and stakeholders appear by role rather than by name, which is also better project writing, because a charter that names an individual becomes stale the moment that person changes jobs. If your charter will be submitted academically as well as used internally, check what organizational detail you are permitted to include, and keep governance body names generic if there is any doubt.
The NR-640B Week 3 method, step by step
Six moves for writing a charter that will still be useful in week seven.
-
Write the problem statement forward from your current-state work
Population, frequency, consequence, drawn from what you actually observed rather than from the original idea. A charter whose problem statement does not match the evidence you gathered will be inconsistent for the rest of the session.
-
Draft the out-of-scope list before the in-scope list
Write down five things somebody will plausibly ask you to add, then exclude them explicitly. Working in this order forces you to define the boundary rather than discover it under pressure later.
-
Name the sponsor by role and state what they have agreed to
Staff time, access, a decision by a certain point, a slot on a governance agenda. Write only what has actually been agreed; an assumed commitment recorded as a fact is a fabrication risk and an operational trap.
-
Map the decisions to the bodies that own them
Data definitions, build changes, clinical workflow, training. List each decision your project needs, the role or committee that makes it, and how long that route typically takes. This is where informatics projects lose weeks.
-
Split success criteria into deliverable and outcome
Two short lists, clearly labeled, with a note on which can realistically be demonstrated inside the session and which would need longer. Honesty here protects your final evaluation section.
-
Record constraints and assumptions as separate items
A constraint is a fact you must work within, such as a release calendar. An assumption is something you believe and have not verified, such as staff availability for training. Confusing them is how a charter becomes optimistic without anyone noticing.
A layout and word budget for a project charter
Our frame for a charter of roughly 1,100 to 1,400 words. It is our own outline rather than anything the university issues, and your scoring guide outranks it wherever the two disagree.
| Section | What belongs in it | Word target |
|---|---|---|
| Problem statement | The workflow problem with population, frequency and consequence, traced to your current-state evidence. | 150 to 190 |
| Objective and deliverables | What the project will produce, listed as artifacts rather than as intentions. | 160 to 200 |
| In scope and out of scope | Both lists, with exclusions phrased as things a reasonable person might request. | 220 to 270 |
| Sponsor and decision rights | The sponsoring role, what has been agreed, and which body owns each decision the project needs. | 200 to 250 |
| Success criteria | Deliverable criteria and outcome criteria kept separate, each checkable by someone other than you. | 170 to 210 |
| Constraints and assumptions | Facts you must work within and beliefs you have not verified, listed under separate headings. | 170 to 210 |
Evidence craft for charter writing
Name the project management framework you are working within. Structured methodologies define what a charter contains and why, and citing one with its edition tells your reader which conventions you are following. It also stops you inventing sections that duplicate each other.
Keep the problem statement evidence-linked. Every quantity in it should trace to something you observed or extracted, with its base. Six of the twenty-two records reviewed carried the assessment in only one of the two required locations is a problem statement a sponsor can act on.
Write agreements in the voice of what was agreed. The nurse manager has agreed to release two staff for a one-hour session in the fourth week is precise. Staff will be available for training is a hope written in the future tense, and it will be tested.
Connect the project to organizational and regulatory context. Standards for interoperability, documentation and privacy shape what is possible, and a charter that references the relevant framework demonstrates that you understand the environment your build lives in rather than only the workflow it touches.
Five mistakes that cost points in this week's territory
- No out-of-scope list. The most common omission and the one that costs the most operationally, because without it every request is arguably in scope.
- A sponsor who is really a colleague. If the named role cannot release resources or settle a dispute, the project has enthusiasm rather than sponsorship.
- Success criteria only you could check. Improved workflow efficiency cannot be verified by anyone else and therefore cannot be evaluated at the end.
- Assumptions recorded as constraints. Dressing an unverified belief as a fixed fact hides the exact risk your risk register should be capturing.
- A charter that contradicts the current-state document. Written a week apart, they drift, and a grader reading both in sequence sees it immediately.
Before you submit
- The problem statement traces to evidence in your current-state work
- The out-of-scope list contains at least four concrete exclusions
- The sponsor is named by role with what they have actually agreed to
- Every decision the project needs is mapped to the body that owns it
- Deliverable and outcome success criteria appear under separate headings
- Constraints and assumptions are listed separately and correctly sorted
Writing the charter for your practicum project?
Send the scoring guide and your current-state findings. A premium original draft comes back in 24 to 48 hours with an out-of-scope list that will actually hold and success criteria somebody else could check, and revisions run until the grade lands.