NR-720 · Week 3 of 8 · Locating a problem at systems altitude

NR-720 Week 3 Finding Systems Altitude: How to Write It

The short answer

Every organizational problem can be described at several altitudes, and the altitude you choose determines which solutions are even visible. This stage of NR-720 typically asks you to take a problem that is being managed locally and analyze it as a system: where the constraint actually sits, which parts interact, and why local effort has not fixed it. The graded idea is that a system produces its results reliably, so a problem that keeps returning is being generated rather than merely occurring. Your section may print this as NR 720 or NR720; 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.

NR-720 Week 3 grading scale at Chamberlain, the criterion levels this assessment is scored on, from Chamberlain Tutors
How Chamberlain grades NR-720 Week 3, visualized by Chamberlain Tutors.

What NR-720 Week 3 asks for

Three medical-surgical units were each running their own discharge improvement effort, and all three were working. Discharge orders were being written earlier, education was being completed the day before, and each unit could show its own progress. Average time from discharge order to bed available had not moved in eighteen months. Mapping the whole path explained it in an afternoon: the constraint was a transport pool sized for a mid-morning peak that no longer existed, and a discharge lounge with four chairs and no clinical cover after 1600. Every hour the units gained upstream arrived at the same choke point and waited there. Nobody on any of the three units could see it, because each of them was measuring the part of the path they owned, and each part was improving.

That is the analytic content of this stage. The written work usually asks for a systems-level problem analysis, sometimes using a named systems thinking, process mapping or constraint framework, sometimes as a root cause analysis raised above the unit. What is being scored is whether you can locate the constraint rather than the symptom, and whether you can show the interactions that produce the result.

Doctoral treatment demands three things beyond a good diagram. It demands data at each stage of the path, so the constraint is demonstrated rather than asserted. It demands attention to the measurement system itself, because problems persist in organizations that measure parts rather than wholes, and that observation is often the most valuable thing in the paper. And it demands the leadership implication: which decisions belong to which level, and what a senior leader has to do that a unit manager cannot.

Keep the practice-doctorate frame visible. You are applying established systems and improvement methods to a local problem in order to produce a change, not investigating whether those methods work. Write in that register and the analysis stays on the right side of the line between improvement and research.

The NR-720 Week 3 method, step by step

Six moves for raising a problem to the level where it can be solved.

  1. Trace the whole path end to end

    From the first triggering event to the final outcome, across every department it passes through, including the waits between steps. Most systems problems live in the handoffs, which are precisely the parts no single manager owns or measures.

  2. Attach elapsed time and volume to every step

    A map without numbers is a picture. Use timestamps the record already produces, name the report they come from, and give each step a median and a spread rather than an average alone, because variability is often the real problem.

  3. Locate the constraint and prove it

    The constraint is the step where work accumulates and whose capacity sets the pace of the whole path. Show the queue, show that improvements upstream do not move the result, and say what would happen if the constraint were relieved.

  4. Examine what each part is measured on

    Local optimization is usually rational behaviour under local measurement. Write what each department is scored on and show where those measures pull against the outcome you care about, because that is a systems finding a senior leader can act on immediately.

  5. Identify the feedback loops that hold the pattern in place

    Delays that create rework, workarounds that hide the problem from the people who could fix it, or a surge response that consumes the capacity needed to prevent the next surge. Naming one real loop is worth more than a page of general systems vocabulary.

  6. Assign each implication to a decision level

    Say which findings a unit manager can act on, which need a service line, and which require executive authority over capital or staffing. That assignment is the bridge from analysis to leadership and it is what makes the paper belong in this course.

A layout and word budget for a systems problem analysis

Our frame for this stage, sized for roughly 1,300 to 1,600 words, with a process map or stage table carrying the path detail. This outline is ours rather than anything the university issues, and your week's rubric outranks it wherever the two disagree.

SectionWhat belongs in itWord target
The result being producedThe outcome as the system currently delivers it, measured, with its source and period.150 to 190
The path, stage by stageEvery step and handoff with elapsed time, volume and variability, and the departments each belongs to.280 to 340
The constraint, demonstratedWhere work accumulates, the evidence that it sets the pace, and what relieving it would change.230 to 280
Measurement misalignmentWhat each part is scored on and where those incentives pull against the whole-path outcome.200 to 250
Loops that sustain itOne or two real feedback mechanisms that return the system to its current behaviour.180 to 220
Decisions by levelWhat belongs to the unit, the service line and the executive, with the reason for each assignment.200 to 250

