The work breakdown is the artifact that turns a charter into something a team can execute, and it is where project management technique becomes visible or fails to. The territory is decomposition and sequence: breaking deliverables into tasks somebody could actually be assigned, estimating them honestly, and ordering them so dependencies are explicit rather than discovered. In a course pairing informatics immersion with formal project management, this is the document most likely to be scored against a technical standard rather than a stylistic one. 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 4 asks for
How do you know a task is small enough? A working test used across project practice is whether you could hand it to one person, describe it in a sentence, and recognize unambiguously when it is finished. Build the training materials fails that test at a clinic where training materials means a one-page reference card, a five-minute huddle script and a screen-by-screen guide for the two staff who will do the entry. Three tasks, three owners, three definitions of done. Decomposing to that level is the graded skill, and it is the difference between a plan and a wish.
The second demand is dependency logic. Tasks do not merely follow one another in time, they enable one another, and the distinction matters because it determines what happens when something slips. If the data definition must be agreed before the report specification can be written, that is a hard dependency and a delay in the first moves the second by the same amount. If training could theoretically happen before or after the reference card is printed, that is a preference rather than a dependency. Writing which is which is what lets a reader see where your project is actually fragile.
Estimation is the third element, and honesty here is a professional habit rather than a technique. Informatics tasks in clinical settings are dominated not by the work itself but by waiting: for a governance agenda, for a build queue, for a manager to find two staff who can leave the floor at the same time. An estimate that counts only hands-on effort will be wrong by a factor that embarrasses the plan in week six. Separating effort from elapsed duration, and saying which queue each task sits in, is what makes a practicum schedule survive contact with a real organization.
Finally, this stage usually asks you to identify the critical path, at least informally. In a project of twenty tasks, a handful determine the finish date and the rest have slack. Naming that chain tells your sponsor where attention should go and tells your grader that you understand sequencing as more than a list in date order.
Where our help stops and your practicum begins
Your 72 practicum hours belong to you, and so does every record your school or site verifies. We do not attend meetings, perform project tasks, contact your mentor, your build team or your organization, complete hours, or produce site documentation. Hour logs, activity records, mentor and preceptor evaluations, learning agreements and anything carrying a signature or verification field are your own record and are never drafted, reconstructed or estimated with our help. We also cannot estimate the real durations at your site, because only somebody inside the organization knows how long its queues run.
What we work on is the written layer: how a work breakdown is structured so it decomposes cleanly, how a task is worded so its completion is unambiguous, how dependencies are expressed in prose rather than only in a chart, how a schedule narrative explains the logic behind the sequence, and how the document stays consistent with the charter that preceded it.
Confidentiality applies here even though the content is administrative. Clients never appear. Staff appear as roles, which is also better project practice, since a task assigned to a role survives a resignation and a task assigned to a person does not. Where a task involves a vendor, a contract or an internal system name that your organization treats as sensitive, describe it functionally rather than naming it, and check what may be included before an academic submission leaves your hands.
The NR-640B Week 4 method, step by step
Six moves for building a work breakdown that will hold up in week seven.
-
Decompose from deliverables, never from time
Start with the artifacts your charter promised and break each into the work required to produce it. Building a plan by asking what happens in week five produces tasks that fit the calendar rather than the deliverable.
-
Apply the one-person, one-sentence, one-finish test to every task
If a task needs two owners or two definitions of done, split it. Oversized tasks are where projects hide the work they have not thought about yet.
-
Write a completion criterion for each task in the task itself
Not draft the procedure but draft the procedure and obtain written comment from the clinic manager. A task whose finish is a matter of opinion will be disputed at exactly the wrong moment.
-
Record effort and elapsed duration in separate columns
Three hours of work sitting in a two-week governance queue is a different planning object from a three-hour task you can start tomorrow, and merging them is why practicum schedules fail.
-
Mark hard dependencies and label the reason
Cannot start until the data definition is agreed. Cannot test until the training group exists. A dependency with its reason attached can be challenged and sometimes removed; an unexplained arrow cannot.
-
Trace the longest chain and name it as the critical path
Then write one paragraph on what protects it: which task you would start early, which approval you would chase first, and what you would drop if the chain slipped by a week.
A layout and word budget for a work breakdown and schedule narrative
Our frame for a sequencing document of roughly 1,000 to 1,300 words alongside the breakdown itself. 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 |
|---|---|---|
| Decomposition logic | How the deliverables were broken down and at what level you stopped, with the rule you applied. | 140 to 180 |
| Task inventory narrative | The groups of work in sequence, each with its owner role and completion criterion, complementing the table. | 280 to 340 |
| Effort and duration | How estimates were derived, and which tasks are dominated by waiting rather than by work. | 170 to 210 |
| Dependencies | Each hard dependency with the reason it exists and what would be needed to break it. | 190 to 240 |
| Critical path | The chain that determines the finish date, and what you are doing to protect it. | 150 to 190 |
| Schedule risk | The two or three tasks most likely to slip, with the early warning sign for each. | 140 to 180 |
Evidence craft for planning documents
Cite the decomposition standard you followed. Project management bodies publish conventions for work breakdown structures, including how far to decompose and how to label levels. Naming the source with its edition shows you are applying a method rather than improvising a list.
Derive estimates from something and say what. A comparable task at the same site, a stated queue length, your mentor's experience of similar requests. An estimate with a stated basis can be defended and improved; a number with no origin is a guess your plan depends on.
Keep the narrative and the chart doing different work. The chart carries sequence and dates. The prose carries why the order is what it is and what would happen if it changed. Describing your own chart row by row wastes the section.
Say plainly which tasks fall outside the session. Many practicum projects legitimately extend beyond eight weeks, and marking those tasks as belonging to a later phase is far stronger than compressing them into a timeline that could never have held.
Five mistakes that cost points in this week's territory
- Tasks that are really phases. Implement the change is not a task; it is four tasks with three owners hiding behind one verb.
- A schedule with no waiting in it. Plans that assume every approval arrives on request are the recognizable mark of somebody who has not worked inside a governance process.
- Dependencies drawn without reasons. Unexplained sequence cannot be challenged, and half of it is usually habit rather than necessity.
- A breakdown that contradicts the charter. Tasks appearing for deliverables the charter excluded is scope creep visible in the documents themselves.
- No critical path identified. Without it, a reader cannot tell which slippage matters and which does not, and neither can you.
Before you submit
- Every task passes the one-person, one-sentence, one-finish test
- Each task carries an owner role and a completion criterion
- Effort and elapsed duration appear separately
- Each hard dependency states the reason it exists
- The critical path is named with a paragraph on protecting it
- Every task maps to a deliverable the charter actually promised
Building the work breakdown for your project?
Send the scoring guide and your charter. A premium original draft comes back in 24 to 48 hours with tasks decomposed to an assignable level and dependencies stated with their reasons, and revisions run until the grade lands.