PMI CD-P flashcards

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Value hypothesis

A statement linking a proposed app to a metric, its baseline, a target, and a measurement window. Without a baseline, success cannot be proven after launch.

Root cause analysis

Structured technique to find the underlying cause of a process problem rather than its symptom. Common methods are 5 Whys, fishbone diagrams, and direct process observation.

Cost of inaction

The quantified harm of leaving the current state unchanged, expressed in time, money, errors, or risk. It justifies prioritization against other candidate projects.

Stakeholder influence-interest grid

A mapping of stakeholders on influence and interest axes. High-influence, low-interest parties need brief decision summaries; high-interest parties need working involvement.

Minimum viable scope

The smallest feature set that can move the value metric. A feature whose removal does not affect that metric is deferred to a later release.

Discovery output set

The documented trigger, process steps, decision points, handoffs, exceptions, cycle time, and volume that describe a process before design begins.

Citizen development candidate test

A process qualifies when it is bounded, rule-based, low in data sensitivity, has a clear owner, and shows measurable pain such as cycle time or error rate.

Environment separation

Keeping development, test, and production workspaces distinct so that only reviewed artifacts are promoted into production where real users and data reside.

Data loss prevention policy

Platform rules classifying connectors as business, non-business, or blocked. Combining business and non-business data in a single app is typically prevented.

Connector risk tier

A classification of connectors by data exposure and control. Standard connectors are often pre-approved; premium and custom connectors usually need extra review.

Delegation limit

A cap on how many records a low-code query retrieves server-side. Exceeding it causes silent client-side filtering and incomplete results unless the query is redesigned.

Maker inventory

A register listing each app's owner, sponsor, data sources, connector tier, criticality, and last review date. It enables lifecycle and risk oversight.

Capacity licensing

A pricing model where an organization buys pooled platform capacity rather than per-user licenses. Cost risk shifts to the maker and requires active usage monitoring.

Reusable component library

A shared set of templates, controls, and automation patterns that reduces duplicate build effort and enforces consistent governance controls across apps.

Single source of business rules

A design principle placing each business rule in exactly one named location, such as a formula or flow, rather than duplicating it across screens.

Idempotent automation

An automation that checks for an existing record using a natural identifier before creating a new one, preventing duplicates on retries or repeated submissions.

Input validation layering

Validating user input at the point of entry and again at the data layer. Client-only validation can be bypassed and is insufficient for data integrity.

Correlation ID logging

Attaching a unique identifier to each transaction so errors logged across screens, flows, and data layers can be traced to one user action.

Source-side filtering

Applying filters and aggregation in the data source query rather than in the client. This keeps performance stable as record counts grow.

Accessibility baseline

Minimum design controls: every input labeled, logical tab order, no meaning conveyed by color alone, and readable contrast for text.

Naming convention rule

Names are prefixed by environment and purpose, major releases carry versions, and retired component names are never reused for new artifacts.

Test pyramid

A testing shape with many unit-level rule checks, fewer integration tests across connectors, and few end-to-end UI tests, balancing speed and coverage.

Boundary testing

Testing at the edges of allowed input: zero records, one record, maximum size, oversized payloads, null or blank values, and duplicate submissions.

UAT exit criteria

Acceptance conditions agreed before user acceptance testing begins, typically named testers, scenario coverage, zero open severity-1 defects, and signed acceptance.

Severity versus priority

Severity measures the impact of a defect on the system; priority measures how urgently it should be fixed. The two are assigned independently.

Rollback plan

A documented recovery path naming the artifact version to restore, the data restore point, and the person authorized to trigger the rollback.

Deployment sequence

Freeze changes, back up solution and data, deploy to test, run regression, deploy to production, smoke test, then announce to users.

Three lines of defense

Maker owns build quality, the center of excellence sets standards and reviews, and audit or risk provides independent assurance over the whole program.

Tiered review model

Risk-based governance where low-risk apps use a self-service checklist, medium-risk apps get center-of-excellence review, and high-risk apps get full security review.

Shared responsibility matrix

A document naming who owns the platform, connectors, data, app support, and incident response across the citizen development program and IT.

Data classification tiers

Labels such as public, internal, confidential, and restricted that determine which controls apply. Restricted data is usually barred from citizen-built apps.

Orphaned app detection

Governance practice of identifying apps whose owner has left or whose support contact is stale, then reassigning or retiring them before risk accumulates.