Evidence craft for systems analysis

Cite the systems or improvement method you are using. Constraint theory, lean and value stream methods, systems thinking archetypes and improvement science models are published bodies of work. Name the one you are applying, with its source and year, and use its actual terms rather than a loose paraphrase.

Take timings from the record, not from recollection. Order timestamps, bed management logs, transport dispatch records and discharge times exist and are retrievable. A path built from what staff estimate is a hypothesis, and it should be labelled as one if that is all you have.

Report spread, not only central tendency. A median wait of 40 minutes with a tail reaching four hours is a different problem from a consistent 40 minutes, and the tail is usually where the patients and the complaints are. Executive readers act on the tail.

Compare against a defensible reference. Your own historical performance, another site in the same organization, or a published benchmark with its source named. Avoid inventing a target; if no benchmark exists, say what would count as acceptable and on what reasoning.

Keep departments described by function, not by fault. Transport capacity is sized to a demand pattern that has shifted is analysis. Transport is unreliable is a complaint, and it produces no design change.

Five mistakes that cost points in this week's territory

  • A symptom analyzed as a cause. Late discharges are a result; the question is which step in the path produces them and why it persists.
  • A map with no data. Boxes and arrows without elapsed times cannot locate a constraint and cannot support a recommendation.
  • Systems vocabulary without a mechanism. Words like complexity and interdependence do no work unless a specific loop or constraint is named.
  • Ignoring the measurement system. Most persistent problems are held in place by what each part is scored on, and papers that skip this miss the highest-yield finding.
  • Every recommendation aimed at the unit. If the analysis found a systems constraint and the recommendations are all local, the paper has argued against itself.

Before you submit

  • The whole path is traced across departments, including handoffs and waits
  • Every stage carries elapsed time and volume from a named record
  • The constraint is demonstrated with evidence rather than asserted
  • Spread and tail behaviour are reported, not just averages
  • What each part is measured on appears in the analysis
  • The systems or improvement method is cited with its source and year
  • Recommendations are assigned to the decision level that can act on them

Building the systems analysis for NR-720?

Send the rubric and your process data out of Canvas. A premium original draft comes back in 24 to 48 hours with the constraint demonstrated, the measurement misalignment named and recommendations sorted by decision level, and revisions run until the grade lands.

Questions students ask about this stage

I cannot get access to the data for every step. What then?
Build the path with what you can obtain, mark the gaps explicitly, and write what each missing figure would settle. That is closer to how these analyses are actually done than the complete dataset students imagine. In most organizations the first and last timestamps of a process are easy to get and the middle is opaque, so a common and legitimate approach is to establish the total, establish the two or three steps you can measure, and then reason about the remainder as a residual with the uncertainty stated. Naming who holds the missing data and what you would ask them for is part of the analysis, not an admission of weakness, because obtaining cross-departmental data is itself a leadership task at this altitude. What you must not do is estimate a number and present it as measured, since a single invented figure calls the whole path into question.
How is this different from a root cause analysis?
Root cause analysis typically starts from a single event and works backwards to the conditions that allowed it, and it is usually conducted for an event that should not have happened. A systems analysis at this altitude starts from a persistent result the organization produces routinely and asks what structure generates it. The distinction matters for how you write. Event analysis looks for the sequence and the barriers that failed; systems analysis looks for capacity, flow, incentives and feedback. There is also a difference in what counts as a finding: a root cause analysis can legitimately end with a contributing factor and a corrective action, whereas this course expects you to end with the structural condition and a decision assigned to a level of the organization. If your paper reads as an event investigation, the usual fix is to widen the frame from one occurrence to the pattern of occurrences and re-ask the question.
What if the constraint turns out to be something nobody can change?
Then you have a genuinely useful finding, and the analysis moves to designing around it rather than through it. Some constraints are fixed within any realistic horizon: a building's physical layout, a regional shortage of a specific clinical specialty, a payer's rule, an information system's release schedule. When the constraint is immovable, the productive questions become whether demand can be shifted away from it, whether work arriving at it can be sequenced better, whether some of the work can be done elsewhere, and whether the organization should stop absorbing the cost invisibly and make it a stated limit instead. Writing that last option honestly is a mark of executive-level analysis, because senior leaders sometimes need to hear that a target is unachievable with the current structure and that the choice is between investment and a revised expectation.

Keep going

Online now