Project boundaries and life cycle

Imagine a hospital trying to shorten appointment waits. Building a new booking service is a bounded piece of work; operating it after launch is repeated daily work. The former is a project, a temporary effort that creates a distinct result. The latter is operations. Changing a routine through a project does not turn every day of that routine into a new project. Related projects such as booking, automated reminders, and staff training may form a program when coordinated management produces a shared benefit that separate delivery would miss. A portfolio groups investments to advance organizational strategy and can include initiatives with no operational dependency. These distinctions tell us what to measure: a deliverable for the project, shared benefits for the program, and value and risk across the portfolio.

Start by identifying the problem, deliverable, and boundary, then select a life cycle. A predictive approach makes sense when requirements and sequence can be set early and late changes are expensive. An adaptive approach builds inspectable slices and uses feedback when users cannot specify the details yet. Neither label makes a team virtuous or careless. For booking, an integration with patient records may have fixed security specifications and prior approval, while the patient interface may benefit from iterative tests. Explain the boundary between these parts and who authorizes movement between them. Adaptive work still respects privacy and budget constraints.

Critique a scope statement by asking what will be delivered, to whom, how acceptance will be checked, and what is excluded. “Improve patient experience” is an aim, not an adequate scope boundary. A more testable statement is: “Enable outpatient patients to book or cancel available appointments and receive confirmation within one minute in Arabic and English; billing is excluded from this release.” The channels and confirmation can be checked; billing cannot slip in without a change decision. If a one-minute promise depends on an external message provider, separate the system's processing time from actual message delivery and agree on a realistic criterion.

Four descriptions often get confused. A risk is an uncertain future event that might affect an objective: the messaging provider may deliver its interface late. An issue is a present fact requiring action: the interface failed today's test. An assumption is a proposition provisionally used for planning: a test interface will be available next week. A constraint limits choices: patient information may not leave the approved environment. An untested assumption may expose a risk; a realized risk becomes an issue. Record the date, owner, and trigger for changing classification. Do not put every inconvenience in the risk register.

A project is a vehicle for change, not merely a software handoff. Trace the benefit: online booking reduces manual calls only if patients adopt it and staff can handle exceptions. If the team delivers the screen on time but most calls remain manual, delivery has occurred while the benefit is still unproven. Set a baseline, say 900 booking calls per week, and a post-launch measure such as self-service share. Check other changes before attributing a decline to the screen. Plan the transition owner; otherwise project closure may expose an unsupported service.

Apply professional conduct to a decision rather than memorizing an ethics slogan. Suppose a supplier tells the project manager a data protection test failed but suggests delaying the report. Concealment would leave the launch decision based on incomplete information. Record the observed failure, establish its effect, report through the agreed route, and never represent the test as passed. This is not a universal legal conclusion about privacy: exact obligations depend on context. Professional responsibility and honesty support accurate reporting, while a technical compliance conclusion needs test evidence and organizational policy.