PMI CD-P key terms

The practice of stating a business need in terms of affected users, current pain, measurable impact, and desired outcome before any tool is chosen, so that solutions are judged against the problem rather than against feature lists.

A structured phase of interviews, observation, and data review that uncovers how work is actually done today, who is affected, and which constraints are real, producing evidence rather than assumptions before building begins.

A short written statement describing the specific gap between current and desired performance, who experiences it, and how success will be measured, used to keep scope anchored throughout delivery.

A technique such as the five whys or a fishbone diagram that traces a visible symptom back to underlying process, data, or role causes, preventing teams from automating a defect rather than fixing it.

Identifying everyone who influences or is affected by a solution, recording their interests, influence, and concerns, so engagement and communication effort is directed where it changes outcomes.

Agreed, measurable conditions that define whether a delivered solution solved the framed problem, such as cycle-time reduction, error rate, or adoption level, set before build so evaluation is objective.

The accountable leader who funds and champions an initiative, resolves escalations, and confirms that the delivered outcome meets the business need, distinct from the day-to-day product owner role.

The smallest release that delivers real value to a defined user group and generates learning, used to validate assumptions early instead of building a full feature set before any feedback arrives.

A business-side practitioner who builds applications or automations with sanctioned low-code or no-code tools, typically within a governed environment and without holding a formal software engineering role.

A development environment offering visual modeling, prebuilt components, and declarative configuration, with the option to extend through code, so builders deliver working applications faster than fully hand-coded approaches.

A toolset where applications are assembled entirely through configuration, forms, and visual logic with no programming, trading flexibility and fine control for speed and accessibility to non-technical builders.

A central team that sets standards, curates reusable components, provides coaching, and reviews higher-risk builds, enabling many distributed makers to work consistently without duplicating governance effort.

A blended group pairing business subject-matter experts with IT professionals so that domain knowledge and technical rigor are applied together, reducing handoff delays and rework during delivery.

The rules, roles, and technical controls that determine who may build what, which data and connectors are permitted, and how environments are separated, keeping distributed development safe and auditable.

A planned separation of development, test, and production workspaces with controlled promotion paths, so changes are validated before they reach live users and production data stays protected.

A prebuilt integration component that lets an application read from or write to an external system such as a database, ticketing tool, or file store, often carrying its own authentication and throttling behavior.

A shared building block, such as a form template, approval flow, or connector configuration, published for repeated use so teams avoid rebuilding the same logic and inherit vetted standards.

The distinction between the person who builds and maintains an application and the person who operates it in daily work; confusing the two leads to interfaces tuned to the builder rather than the worker.

A concise profile of a representative user group capturing goals, context, frequency of use, and constraints, used to justify design choices and to test whether the interface serves real working conditions.

The defined entities, attributes, and relationships that structure stored information, determining what the application can report, how duplicates arise, and how easily the design can change later.

Organizing data so each fact is stored once in the appropriate table, reducing duplication and conflicting updates that otherwise cause unreliable reports and hard-to-trace defects.

A rule ensuring that a record pointing to another record references one that exists, preventing orphaned entries and broken relationships when records are deleted or merged.

Granting permissions through assigned roles rather than to individuals, so access reflects job need, is auditable, and can be updated consistently when people change positions.

The principle that each user, service account, and application receives only the access strictly required for its function, limiting the scope of mistakes and the blast radius of a compromise.

Designing workflows so that no single person can both initiate and approve a sensitive action, such as creating a vendor and releasing its payment, which reduces fraud and undetected error.

Shaping screens, labels, defaults, and interaction flow around how real users complete tasks, including error prevention and clear feedback, so adoption is not undermined by friction.

Designing applications so people with visual, motor, auditory, or cognitive differences can perceive and operate them, covering contrast, keyboard navigation, labels, and assistive-technology compatibility.

A defined interface through which one system requests data or actions from another, with documented inputs, outputs, authentication, and limits that shape how an application can integrate safely.

A cap on how many requests an interface or service accepts in a period, which a well-designed application respects through retries and queuing to avoid failures under load.

Planned behavior when an action fails, including clear user messages, logging, safe rollback, and retry rules, so failures are visible and recoverable rather than silently corrupting records.

A documented set of preconditions, inputs, and expected results for one scenario, written so a reviewer can confirm whether the application behaves correctly and repeat the check after changes.

Business users executing realistic scenarios against a candidate release to confirm it meets agreed needs, producing formal sign-off before the application is promoted to production.

Re-running a defined set of checks after a change to confirm previously working behavior still works, which is essential when shared components or data models are modified.

An automated or scripted sequence that moves a solution from development through testing into production with recorded approvals, replacing manual copying and reducing release errors.

A prepared method for restoring the prior working state if a release fails, including backups, version history, and decision authority, agreed before deployment rather than improvised during an incident.

Evaluating a proposed application for data sensitivity, user population, financial or regulatory impact, and integration reach, to assign the review depth and controls its risk level warrants.

Classifying applications into risk bands that each carry defined requirements for review, testing, documentation, and monitoring, so governance effort is proportionate rather than uniform.

Rules restricting which data classifications may be stored, shared, or sent to external services, enforced through platform settings and connector approvals to prevent leaks of sensitive information.

The defined process for reporting, triaging, containing, and learning from application failures or data issues, including named owners and communication paths between business and IT.

Confirming after deployment that measured outcomes match the business case, such as hours saved or errors avoided, and deciding whether to scale, adjust, or retire the solution.