10.2 Project Management: Needs, Gap, and Requirements

10.2 Project Management: Needs, Gap, and Requirements

Quick Answer: Task A.2 is needs analysis, gap analysis, and requirements. A need is the problem for a named stakeholder. A gap is current versus desired capability. Requirements are testable statements you can trace to design and test. MoSCoW ranks them. Safety, identity, and downtime continuity are Must—never Could used to save a date.

Section 10.1 put you in the analysis phase. Task A.2 is what that phase must produce before anyone is allowed to design an EHR upgrade, a medication-reconciliation rebuild, or an emergency-department tracker. CPHIMS will hand you a vice president who already named the product. Your job is to walk the request backward to a need, a measured gap, and a prioritized requirement set.

CPHIMS practice questionsPractice questions with detailed explanations

Why this sequence is scored

Projects fail when a solution is treated as a need. “We need a new medication-reconciliation module” is not a need. It is a shopping sentence. The need might be reliable capture of home medications at admission and a single reconciled list at discharge. The gap might be that home medications live in three systems and the admitting screen cannot show the outpatient list. The requirement might be that, at admission, the reconciling clinician can see the last outpatient medication list, document each item as continue/hold/stop, and produce a single list that pharmacy and nursing use.

If you skip to the module, you can spend a million dollars and still print paper lists at 02:00.

Exam stems mix three mistakes: collecting a wish list, copying a vendor feature catalog, and demoting a safety requirement so the date survives. Name which artifact is missing, then refuse the skip.

Needs analysis

A need answers: who has what problem, in what context, and what outcome would tell you the problem is smaller?

Write needs in stakeholder language, not in module names:

• Emergency department: patients leave before evaluation because door-to-disposition time is unpredictable when boarding hides true bed status.
• Hospitalists and pharmacists: admission medication lists are incomplete, so first inpatient doses do not match what the patient actually takes.
• Nursing: discharge teaching starts late because the after-visit summary cannot be generated until a physician closes a note that is not part of teaching.

Needs analysis is not a survey that asks “what features do you want?” It is observation plus interviews plus outcome data. Voice of the customer matters. Voice of the process matters too: timestamps, left-without-being-seen, incomplete admission reconciliation, first-dose delay. A loud stakeholder can describe a favorite screen. The process data tell you whether that screen would change the outcome.

Name the sponsor and the users. They are not always the same. A chief medical officer can sponsor a reconciliation project; night-shift admitting clinicians and pharmacists are still the users whose work-as-done you must watch.

Gap analysis

A gap is the difference between current capability and the desired state. It is not a complaint, and it is not a training slogan.

Good gap statements are specific:

• Current: home medications are retyped from a bag or a memory; the outpatient EHR list is not visible on the inpatient admission screen. Desired: the last maintained outpatient list is visible and each item is actioned. Gap: interoperability and screen design, not motivation.
• Current: the ED tracker shows roomed patients but not hallway boarders or incoming EMS. Desired: every patient in the department is visible with a next action. Gap: status model and data feed, not “nurses should look harder.”
• Current: downtime medication reconciliation is an unsigned binder in the charge-nurse office. Desired: a tested, role-based downtime kit with a recovery merge path. Gap: procedure, kit, and recovery design.

“Users need more training” is the exam’s favorite fake gap. Training is a valid intervention when people do not know a working path. It is not the gap when the path does not exist, when the data are in another system, or when the safe action takes fourteen minutes.

Gap analysis uses the visuals in section 10.4. You cannot declare a gap from a conference-room policy. You compare work-as-done with the intended future state.

Defining requirements

A requirement is a testable statement of what the system and the surrounding process must do. If you cannot write an acceptance test, you do not have a requirement. You have a wish.

Split what you hear into four buckets before you write the spec:

Write functional requirements (what the user can do) and non-functional requirements (performance, availability, security, audit, usability, interoperability). In HIT, non-functional is not optional polish. Audit logging, identity, response time on a sepsis order set, and a defined recovery time for downtime are requirements, not “IT preferences.”

Every requirement gets an identifier, a source (stakeholder, regulation, safety event, policy), an owner, and an acceptance test. Traceability is the chain need → requirement → design element → test case. When a stem says “we will figure out testing after go-live,” the chain is already broken.

Prioritizing with MoSCoW

MoSCoW is a prioritization method, not a personality test:

• Must — the release is a failure without it. Safety, identity, privacy, downtime continuity, and legally required record elements live here.
• Should — high value, painful to defer, but the release can still meet the stated need if a workaround is explicit and time-limited.
• Could — nice if capacity remains after Must and Should. Colors, extra reports, and convenience filters often live here.
• Won't (this time) — explicitly out of scope for this release, written down so it does not sneak back in as a “quick add.”

Must-have safety requirements stay Must. Two-identifier checks, allergy capture before ordering, dose-range validation for high-alert drugs, a tested downtime medication path, and audit trails are not bargaining chips. Demoting them to Could so an EHR upgrade date can hold is a requirements failure, not a schedule success.

Should is not a junk drawer for everything a chief asked for in a hallway. If a Should has no owner and no acceptance test, it is not a Should. It is noise.

Won't is a gift. Writing it down protects the team from silent scope creep and tells the sponsor what the next increment is for. A Won't that never gets a future home becomes a political ambush at go-live.

What is not a requirement

• A vendor feature list, including features inside a certified EHR
• A color, a logo, or a report someone saw at another hospital, until it maps to a need
• “Make it like our old system,” which is a constraint on change, not a specification
• “Be user friendly,” which is not testable until you define time-to-task, error rate, or completion
• A regulatory citation with no local behavior (“be HIPAA compliant”) until you name access, audit, minimum necessary, or transmission controls

Certified software can still fail a local need. Certification means a product met a national program. It does not mean your admission reconciliation gap is closed.

How to read a CPHIMS requirements stem

1. Separate the shopping sentence from the need.
2. Ask whether anyone measured the gap on the current path.
3. Ask whether the statement is testable.
4. Ask whether a safety, identity, or downtime item was demoted to protect a date.
5. Prefer the answer that restores need → gap → requirement → MoSCoW over the answer that issues an RFP first.

Scenarios and exam traps

Scenario — “we need a new med-rec module.” After a wrong-home-medication event, the CMO names a product. Informatics defines the need as complete home-medication capture and a single reconciled list at transitions, then measures how often the admission list is blank or retyped. The gap is visibility and handoff, not the absence of a brand name. An RFP can wait until those sentences exist.

Scenario — EHR upgrade wish list. Analysts collect 140 “requirements” that are really reports, theme colors, and copies of another hospital’s dashboard. Separate solution ideas from needs. Write testable requirements for the upgrade delta that affects ordering, results, and downtime. Apply MoSCoW. Do not rank every wish as Must to keep the room happy.

Scenario — safety as Could. Steering ranks two-factor authentication for remote e-prescribing and a downtime medication-reconciliation kit as Could so the upgrade weekend can hold. Those are Must. Slip the date or cut a Could report. Do not ship ordering without the identity and continuity controls the need implied.

Watch these traps:

1. Treating a module, screen, or vendor catalog as a need.
2. Declaring the gap to be training when the data or the path is missing.
3. Writing untestable slogans instead of acceptance criteria.
4. Demoting safety, identity, audit, or downtime to Should or Could to protect a date.
5. Copying certified feature lists into the spec without local mapping.
6. Having no Won't list, so every hallway request re-enters as Must.

Task A.2 ends when you can trace a need to a prioritized, testable requirement. Section 10.3 is how you improve the process those requirements sit inside.