Within the PMI-CPMAI methodology, identifying data needs is a core activity of Phase II (Data Understanding). It follows Business Understanding, where the AI problem and its pattern were defined. Understanding data types and formats ensures the project team knows what data the chosen AI pattern requires, whether that data exists, and how much effort is needed to make it usable for model training.

Data types fall into three broad categories. Structured data is organized in rows and columns, such as databases, spreadsheets and transaction records. It includes numerical values (continuous or discrete), categorical values (nominal or ordinal), Boolean fields and dates. Semi-structured data has some organization but no rigid schema. Examples include JSON, XML, logs and emails. Unstructured data has no predefined model and makes up most enterprise data. It includes text documents, images, audio, video and sensor streams. Specialized types include time-series data, geospatial data and graph or relationship data.

Common formats include:
- CSV, Parquet and SQL tables for tabular data
- JSON and XML for semi-structured data
- TXT and PDF for text
- JPEG, PNG and DICOM for images
- WAV and MP3 for audio
- MP4 for video

Format choices affect storage, processing speed, compatibility with tools and the transformation effort required.

Data types should align with the AI pattern being pursued:
- Recognition relies on images, audio or text.
- Predictive analytics relies on structured historical data.
- Conversational systems need text and speech.
- Pattern and anomaly detection often uses time-series data.
- Hyperpersonalization requires behavioral data.

Project managers must also determine whether data must be labeled for supervised learning or can stay unlabeled for unsupervised approaches. Labeling adds cost and time.

Key considerations for each data source include:
- Volume, velocity, variety and veracity
- Accessibility and ownership
- Privacy and regulatory constraints
- Data quality

Assessing these factors early supports the CPMAI go/no-go decision. It prevents projects from advancing without the data needed to train reliable, trustworthy models.

In PMI-CPMAI, the Identify Data Needs work falls within the Data Understanding phase. Here the AI project manager decides how much data, and what kind, is needed to meet the business objective. Data volume requirements and sampling strategies are central to that decision, because data, not code, usually determines whether an AI project succeeds.

Data volume requirements describe the quantity of data needed to train, validate, and test a model reliably. Several factors drive volume. Problem complexity matters: deep learning for image recognition may need many thousands of labeled examples, while simple regression may need far fewer. The number of features and classes matters, since more dimensions and categories require more examples to avoid overfitting. Required accuracy and confidence levels matter as well, and rare events such as fraud need enough positive cases to be learned at all.

Project managers should also consider whether data can be augmented, synthesized, or supplemented through transfer learning. They must account for practical limits such as storage, labeling cost, privacy, and time. Too little data leads to poor generalization. Too much unmanaged data raises cost without adding value.

Sampling strategies define how a representative subset is selected when using all available data is impractical, or when data must be split into training, validation, and test sets. Common approaches include:

- **Random sampling**, which gives every record an equal chance of selection.
- **Stratified sampling**, which preserves class or subgroup proportions and is critical for imbalanced data.
- **Systematic or cluster sampling**, used for large or geographically distributed datasets.
- **Oversampling, undersampling, or SMOTE**, which address class imbalance.
- **Time-based sampling**, which suits forecasting and avoids data leakage.

Good sampling reduces bias, supports fairness and trustworthy AI, and ensures the model reflects real-world conditions. In CPMAI's iterative approach, teams start with a minimum viable dataset, test feasibility, and expand only when needed. They document their volume assumptions and sampling decisions so that data quality, representativeness, and governance remain transparent and auditable throughout the project.

In the PMI-CPMAI framework, Phase II (Data Understanding) begins with identifying data needs. A key part of that work is defining temporal and granularity requirements. These describe when the data must come from and at what level of detail it must exist so the AI solution can meet the business objective defined in Phase I.

Temporal requirements cover the time dimension of data:
(1) Historical depth: how far back the data must go to capture trends, seasonality, cycles, and rare events. A demand-forecasting model may need several years of history to learn annual patterns.
(2) Recency and freshness: how current the data must be. Fraud detection may need near-real-time feeds, while strategic planning can tolerate monthly updates.
(3) Frequency and latency: how often data is collected and how quickly it must reach the model, whether in batch, streaming, or on-demand pipelines.
(4) Time alignment: making sure timestamps are consistent across sources and time zones. This includes avoiding data leakage, where information from the future accidentally appears in training data.
(5) Stability and drift: whether past data still represents current conditions after changes in markets, policies, or behavior.

Granularity requirements cover the level of detail in each record:
(1) Unit of analysis: whether data is captured per transaction, customer, device, store, or region.
(2) Aggregation level: whether summarized data is enough or raw, fine-grained records are needed.
(3) Matching granularity to the decision: data too coarse hides important signals, while data too fine adds noise, storage cost, and privacy risk.
(4) Consistency across sources: merging datasets recorded at different levels, such as hourly sensor readings and monthly sales, requires harmonization.

For the project manager, these requirements shape feasibility, cost, timelines, and data-sourcing decisions. Defining them early, with subject matter experts and data engineers, helps prevent rework and confirms data availability before modeling. It also supports the iterative go/no-go checkpoints that are central to CPMAI's data-first approach.

In PMI-CPMAI, the Identify Data Needs domain asks whether the right data exists, can be accessed, and is good enough to support the AI solution defined during business understanding. Data Quality Standards and Acceptance Criteria turn the vague idea of good data into measurable, agreed-upon requirements. This matters because in AI projects data quality directly limits model performance.

Data Quality Standards are the dimensions used to judge data fitness. Common dimensions include:
- Accuracy: values correctly reflect reality.
- Completeness: required fields and records are present.
- Consistency: formats, units, and definitions match across sources.
- Timeliness: data is current enough for the use case.
- Validity: values follow business rules and allowed ranges.
- Uniqueness: duplicates are controlled.

AI adds further standards. Data should be representative of real-world conditions and the populations the model will serve. Labels for supervised learning should be accurate and consistent. Data should be checked for bias, and its lineage, provenance, privacy, and regulatory compliance must be documented.

Acceptance Criteria are the specific thresholds that data must meet before the project moves forward. Examples include missing values below 2 percent in critical features, inter-annotator agreement above 0.85, a minimum number of labeled examples per class, and data refreshed within 24 hours. Good criteria are measurable, tied to business objectives, and agreed upon by stakeholders such as data owners, domain experts, data scientists, and compliance teams.

The project manager's role is to:
1. Define these standards early.
2. Document them in data requirements.
3. Ensure data profiling and assessment are performed against them.
4. Use the results to make go/no-go decisions.

If data fails the criteria, the team can acquire more data, improve labeling, clean or augment the data, revise scope, or return to business understanding. This reflects the iterative nature of CPMAI.

Clear standards and acceptance criteria reduce project risk, prevent costly rework in later phases, support trustworthy and responsible AI, and give everyone an objective basis for judging data readiness.

In the PMI-CPMAI framework, Mapping Data Requirements to Business Objectives is a core activity within the Identify Data Needs domain. It links the business understanding established in Phase I of the CPMAI methodology to the data understanding work of Phase II. The principle is simple: AI projects fail more often from data problems than from algorithm problems, so every data requirement must be traceable to a clearly defined business goal. The process begins with the business objective and its success criteria, such as reducing customer churn by 10 percent or cutting invoice processing time in half. The project manager and team then break that objective into the AI pattern being applied, such as prediction, recognition, conversational, patterns and anomalies, hyperpersonalization, autonomous systems, or goal-driven systems. Each pattern implies specific data types. A churn prediction model needs historical customer behavior, transaction records, and labeled outcomes showing who actually left. Next, the team builds a traceability matrix that maps each objective to the required data sources, attributes, volume, granularity, timeliness, and labeling needs. This exposes gaps early, such as missing labels, insufficient history, or restricted access, before resources are committed to modeling. It also prevents over-collection, which adds cost, privacy risk, and regulatory exposure. Key questions include: What decision will the AI support? What data reflects the real-world conditions of that decision? Is the data available, accessible, and of adequate quality and quantity? Who owns it, and are there legal, ethical, or consent constraints? Do business stakeholders agree that the data represents the problem accurately? Mapping also supports go or no-go decisions. If critical data cannot be obtained, CPMAI encourages iterating back to business understanding to reframe or rescope the problem rather than forcing a weak solution. Ultimately, this mapping keeps the AI initiative value-driven, data-centric, and aligned with stakeholder expectations, increasing the likelihood that the deployed model delivers measurable return on investment.

In the PMI-CPMAI framework, the Identify Data Needs work, which aligns with the Data Understanding phase of the CPMAI methodology, focuses on determining what data an AI solution requires and whether that data is available, accessible, and fit for purpose. Locating domain experts for data sources is a critical task within this effort, because data rarely explains itself. Domain experts, often called subject matter experts (SMEs), are the people who understand how data is generated, what it represents, and how it relates to the business problem.

The project manager should first map each candidate data source, such as transactional databases, sensor feeds, documents, logs, or third-party datasets, to the individuals or teams who own, create, or regularly use it. These may include data stewards, system administrators, business analysts, frontline operators, compliance officers, and external vendors. Reviewing data catalogs, organizational charts, RACI matrices, and data governance records helps identify the right owners and custodians.

Domain experts provide essential context. They clarify field definitions, units, business rules, and collection methods. They also reveal known quality issues, gaps, biases, and historical changes in how data was recorded. They can explain access restrictions, privacy and regulatory constraints, and the effort required to extract data. In addition, they help determine whether data truly reflects the patterns the AI model must learn, and they are often essential for labeling, annotation, and validating ground truth.

Engaging experts early reduces the risk of building models on misunderstood or unsuitable data, which is a leading cause of AI project failure. Project managers should secure stakeholder commitment, schedule time with experts, document their insights in a data inventory or data dictionary, and plan for their continued involvement in later phases such as data preparation and model evaluation.

Ultimately, locating domain experts turns raw data sources into understood, trustworthy assets. It supports informed go or no-go decisions and keeps the AI initiative grounded in real business needs.

In the PMI-CPMAI framework, Identify Data Needs falls within Data Understanding (CPMAI Phase II). Its purpose is to confirm that the data available can actually support the AI solution defined during Business Understanding. Engaging business users on data context and meaning is central to this work. Raw data rarely explains itself. The people who create, use, and depend on it every day hold the knowledge needed to interpret it correctly.

Business users and subject matter experts provide context that data engineers and data scientists often lack. They explain what each field represents and how values are generated, for example whether a status code is entered manually or by a system. They describe the business rules behind the data, such as why a customer record might be duplicated or what a null value really means. They also highlight seasonal patterns, process changes, policy shifts, and historical events that could distort a model if left unexplained. This tacit knowledge helps the team avoid misreading data, building on proxies that do not reflect reality, or training models on biased or outdated patterns.

Effective engagement uses structured techniques:
- Interviews and workshops to walk through data sources
- Building a shared business glossary and data dictionary
- Reviewing data samples together
- Validating that target labels truly match the business outcome the AI is meant to predict

Project managers should also involve data owners and stewards. This clarifies access, privacy, regulatory constraints, and data quality expectations, all of which feed into trustworthy AI considerations.

The benefits are significant. Early engagement reduces rework, reveals data gaps before model development begins, and builds stakeholder trust and buy-in. It also keeps the project aligned with real business value. Because CPMAI is iterative, these conversations continue as understanding deepens. Insights gained may send the team back to Business Understanding to refine the problem scope or the success criteria. Ultimately, treating business users as partners in interpreting data ensures that the AI system learns from data that is accurate, relevant, and meaningful to the organization.

In the PMI-CPMAI framework, the Identify Data Needs work sits within the Data Understanding phase. Here the AI project team determines what data is required, where it lives, who controls it, and whether it can legally and ethically be used. Data Stewards and Data Governance Teams are key stakeholders in this effort because AI projects are data-centric, and most AI failures trace back to data issues rather than algorithms.

Data Stewards are subject-matter custodians responsible for specific data domains, such as customer, financial, or operational data. They understand the meaning, lineage, quality, and limitations of the data they oversee. For an AI project manager, stewards help answer critical questions. Does the needed data exist? What does each field actually represent? How accurate, complete, and current is it? Are there known biases or gaps? Stewards also maintain metadata and data dictionaries, and they can grant or facilitate access. Engaging them early prevents costly misunderstandings during data preparation and model training.

Data Governance Teams operate at the organizational level. They define the policies, standards, roles, and controls for how data is collected, stored, shared, secured, and retained. Their concerns include privacy regulations such as GDPR, HIPAA, and CCPA, consent and permitted use, data classification, security, retention rules, and ethical or responsible AI considerations. They approve whether data can be repurposed for AI training and may require anonymization, masking, or data-sharing agreements.

For CPMAI practitioners, best practices include identifying stewards and governance contacts during stakeholder analysis, documenting data sources and ownership, confirming usage rights before committing to a solution, and building governance approval time into the project schedule. Collaboration with these groups supports trustworthy AI, reduces compliance risk, and ensures that data quality and quantity are sufficient. Ultimately, they help the project answer a central CPMAI go or no-go question: do we have the right data, in the right condition, with the right permissions, to deliver the AI solution?

In the PMI-CPMAI framework, the Identify Data Needs domain focuses on determining what data an AI solution requires, where that data resides, and whether it is usable. A key part of this work is engaging Technical Experts on Data Systems and Structures. These are the people who understand how an organization's data is physically and logically stored, moved, and governed.

These experts typically include data architects, data engineers, database administrators, IT system owners, enterprise integration specialists, and cloud or platform engineers. Business stakeholders and domain experts explain what the data means. Technical experts explain how the data exists: its schemas, formats, storage locations, access methods, volumes, refresh frequencies, and interdependencies across systems.

In CPMAI's iterative, data-centric approach, AI project managers rely on these experts to answer several practical questions:

- Which source systems hold the relevant data, such as ERP, CRM, data warehouses, data lakes, or streaming platforms?
- Is the data structured, semi-structured, or unstructured?
- How is the data labeled, and how complete is it?
- What pipelines, APIs, or extraction methods are available?
- What security, privacy, and compliance controls restrict access?
- What lineage and metadata exist to establish trustworthiness?

Their input helps the team assess data feasibility early, before significant investment in model development. It also helps them estimate the effort needed for data preparation, integration, and transformation. Finally, it surfaces technical risks such as legacy system limitations, siloed data, inconsistent formats, latency constraints, and scalability issues.

Project managers should identify these experts during stakeholder analysis and involve them in data discovery workshops. Their findings should be documented in data inventories or data requirement artifacts. Collaboration with these experts also supports realistic go/no-go decisions in the CPMAI phases.

Ultimately, technical data experts bridge the gap between what the AI solution needs and what the organization's infrastructure can actually deliver. This reduces the chance of project failure caused by unavailable, inaccessible, or poor-quality data.

In the PMI-CPMAI framework, Identify Data Needs falls within the Data Understanding phase. It follows Business Understanding, where the AI problem, the AI pattern (for example recognition, prediction, or conversational systems), and the success criteria are defined. Mapping internal databases and data warehouses is a core activity in this step. It means systematically discovering, cataloging, and assessing the data assets an organization already owns so the team can tell whether they can support the intended AI solution.

The process usually starts with an inventory. The team identifies the relevant systems of record, such as ERP, CRM, HR, finance, operational databases, data warehouses, data lakes, and departmental spreadsheets. For each source, the project manager works with data owners, data stewards, and IT to document the following:

- Location, format, and schema
- Volume and refresh frequency
- Lineage, meaning where the data comes from and how it is transformed
- Access methods and ownership

Data warehouses are especially valuable. They often hold cleaned, integrated, historical data that is suitable for training models. However, they may aggregate away the granular detail that machine learning needs.

Mapping then links each data element to the AI use case. The team asks several questions:

- Does the data contain the features and labels the model requires?
- Is there enough history and enough examples?
- Is the data representative and free of obvious bias?
- What is its quality in terms of completeness, accuracy, consistency, and timeliness?

This comparison reveals data gaps. Gaps may lead the team to acquire external data, generate synthetic data, launch labeling efforts, or rescope the project.

Governance is critical throughout. Teams must identify personally identifiable information, regulatory constraints such as GDPR or HIPAA, consent limits, retention policies, and security classifications before using any data. Common outputs include a data inventory or catalog, a source-to-requirement map, a data quality assessment, and a list of risks and access approvals.

CPMAI stresses that AI projects fail more often because of data issues than because of algorithms. Thorough mapping lowers that risk and supports informed go or no-go decisions. It also produces more realistic schedules and budgets and sets up smoother data preparation in later iterations.

In the PMI-CPMAI framework, the Identify Data Needs work, part of the Data Understanding phase, requires project managers to determine whether internal data is enough to meet the AI solution's objectives. When internal data is insufficient, incomplete, biased or too narrow, teams look to external and third-party data sources. These include commercial data vendors, data brokers, government and open data portals, academic datasets, industry consortia, partner organizations, public APIs, social media feeds, web-scraped content, synthetic data providers and pre-labeled training datasets from annotation companies.

External data can enrich internal records, for example by adding demographic, weather, economic or geospatial attributes. It can fill gaps for rare events, increase data volume and diversity, and speed up projects when collecting the data internally would be too costly or slow. Pre-trained models and foundation models are a related category, because they carry embedded knowledge from external training data.

The CPMAI approach emphasizes careful evaluation before acquisition. Key considerations include:

- Relevance and fit to the defined business problem.
- Data quality, including accuracy, completeness, timeliness and consistency.
- Provenance and lineage, meaning knowing how the data was collected.
- Licensing terms and usage rights, including restrictions on commercial use or model training.
- Cost and ongoing subscription models.
- Format compatibility and integration effort.
- Update frequency and long-term vendor reliability.

Trustworthy AI concerns are central. Teams must assess privacy compliance with regulations such as GDPR and CCPA, consent obligations, potential bias, security risks and ethical sourcing. Third-party data also creates dependency risks: vendors may change terms, raise prices or stop providing the data, which can affect model retraining and operationalization.

Project managers should document these sources in a data inventory. They should also engage legal, procurement and data governance stakeholders early, and include data acquisition timelines and costs in project planning. Following the CPMAI principle of iterating in small cycles, teams can test sample external data before committing to large purchases. This confirms that the data actually improves model performance and supports the go/no-go decisions made throughout the AI project lifecycle.

In the PMI-CPMAI framework, Identify Data Needs falls within the Data Understanding phase. Here the AI project manager confirms what data the solution requires, where it lives, and whether it can be accessed reliably. Cloud storage and distributed data repositories matter because modern AI data rarely sits in one place. It is usually spread across platforms, regions, and organizations.

Cloud storage is on-demand, scalable capacity offered by providers such as AWS S3, Azure Blob Storage, and Google Cloud Storage. Its main forms are object storage, used for unstructured data like images, audio, logs, and documents, plus block and file storage. The benefits for AI are elastic scalability for large training datasets, pay-as-you-go cost, built-in redundancy, and close integration with cloud machine learning services and compute.

Distributed data repositories store data across multiple nodes or locations while presenting it as a unified resource. Common examples are:
- Data lakes, which hold raw structured and unstructured data.
- Data warehouses, which hold curated, structured data for analytics.
- Lakehouses, which combine features of both.
- Distributed file systems such as HDFS.
- Federated sources, where data stays in place across departments or partners.

When identifying data needs, the project manager should assess the following:
1. Location and access: Where does each required dataset reside? Who owns it, and what permissions or APIs are needed?
2. Volume, velocity, and variety: Can the storage handle the scale and formats the model needs?
3. Latency and data gravity: Moving large datasets is costly and slow, including egress fees, so compute is often placed near the data.
4. Governance and compliance: Data residency, sovereignty, privacy rules such as GDPR and HIPAA, encryption, and audit trails.
5. Quality and consistency: Distributed copies can create versioning conflicts, duplication, or stale data. Metadata catalogs and lineage tracking help prevent this.
6. Cost and sustainability: Storage tiers, retrieval charges, and long-term retention.

Understanding these repositories early prevents surprises later in the project. It supports realistic feasibility decisions, helps the team scope data preparation, and confirms that the data infrastructure can support an iterative AI lifecycle.

In the PMI-CPMAI framework, the Identify Data Needs domain sits within the Data Understanding phase of the CPMAI methodology. It asks project managers to determine what data an AI solution requires, where that data lives, and whether it is fit for purpose. Legacy systems and historical data archives are often the richest, and the most problematic, sources an organization has.

Legacy systems are older operational platforms that still run critical business processes, such as mainframes, outdated ERP or CRM tools, proprietary databases, and custom applications. They frequently hold years of transactional, customer, or operational records that are valuable for training supervised models, detecting patterns, and setting performance baselines. Historical data archives include backups, data warehouses, cold storage, scanned documents, log files, and retired system exports kept for compliance or reference.

When identifying data needs, a CPMAI practitioner must assess several factors. Accessibility: Can the data be extracted? Is there documentation, an API, or staff who understand the schema? Quality: Older data often has missing values, inconsistent formats, duplicate records, or encoding problems. Relevance and drift: Historical data may reflect outdated business rules, products, or customer behavior, which can introduce bias or reduce model accuracy. Labeling: Archives rarely contain the labels needed for supervised learning. Governance and compliance: Retention policies, privacy regulations such as GDPR, and consent limits may restrict how archived personal data can be reused. Volume and cost: Migrating, cleaning, and storing large archives requires budget and time that must be built into the project plan.

Project managers should involve data stewards, system owners, and subject matter experts early, document data lineage, and run data profiling to confirm feasibility before committing to model development. Following the CPMAI iterative approach, teams should start with a small, accessible slice of legacy data, validate its value, and then expand. Treating legacy data as an asset that comes with risk helps avoid failed AI projects and supports trustworthy, well-governed AI outcomes.

In the PMI-CPMAI framework, Data Ownership and Access Permissions are critical considerations within the Identify Data Needs domain, which aligns with the Data Understanding phase of the CPMAI methodology. Once a project team determines what data an AI solution requires, it must establish who owns that data and whether the project can legally and ethically use it. Many AI projects fail not because the data does not exist, but because the team cannot obtain timely, authorized access to it.

Data ownership is about accountability. A data owner, often a business unit leader, data steward, or external provider, is responsible for the quality, security, and approved use of a dataset. For each required source, the AI project manager should identify the owner, document who holds decision rights, and clarify obligations such as licensing terms, contractual restrictions, intellectual property rights, and regulatory constraints like GDPR, HIPAA, or CCPA. Third-party and publicly scraped data need extra scrutiny, because usage rights for model training may differ from rights for analytics or reporting.

Access permissions describe how data can be reached and by whom. Key questions include: Who on the team needs access, and at what level (read, write, or export)? Must data be anonymized, masked, or aggregated first? Can it leave its source environment, or must processing occur in a secure enclave? How long will access last, and how will it be audited? Applying the principle of least privilege and role-based access control lowers security and privacy risks.

From a project management perspective, securing ownership approvals and permissions should be treated as a schedule-critical activity. Approval cycles, legal reviews, and data-sharing agreements can take weeks or months. CPMAI encourages addressing these issues early, as part of a go/no-go assessment. If necessary data cannot be accessed, the team should rescope the project, look for alternative sources, or consider synthetic data. Documenting ownership and permissions also supports trustworthy AI by enabling transparency, traceability, and compliance throughout the model lifecycle.

In the PMI-CPMAI framework, which builds on the iterative CPMAI methodology (Business Understanding, Data Understanding, Data Preparation, Model Development, Model Evaluation, and Operationalization), provisioning compute is a key part of Identify Data Needs. Once a project team knows what data an AI solution requires, it must also confirm that the infrastructure exists to ingest, clean, transform, label, store, and train on that data. Underestimating compute is a common reason AI projects stall, exceed budgets, or fail to move beyond proof of concept.

Provisioning begins with sizing the workload. The project manager works with data engineers and data scientists to estimate data volume, velocity, and variety. They also consider the complexity of preprocessing pipelines and the type of model being trained. Traditional machine learning on structured data may run well on CPUs. Deep learning, computer vision, and large language model fine-tuning typically require GPUs or TPUs, high-memory nodes, and fast storage.

Key decisions include the deployment model (on-premises, cloud, hybrid, or managed AI platforms) and the trade-off between capital and operational expense. Teams also choose between elastic and reserved capacity and between batch and real-time processing. Cloud resources offer rapid scalability and pay-as-you-go pricing, but they require cost monitoring to prevent runaway spending during iterative experimentation.

The project manager must also address non-functional requirements. Data residency, privacy, and regulatory constraints may limit where data can be processed. Security controls, access management, and encryption must be in place before sensitive data moves into compute environments. Reproducibility depends on consistent environments, so teams often use containers, versioned infrastructure-as-code, and MLOps tooling.

Finally, provisioning should anticipate the full lifecycle. Training needs differ from inference and production needs, and models may require periodic retraining. Aligning compute plans with project scope, timeline, budget, and risk registers keeps the AI initiative feasible. It also ensures each CPMAI iteration can proceed without infrastructure bottlenecks, supporting delivery of business value.

Within the PMI-CPMAI framework, the Identify Data Needs domain focuses on determining what data an AI project requires, where it comes from, and how it will be accessed and protected. Secure Development Environments for AI Teams are a core consideration because AI work involves large volumes of potentially sensitive data that teams must explore, label, transform, and use for model training. A secure development environment is a controlled technical and procedural workspace where data scientists, engineers, and analysts can work with data without exposing it to unauthorized access, leakage, or misuse.

Key elements include:

1. Access control based on least privilege. Role-based permissions ensure each team member reaches only the data needed for their task. Identity management, multi-factor authentication, and periodic access reviews reduce insider and external risk.

2. Data protection techniques. Encryption at rest and in transit, data masking, pseudonymization, anonymization, and synthetic data let teams work productively while minimizing exposure of personally identifiable or confidential information.

3. Isolation and segmentation. Sandboxed workspaces, virtual private clouds, and separate development, test, and production environments prevent sensitive data from moving into uncontrolled locations such as personal laptops or public AI tools.

4. Auditability and lineage. Logging who accessed which datasets, when, and why supports compliance with regulations such as GDPR, HIPAA, or industry-specific rules. Data and model versioning provide traceability for governance and trustworthy AI reviews.

5. Approved tooling and supply chain security. Vetted libraries, scanned open-source packages, and approved pretrained models reduce vulnerabilities and licensing risks.

6. Policies and training. Clear data-handling agreements, usage policies, and team awareness ensure that people, not just technology, uphold security.

For the AI project manager, planning secure environments early during data needs identification prevents costly rework, builds stakeholder and regulator trust, and ensures that data access constraints are reflected in schedules, budgets, and feasibility decisions before the project moves into data preparation and model development.

In the PMI-CPMAI framework, Data Storage and Backup is a key consideration within the Identify Data Needs domain, which closely aligns with the CPMAI methodology's Data Understanding phase. Because AI systems are data-centric, the project manager must ensure that the data required to train, validate, test, and operate models is stored securely, remains accessible, and can be recovered if it is lost or corrupted. Storage planning starts with understanding data characteristics, often described by the Vs of big data: volume, velocity, variety, and veracity. Large image or video datasets, streaming sensor data, and unstructured text each require different solutions, such as data lakes, data warehouses, cloud object storage, or hybrid on-premises architectures. The project manager should work with data engineers and IT to choose storage that balances cost, scalability, performance, and the latency needs of training and inference. Backup and recovery planning protects the organization's investment in data collection, labeling, and preparation. Key practices include automated and regular backups, geographic redundancy, defined recovery point objectives (RPO) and recovery time objectives (RTO), and periodic restoration testing. AI projects also need data versioning and lineage tracking so teams can reproduce model results, audit decisions, and roll back to earlier datasets if data drift or quality problems appear. Versioning labeled training sets is especially important because relabeling is costly. Governance and compliance are central concerns. Storage must follow privacy regulations such as GDPR or HIPAA, data residency rules, retention schedules, and organizational policies. Common controls include encryption at rest and in transit, role-based access control, and audit logging, all of which support trustworthy and responsible AI. Finally, storage and backup needs should be estimated early, since they affect budget, schedule, and feasibility. Including them in the initial assessment of data needs helps prevent bottlenecks later in the iterative CPMAI lifecycle and supports smooth operationalization and ongoing model retraining.

In the PMI-CPMAI framework, the Identify Data Needs activity sits within the Data Understanding phase. Here teams define what data the AI solution requires, where it lives, who owns it, and whether its quality, quantity, and access rights are sufficient. Collaboration tools and version control give this work structure, transparency, and repeatability across data scientists, data engineers, domain experts, compliance officers, and project managers.

Collaboration tools, such as shared notebooks (Jupyter, Databricks), wikis (Confluence), and work trackers (Jira, Azure Boards), let stakeholders record data requirements together. Teams use them to document data sources, data dictionaries, labeling needs, and privacy constraints, and to capture business-to-data mappings. They also support asynchronous review, so subject matter experts can confirm that the data actually represents the business problem defined earlier in Business Understanding. Data catalogs (Collibra, Alation) add discoverability, lineage, and ownership details, which help the team judge availability and governance early.

Version control extends beyond code to data, schemas, and documentation. Git manages scripts, queries, and requirement documents. Tools such as DVC, LakeFS, or Delta Lake track dataset versions, so every exploration or model iteration can be traced back to an exact data snapshot. This is essential because AI projects are data-centric and iterative. Requirements change as teams find gaps, bias, or quality problems, and versioning keeps a history of those decisions.

Key benefits for the AI project manager include:

- **Reproducibility:** results can be recreated from a specific data and code state.
- **Auditability and compliance:** lineage supports responsible and trustworthy AI and regulatory reviews.
- **Reduced rework:** shared, current requirements prevent teams from working on conflicting assumptions.
- **Go/no-go decisions:** documented data gaps inform feasibility checkpoints before costly model development begins.

Best practices include setting clear access controls, naming conventions, branching strategies, and metadata standards early. Version control should be integrated with MLOps pipelines so the workspace scales from experimentation into operationalization.

In the PMI-CPMAI framework, Data Extraction from Identified Sources is a key activity within the Identify Data Needs domain. It corresponds to the Data Understanding phase of the CPMAI methodology and prepares the ground for Data Preparation. Once the project team has defined the AI problem, chosen the relevant AI pattern (such as recognition, prediction, or conversational systems), and listed candidate data sources, it must actually obtain that data in a usable, compliant, and repeatable way.

The process starts by confirming each source's location, owner, format, and access method. Sources may be internal databases, data warehouses, data lakes, ERP or CRM systems, APIs, IoT sensors, documents, images, logs, or third-party and public datasets. The project manager works with data owners, stewards, and IT to secure access permissions and to clarify licensing terms, data-sharing agreements, and any regulatory limits such as GDPR, HIPAA, or industry-specific rules.

The team then selects extraction techniques that suit each source. Options include SQL queries, ETL or ELT pipelines, API calls, web scraping where it is permitted, streaming ingestion, and manual collection. Important considerations include data volume, velocity, and variety, and whether extraction will be a one-time pull for prototyping or an automated pipeline that supports ongoing model training and operations.

During extraction, the team should capture metadata and lineage, meaning where the data came from, when it was pulled, and how it was transformed. This supports traceability, reproducibility, and trustworthy AI. The team should also run initial quality checks for completeness, consistency, timeliness, and representativeness, so that gaps or biases are flagged early.

Risks to manage include privacy exposure, security breaches, unclear data ownership, schema changes, and extraction costs. The PMI-CPMAI approach stresses iteration. If the extracted data proves insufficient, the team loops back to revisit data needs or the scope of the business problem. Doing this step well reduces downstream rework and keeps the AI project feasible and aligned with business objectives.

In the PMI-CPMAI framework, Data Transfers and Migrations to AI Environments is a key consideration within the Identify Data Needs domain, which aligns with the Data Understanding phase of the CPMAI methodology. Once a project team knows which data the AI solution requires, it must determine how that data will physically and logically move from its source systems into the environment where models will be trained, tested, and operationalized. Sources may include legacy databases, ERP systems, third-party providers, or IoT devices. Destinations may include cloud ML platforms, data lakes, feature stores, or on-premises GPU clusters.

An AI project manager must assess several dimensions.

1. Volume, velocity, and variety: Large datasets or streaming data may require high-bandwidth connections, incremental loading, or physical transfer appliances. The team must also decide between batch and real-time pipelines.
2. Format and schema compatibility: Data often needs conversion, schema mapping, and metadata preservation so it remains usable and understandable in the new environment.
3. Security and privacy: Data must be protected with encryption in transit and at rest, access controls, and anonymization or masking of sensitive fields.
4. Regulatory compliance: Cross-border transfers, data residency and sovereignty rules, and regulations such as GDPR or HIPAA can restrict where data may move.
5. Integrity and lineage: Checksums, record counts, and validation tests confirm nothing was lost or corrupted. Lineage tracking supports trustworthy AI, auditability, and reproducibility.
6. Cost and timing: Cloud egress fees, storage costs, downtime windows, and migration duration all affect budget and schedule.
7. Ownership and agreements: Data sharing agreements, licensing terms, and stakeholder approvals must be secured before any transfer begins.

The project manager should document these requirements, add migration risks to the risk register, and coordinate with data engineers, security, legal, and data owners. Piloting a small transfer first, defining rollback plans, and planning for ongoing pipelines rather than one-time moves helps ensure the data reaching the AI environment is complete, compliant, secure, and ready for the Data Preparation phase.

In the PMI-CPMAI methodology, Identify Data Needs falls within Data Understanding, the phase where the project team determines what data an AI solution requires, where it comes from, and whether it is adequate. Data Collection Processes for Ongoing Feeds address a key reality of AI projects: models are not built once and left alone. They need a continuous supply of fresh data for inference, monitoring, and periodic retraining. Planning these feeds early prevents a model that works in development from failing in production.

Key considerations include:

1. Source identification and ownership: Identify each recurring data source, such as transactional systems, IoT sensors, APIs, third-party vendors, or user interactions. Assign clear data owners and stewards who are accountable for availability and quality.

2. Frequency and latency: Decide whether data arrives in batches (daily or weekly loads) or as real-time streams. This choice depends on the AI pattern and business need. Fraud detection may require streaming data, while monthly demand forecasting may only need batch updates.

3. Pipeline design and automation: Define repeatable, automated ingestion pipelines with documented schemas, transformation rules, and data contracts with providers. This reduces manual effort and keeps the format consistent over time.

4. Quality controls: Build validation checks for completeness, accuracy, timeliness, and consistency. Include alerts for missing feeds, schema changes, or anomalous values.

5. Labeling and feedback loops: For supervised learning, plan how new ground-truth labels will be captured, for example through user feedback or human review, so that retraining data stays current.

6. Drift monitoring: Ongoing feeds make it possible to detect data drift and concept drift, which signal when retraining is needed.

7. Governance and compliance: Ensure continued consent, privacy protection, security, retention policies, and regulatory compliance for all incoming data.

8. Versioning and cost: Version datasets for traceability and reproducibility, and estimate storage, compute, and licensing costs.

Well-defined ongoing feed processes support iterative CPMAI cycles and help keep AI solutions trustworthy and valuable over time.

In the PMI-CPMAI framework, the Identify Data Needs domain sits in the Data Understanding phase. Validating completeness and accuracy during collection means checking incoming data while it is being gathered, rather than waiting until data preparation or model training to find problems. Because AI outcomes depend on data quality ('garbage in, garbage out'), catching gaps and errors early lowers rework, cost, and project risk.

Completeness asks whether the collected data covers everything the AI solution needs. Key checks include: (1) Field-level completeness, meaning required attributes are populated and missing values are measured against agreed thresholds. (2) Coverage completeness, meaning the data represents all relevant populations, time periods, geographies, edge cases, and classes. This is critical for avoiding bias and poor generalization. (3) Volume sufficiency, meaning enough records and labeled examples exist for the chosen AI pattern, such as classification, prediction, or recognition.

Accuracy asks whether the data correctly reflects reality. Practices include validating against authoritative sources, enforcing format, range, and type rules, detecting duplicates and outliers, and confirming label quality through inter-annotator agreement or expert review. The project should also verify lineage and provenance so it is clear where data came from and how it was transformed.

Practical techniques include automated validation rules in ingestion pipelines, data profiling, statistical sampling with manual review, data quality dashboards, and pilot or incremental collection batches. Acceptance criteria, such as a maximum missing rate or a minimum labeling accuracy, should be defined up front with data owners and subject-matter experts.

From a project management view, the AI project manager should document quality findings, track issues in a risk or issue log, and assign clear data stewardship roles. If validation shows the data cannot support the business objective, CPMAI's iterative approach encourages revisiting earlier decisions. Options include refining scope, finding new sources, or making a go/no-go decision before investing further. This supports trustworthy, responsible AI and realistic expectations for the solution.

In the PMI-CPMAI methodology, Data Refresh and Update Procedures are planned during the Identify Data Needs activity, which belongs to the Data Understanding phase. AI systems are not built once and left alone. They depend on data that reflects a changing world, so project managers must decide early how data will be kept current, accurate, and relevant over the life of the solution. Data refresh means replacing or adding to datasets on a set schedule or when specific events occur. Data update means correcting, enriching, or changing existing records. Together, these procedures guard against data drift, where incoming data no longer looks like the training data, and concept drift, where the relationship between inputs and outcomes shifts. Both problems quietly reduce model performance.

Key elements to define include the following. First, refresh frequency: real-time streaming, daily, weekly, or quarterly, based on how volatile the business domain is and on cost limits. Second, triggers: scheduled intervals, performance thresholds, detected drift, regulatory changes, or new data sources. Third, data sources and ownership: who supplies the data, under what agreements, and who approves changes. Fourth, validation and quality checks: automated tests for completeness, consistency, schema changes, and bias before new data reaches production pipelines. Fifth, versioning and lineage: tracking dataset versions so results can be reproduced, audited, and rolled back if needed. Sixth, retraining linkage: deciding whether refreshed data automatically triggers model retraining or requires human review.

From a project management view, these procedures affect scope, budget, staffing, infrastructure, and risk. Costs for storage, labeling, and compute grow as refresh frequency increases. Governance and compliance needs, such as privacy rules and data retention policies, must be built into the process. Documenting these procedures early ensures that the AI solution stays trustworthy and keeps delivering business value after deployment. It also supports the iterative nature of CPMAI, where teams return to earlier phases as data and requirements evolve.

In the PMI-CPMAI framework, Identify Data Needs comes early in an AI project. Teams determine what data the solution requires, where it will come from, and whether the organization may legally and ethically use it. Data usage rights and licensing agreements are central to that last question. Having access to data is not the same as having permission to use it for AI.

Data usage rights define who owns a dataset and what others may do with it. Rights can cover collection, storage, processing, sharing, modification, commercialization, and use in model training. Internal data may still carry limits from customer consent, privacy notices, or contracts. External data, such as purchased datasets, open data, web-scraped content, or third-party APIs, is usually governed by explicit licenses.

Licensing agreements formalize these permissions. Key terms to review include:

- **Scope of use:** research only, internal, or commercial.
- **Duration and termination:** how long the license lasts and what happens to trained models when it ends.
- **Derivative works:** whether models or outputs built from the data are restricted.
- **Attribution:** what credit must be given to the source.
- **Redistribution limits:** whether the data may be shared or resold.
- **Geographic restrictions:** where the data may be stored or used.
- **Liability and indemnification:** who bears legal risk if problems arise.

Open licenses such as Creative Commons vary widely. Some prohibit commercial use or require share-alike terms.

AI project managers must also align data use with regulations such as GDPR, CCPA, and HIPAA. These laws impose purpose limitation, consent, and data minimization requirements. Using personal data beyond its original consented purpose can create serious compliance exposure.

In practice, the CPMAI professional should:

1. Inventory candidate data sources.
2. Engage legal, privacy, and procurement stakeholders early.
3. Document provenance and permissions.
4. Flag gaps before modeling begins.

Unresolved rights issues can force costly rework, model retraining, or project cancellation. Early due diligence protects the organization, preserves stakeholder trust, and supports responsible, trustworthy AI. It ensures the data foundation is both technically suitable and legally sound.

In the PMI-CPMAI framework, Data Protection Compliance is a core consideration in the Identify Data Needs activities, which align with the Business Understanding and Data Understanding phases of the CPMAI methodology. Before any data is collected or used for an AI model, the project manager must confirm that every planned data source can be lawfully and ethically used for the intended purpose. Compliance problems found late can halt a project, force model retraining, or create legal and reputational damage, so this work happens early and continues throughout the lifecycle.

Key elements include:

1. Regulatory identification: Determine which laws and standards apply, such as GDPR, CCPA/CPRA, HIPAA, the EU AI Act, sector-specific rules, and internal corporate policies. Jurisdiction depends on where data subjects live, where data is stored, and where processing happens.

2. Data classification: Inventory the required data and flag personally identifiable information, sensitive categories (health, biometric, financial, children's data), and confidential business data.

3. Lawful basis and consent: Verify that consent, contractual need, or legitimate interest covers AI training and inference, not just the original collection purpose. Purpose limitation is a frequent gap when repurposing legacy data.

4. Data minimization: Request only the data truly needed to meet the AI objective. Less sensitive data lowers risk and compliance burden.

5. Protection techniques: Plan for anonymization, pseudonymization, masking, encryption, synthetic data, or differential privacy where appropriate.

6. Third-party and licensing checks: Confirm usage rights, data sharing agreements, and vendor obligations for externally sourced or scraped data.

7. Residency, retention, and access: Address cross-border transfer restrictions, retention and deletion schedules, data subject rights, and role-based access controls.

8. Assessments and documentation: Conduct Data Protection Impact Assessments or privacy reviews, engage legal, privacy, and security stakeholders such as the Data Protection Officer, and record decisions in data governance artifacts.

For the exam, remember that a CPMAI project manager treats data protection as a go/no-go factor: if required data cannot be obtained compliantly, the project scope, data strategy, or AI approach must be adjusted before moving forward.

In the PMI-CPMAI framework, Identify Data Needs falls within the Data Understanding phase. Here the project team determines what data an AI solution requires, where it lives, and whether the team can legally and practically use it. Access controls and user permissions are central to that last question. Data that exists but cannot be accessed, or is accessed improperly, can stall or derail an AI project.

Access controls are the policies and technical mechanisms that decide who can view, modify, copy, or share specific data assets. User permissions are the specific rights granted to individuals, roles, or systems. Common models include Role-Based Access Control (RBAC), which assigns rights by job function such as data engineer or data scientist, and Attribute-Based Access Control (ABAC), which considers context such as data sensitivity, location, or project purpose.

When identifying data needs, an AI project manager should:

1. Identify data owners and stewards for each source and secure formal approval to use the data.
2. Classify data sensitivity, such as public, internal, confidential, or regulated data like PII and PHI, to decide the protection level.
3. Apply least privilege, giving team members only the access their tasks require.
4. Address compliance obligations under regulations such as GDPR, HIPAA, or CCPA, as well as contractual limits on data use.
5. Use protective techniques such as masking, anonymization, pseudonymization, or synthetic data where full access is unnecessary.
6. Separate environments so that development, testing, and production data have distinct permission sets.
7. Enable auditing and logging to track who accessed what and when, which supports accountability and trustworthy AI.
8. Plan provisioning and revocation, including onboarding timelines and removing access when roles change or the project ends.

Access approvals often take weeks, so CPMAI encourages addressing them early and recording them in the data requirements and risk register. Doing so prevents schedule delays, reduces the risk of privacy breaches, supports ethical and responsible AI, and helps the project iterate toward a usable model with properly governed data.

In PMI-CPMAI, the Identify Data Needs domain aligns with the Data Understanding phase of the CPMAI methodology. Here, project managers make sure that every dataset feeding an AI solution is traceable, justified, and defensible. Data lineage and usage documentation for audit are the practices that make this possible.

Data lineage is the documented record of where data comes from, how it moves, and how it changes across its lifecycle. It captures original sources such as internal systems, third-party vendors, public datasets, or sensors. It also records collection methods, ownership, and timestamps. Finally, it tracks every transformation applied, including cleaning, labeling, aggregation, feature engineering, anonymization, and augmentation. Good lineage lets a team trace any model output back to the exact data versions and processing steps that produced it.

Usage documentation records why and how data is used. It covers the business purpose tied to the AI use case and the legal basis or consent for use. It also notes licensing terms, retention limits, access permissions, and known restrictions on sensitive attributes such as personally identifiable information. Datasheets for datasets, data cards, and data catalogs are common formats.

For audit, these records provide evidence that the project complies with regulations such as GDPR and the EU AI Act, as well as internal governance policies and ethical commitments. Auditors, regulators, and stakeholders can then verify several things:

- Data was obtained lawfully.
- Bias risks were assessed.
- Quality checks occurred.
- Data was used only for approved purposes.

Lineage also supports reproducibility, root-cause analysis when models drift or fail, and impact analysis when a source changes or must be deleted.

The project manager's responsibilities include:

- Defining documentation standards early.
- Assigning data stewards.
- Using version control and metadata tools.
- Logging approvals and changes.
- Keeping records updated through iterations, since CPMAI is iterative.

Treating lineage as a planned deliverable, not an afterthought, reduces compliance risk. It builds trustworthy AI and keeps the project ready for any internal or external audit.

In the PMI-CPMAI framework, the Identify Data Needs work, which corresponds to CPMAI Phase II (Data Understanding), requires the project manager to confirm that available data can support the AI solution before model development begins. Data quality is assessed across several dimensions. Three of the most critical are accuracy, completeness, and consistency, because AI systems learn directly from data and amplify its flaws ('garbage in, garbage out').

Accuracy is the degree to which data correctly represents the real-world entities or events it describes. Inaccurate data includes wrong values, mislabeled training examples, sensor errors, and outdated records. In supervised learning, label accuracy is especially important. If images or transactions are tagged incorrectly, the model learns the wrong patterns. Project managers should ask several questions: How was the data captured? Who labeled it, and how was labeling verified? What error rate is tolerable for the business objective?

Completeness measures whether all required data is present. This covers missing fields and null values. It also covers missing records and gaps in coverage, such as underrepresented customer segments, time periods, or edge cases. Incomplete data can bias models and reduce their ability to generalize. It also raises fairness concerns when certain populations are absent. Teams must decide whether to collect more data, impute values, augment the dataset, or narrow the project scope.

Consistency means data is uniform and free of contradictions within and across sources. Examples of inconsistency include different date formats, units of measure, or category codes. Another example is the same customer having conflicting addresses in two systems. Inconsistent data increases preparation effort and introduces noise that degrades model performance.

For the CPMAI practitioner, evaluating these dimensions supports a go/no-go decision on data readiness. It also shapes estimates for Data Preparation effort, cost, and timeline, and it surfaces risks early. Quality findings should be documented, tied to measurable thresholds, and revisited iteratively, since CPMAI is an agile, iterative methodology in which poor data quality is a leading cause of AI project failure.

In PMI-CPMAI, Identify Data Needs aligns with the Data Understanding phase of the CPMAI methodology. It confirms that available data can actually support the AI solution defined during Business Understanding. Three related concepts are central here: data distributions, bias, and gaps.

Data distributions describe how values are spread across features, classes, time periods, and populations. Project managers should check whether training data reflects the real-world conditions the model will face in production. Key checks include class balance (for example, rare fraud cases compared with normal transactions), ranges and outliers, seasonality, and geographic or demographic coverage. A mismatch between training and production distributions, often called data drift or distribution shift, is a leading cause of AI failure after deployment. Profiling data early with statistics and visualizations sets realistic performance expectations.

Bias is systematic distortion that leads to unfair or inaccurate outcomes. Common sources include sampling bias (some groups are underrepresented), historical bias (past discriminatory decisions embedded in the data), measurement bias (inconsistent collection methods), labeling bias (subjective or inconsistent annotators), and selection bias (data chosen for convenience). CPMAI stresses Trustworthy AI, so bias assessment is an ethical, legal, and reputational requirement, not just a technical step. Teams should document protected attributes and proxy variables, involve diverse stakeholders, and define fairness metrics before modeling starts.

Data gaps are missing elements needed to meet project objectives. They can be missing records, absent features, insufficient volume, poor labeling, limited history, or no access because of privacy, licensing, or ownership limits. Gap analysis compares the data required against the data available. The results drive go or no-go decisions, budgets for data acquisition or labeling, synthetic data or augmentation strategies, and possible scope changes.

For the project manager, the key outputs are a data inventory, a data quality and bias assessment, a documented gap analysis with mitigation plans, and an updated risk register. Revisiting these iteratively helps the AI project avoid the common failure of starting modeling on data that cannot support the business goal.

In the PMI-CPMAI framework, the Identify Data Needs activity, rooted in the CPMAI Data Understanding phase, requires project managers to confirm that training data is not only available but also fresh and relevant to the business problem defined earlier. Data Freshness is how current the data is compared with the real-world conditions the AI model will face in production. Customer behavior, market prices, fraud patterns, language use, and sensor environments all change over time. A model trained on stale data learns outdated patterns. This causes data drift, where input distributions shift, and concept drift, where the relationship between inputs and outcomes changes. Both reduce accuracy after deployment. Project managers should define acceptable data age, appropriate lookback windows, and update frequency. They should also plan pipelines that deliver timely data and set retraining triggers tied to monitored performance. Data Relevance is whether the data actually represents the problem, population, and context the model must serve. Relevant data contains the features, labels, and granularity needed to support the target prediction or pattern. It also reflects the operational environment, including the geographies, customer segments, devices, and edge cases involved. Large volumes of irrelevant or misaligned data add noise, increase cost, and can introduce bias without improving results. Relevance also means honoring scope. Teams should avoid collecting data that is unnecessary or that raises privacy, ethical, or compliance concerns. Freshness and relevance are linked. Historical data may still be relevant if the underlying patterns are stable, but it becomes harmful when conditions have fundamentally changed, as during a pandemic or a regulatory shift. PMI-CPMAI encourages iterative go/no-go checkpoints. If fresh, relevant data cannot be obtained, the team should revisit the business understanding or adjust project scope rather than proceed. Ensuring these qualities early reduces rework, supports trustworthy AI, and helps the deployed model keep delivering business value over time.

In PMI-CPMAI, Identify Data Needs ties the AI pattern selected during Business Understanding to the data required to build it. Data Schema and Structure for Modeling Compatibility asks whether the available data is organized in a way the intended model can actually consume. A schema is the blueprint of a dataset: its fields or attributes, data types (numeric, categorical, text, date-time, binary), allowed values, keys, relationships, and constraints. Structure describes the overall form of the data: structured (relational tables), semi-structured (JSON, XML, logs), or unstructured (images, audio, free text).

Compatibility matters because each AI pattern and algorithm expects specific inputs. Predictive analytics on tabular data needs consistent rows and columns, a clearly defined target variable, and features at the right granularity, such as one row per customer or per transaction. Recognition patterns need labeled images or audio in consistent resolutions and formats. Conversational and NLP systems need tokenizable text corpora. Time-series forecasting needs timestamped, evenly spaced sequences. A mismatch, such as data at the wrong level of aggregation, missing keys for joining sources, or inconsistent units and encodings, can stall the project or quietly degrade model quality.

Project managers should confirm several things. First, that data dictionaries and metadata exist and are accurate. Second, that schemas are consistent across sources and over time, so that schema drift does not break pipelines. Third, that labels, or a way to generate them, are available for supervised learning. Fourth, that the schema used for training will match the data the model receives in production. They should also estimate the transformation effort needed, such as flattening nested records, encoding categories, normalizing formats, or reshaping data into tensors.

Assessing schema and structure early supports a realistic go or no-go decision, accurate scoping of Data Preparation work, and reduced risk. Because CPMAI is iterative, this assessment is revisited as data understanding deepens, keeping the data aligned with both the model requirements and the business objective.

In the PMI-CPMAI framework, Exploratory Data Analysis (EDA) is a core activity in the Identify Data Needs domain, which aligns with Phase II (Data Understanding) of the CPMAI methodology. After the business problem and AI pattern are defined in Phase I (Business Understanding), EDA helps the project team examine available data and decide whether it can realistically support the intended AI solution. It works as a reality check before significant time and money go into data preparation and model development.

EDA is the systematic investigation of datasets to understand their structure, content, quality, and relationships. Key activities include profiling data types, volumes, and sources; calculating summary statistics such as mean, median, variance, and distributions; and identifying missing values, duplicates, outliers, and inconsistencies. Teams also explore correlations and patterns between variables, check class balance for classification problems, and use visualizations such as histograms, scatter plots, box plots, and heat maps.

From a CPMAI perspective, EDA directly informs go/no-go decisions. It shows whether the data has enough quantity, quality, relevance, and representativeness to meet the business objectives. It also exposes gaps that may require new data collection, third-party data acquisition, or labeling efforts. EDA reveals potential bias, privacy concerns, and compliance risks that matter for trustworthy and responsible AI. Its findings help the team estimate the effort needed for data cleansing, transformation, and feature engineering in Phase III (Data Preparation).

EDA also supports the iterative, data-centric nature of CPMAI. If the analysis shows that the data cannot support the original goal, the team should loop back to Business Understanding to refine scope, adjust the AI pattern, or reset expectations with stakeholders. This avoids a common cause of AI project failure, which is building on poor or insufficient data.

In short, EDA turns raw data into actionable insight about data readiness. It reduces project risk and ensures that data needs are clearly identified, documented, and aligned with business value before modeling begins.

In the PMI-CPMAI methodology, Identify Data Needs falls within the Data Understanding phase, which follows Business Understanding. Once the team has defined the AI problem, the chosen AI pattern (such as recognition, predictive analytics, or conversational systems), and the success criteria, it must decide whether the organization actually has the data to support the solution. Comparing available data against requirements is essentially a data gap analysis. It is one of the most important checkpoints in the project, because CPMAI stresses that AI projects fail more often because of data problems than because of algorithm problems.

The process starts with a clear statement of data requirements drawn from the business objective. These include the types of data needed (structured, unstructured, images, text, sensor streams), the volume required for training and validation, the features and attributes, labeling needs for supervised learning, granularity, timeliness, historical depth, and the representativeness needed to avoid bias. The team then inventories the data that actually exists, both internal and external, and assesses each source against the requirements. Key dimensions to evaluate are:

- Quantity: is there enough data?
- Quality: is it accurate, complete, and consistent?
- Relevance and coverage: does it represent the real-world scenarios and edge cases?
- Accessibility: is it available, in usable formats?
- Ownership and licensing: does the organization have rights to use it?
- Compliance: does it meet privacy, security, and regulatory obligations?
- Labeling: is it labeled, or what would labeling cost?

The gaps found drive decisions. Options include acquiring third-party data, creating new data collection processes, labeling or augmenting existing data, generating synthetic data, narrowing the project scope, or going back to Business Understanding to reframe the problem. CPMAI is iterative, so this comparison supports a go or no-go decision. If the data gaps are too large or too costly to close, the project manager should pause or redefine the effort before investing in model development. This reduces risk, controls cost, and keeps stakeholder expectations realistic.

In the PMI-CPMAI framework, Identify Data Needs is the stage where teams confirm that the right data exists, in sufficient form, before committing to model development. CPMAI treats AI projects as data-centric, so data sufficiency is a critical go/no-go checkpoint. Data sufficiency means having enough relevant, high-quality, representative data for a model to learn real patterns and perform reliably in production. It covers four areas. First, volume. The amount of data needed depends on problem complexity, the algorithm, and the number of features and classes. Deep learning usually needs far more examples than simpler statistical methods. Too little data leads to overfitting and poor generalization. Second, coverage and representativeness. The data must reflect the full range of conditions the model will face, including edge cases, seasonal variation, and rare but important events. It must also cover all relevant demographic or operational segments. Gaps here cause biased or brittle models that fail when real-world inputs shift. Third, balance and labeling. For supervised learning, teams need enough accurately labeled examples for each class, especially minority classes such as fraud or defects. Labeling cost, consistency, and expert availability must be assessed early. Fourth, quality and timeliness. Data that is plentiful but noisy, incomplete, duplicated, or outdated does not count as sufficient. Recency matters when patterns drift over time. Project managers verify sufficiency in several ways. They profile available data sources and compare them against the requirements defined in Business Understanding. They also run small proofs of concept and use learning curves to estimate whether more data would improve performance. When gaps appear, options include gathering more data, data augmentation, synthetic data, transfer learning, third-party sources, or narrowing the project scope. Governance factors also matter: privacy, consent, licensing, and access rights. Data that cannot be legally or ethically used is not sufficient, however large it is. Confirming sufficiency early reduces project risk, prevents costly rework, and supports trustworthy, robust AI outcomes aligned with business objectives.

In the PMI-CPMAI methodology, the Identify Data Needs work sits mainly in the Data Understanding phase, which follows Business Understanding. Here the project team compares the data the AI solution requires with the data the organization actually has. A data gap is any shortfall between the two. Unaddressed gaps are a leading cause of AI project failure, so CPMAI treats them as a key input to go/no-go decisions.

Common types of data gaps include:
- Quantity: too few examples to train or validate a model, especially for rare events.
- Quality: missing values, errors, duplicates, inconsistent formats or outdated records.
- Coverage and representativeness: data that omits key populations, scenarios or time periods, which can introduce bias.
- Labeling: raw data exists but lacks the ground-truth labels needed for supervised learning.
- Access and ownership: data is siloed, held by third parties or restricted by contracts.
- Compliance and ethics: privacy laws, consent limits or sensitive attributes restrict how data can be used.
- Timeliness: data is not available at the speed or frequency the solution needs in production.

Remediation strategies include:
- Acquire: source data internally, buy third-party datasets, use open data or form data-sharing partnerships.
- Collect: add instrumentation, sensors, forms or logging to capture new data.
- Label: use subject-matter experts, crowdsourcing, labeling tools, active learning or weak supervision.
- Augment or synthesize: apply data augmentation or generate synthetic data to fill sparse areas.
- Clean and transform: profile, cleanse, deduplicate, impute and standardize the data.
- Mitigate bias: rebalance or resample datasets, or collect targeted data for underrepresented groups.
- Reduce data needs: use pretrained models, transfer learning or simpler algorithms.
- Rescope: narrow the problem, change the AI pattern, or decide not to proceed.

Project managers should document gaps and remediation actions in a data plan. That plan should estimate the cost, time and risk of each action and secure governance approval. Because CPMAI is iterative, the team should reassess gaps as understanding grows, returning to Business Understanding when a gap makes the original objective infeasible.

In the PMI-CPMAI framework, Data Representativeness for Target Use Cases is a key consideration within the Identify Data Needs domain. It means the data used to train, validate, and test an AI solution must accurately reflect the real-world conditions, populations, and scenarios the model will face once deployed. A model learns patterns only from the data it sees. If that data is skewed, incomplete, or drawn from a different context than the intended use case, the model will perform poorly or unfairly in production, even if it scores well during development.

Assessing representativeness starts with clearly defining the target use case during Business Understanding: who the end users are, what decisions the AI will support, which geographies, demographics, time periods, devices, or operating conditions apply, and which edge cases matter. The project manager then works with data owners and subject matter experts to compare available data sources against these requirements. Key questions include: Does the data cover all relevant subgroups and classes in realistic proportions? Are rare but critical events, such as fraud cases or equipment failures, sufficiently captured? Is the data current enough to reflect present behavior, or has drift occurred? Was it collected in a way that introduces sampling, selection, or historical bias?

Gaps in representativeness create risks to model accuracy, generalization, fairness, regulatory compliance, and stakeholder trust. Mitigation strategies include acquiring additional data sources, targeted data collection, stratified sampling, data augmentation, synthetic data generation, reweighting, or narrowing the project scope to match the data that is actually available. Findings should be documented in data requirements and risk registers, and they should feed go/no-go decisions.

CPMAI emphasizes iteration. Representativeness is revisited in later phases, during model evaluation and after operationalization, through monitoring for data drift. This helps the AI solution continue to serve its intended population and business objectives responsibly over time.

In the PMI-CPMAI framework, which builds on the iterative CPMAI methodology, Identify Data Needs sits within the Data Understanding phase. It follows Business Understanding and precedes Data Preparation. A Go/No-Go decision on data readiness is a formal checkpoint. At this point the project team and stakeholders decide whether the available data can realistically support the AI solution defined in the business problem. Because AI systems are fundamentally data-driven, this decision is one of the most critical gates in the lifecycle. Many AI projects fail not because of algorithms but because of inadequate data.

The decision evaluates several dimensions. Quantity asks whether there is enough data, including enough labeled examples for supervised learning. Quality covers accuracy, completeness, consistency and the level of noise or missing values. Relevance asks whether the data actually represents the problem and the chosen AI pattern, such as recognition, prediction or conversational. Accessibility asks whether the data can be legally and technically obtained, integrated and stored. Governance and compliance cover privacy, consent, security, regulations such as GDPR, and data ownership. Bias and representativeness ask whether the data reflects the target population fairly. Cost and time ask whether acquisition, labeling and cleansing are feasible within budget and schedule.

A 'Go' indicates the data is sufficient, or that gaps can be closed with acceptable effort through data acquisition, augmentation, synthetic data or labeling. In that case the project proceeds to Data Preparation. A 'No-Go' signals unacceptable risk. The team may then iterate back to Business Understanding to rescope the problem, pursue alternative data sources, choose a different AI pattern, or stop the project entirely.

PMI-CPMAI emphasizes that No-Go is not failure. It is responsible risk management that prevents wasted investment. The decision should be documented, evidence-based, and agreed upon by business, data and technical stakeholders. This supports transparency, trustworthy AI principles and alignment with the original business objectives.

In the PMI-CPMAI framework, the Identify Data Needs domain corresponds to the Data Understanding phase of the CPMAI methodology. In this phase, the project team checks whether the data an AI solution requires actually exists, can be accessed, and is fit for purpose. An Executive Summary of Data Assessment Findings is the concise document that turns this technical investigation into decision-ready insight for sponsors, business owners, and governance bodies.

Its purpose is to answer one central question: do we have the right data, in the right quantity and quality, to support the AI pattern and business objective defined earlier? Executives rarely need detailed profiling statistics. They need clarity on feasibility, risk, cost, and next steps.

A strong executive summary typically covers the following elements:

1. Business context: a restatement of the problem, the selected AI pattern (for example, recognition, prediction, or conversational), and the success criteria.

2. Data inventory: the key sources identified, their ownership, and how easy they are to access, whether internal, external, or third-party.

3. Quality and quantity evaluation: completeness, accuracy, consistency, timeliness, volume, and representativeness, often framed through the V's of big data (volume, variety, velocity, and veracity).

4. Gaps and risks: missing data, labeling needs, bias concerns, privacy and regulatory constraints, security issues, and licensing limitations.

5. Effort and cost implications: estimated work for data acquisition, cleansing, labeling, and pipeline creation.

6. Recommendation: a clear go, no-go, or pivot decision. This may involve narrowing scope, choosing a different AI pattern, or iterating back to Business Understanding.

The summary supports CPMAI's iterative, data-centric philosophy. Because most AI projects fail due to data problems rather than algorithms, this document acts as a critical checkpoint before teams invest in data preparation and modeling. It should be brief, often one or two pages, and written in plain language. Its findings should be quantified wherever possible and tied directly to business value. It must also be transparent about uncertainty and support trustworthy AI principles such as fairness and accountability.

Ultimately, the summary keeps stakeholders aligned, documents assumptions, and enables informed investment decisions.

In the PMI-CPMAI framework, the Identify Data Needs domain aligns with the Data Understanding phase of the CPMAI methodology. Here the project team works out whether available data can support the AI solution defined during Business Understanding. Visualizations and reports turn raw datasets into evidence that technical and business stakeholders can use to make go/no-go and scoping decisions.

Visualizations support exploratory data analysis (EDA). Common techniques include:
- Histograms and box plots, which reveal distributions, skew, and outliers.
- Bar charts, which expose class imbalance in classification targets.
- Scatter plots and correlation heatmaps, which suggest relationships between features and possible redundancy.
- Time-series plots, which show trends, seasonality, and data drift.
- Missing-value matrices, which show where gaps cluster.

These views help the team judge data against the 'V's of data: volume, variety, velocity, veracity, and value. They also surface quality issues, sampling bias, and fairness concerns early, before money is spent on modeling.

Reports formalize these findings. Typical artifacts include:
- Data profiling reports covering completeness, uniqueness, validity, and consistency.
- Data inventory and source catalogs.
- Data lineage and provenance summaries.
- Labeling readiness assessments.
- Gap analyses comparing the data the AI pattern requires with what actually exists.

Reports should also note privacy, security, licensing, and regulatory constraints, which supports trustworthy and responsible AI practices.

For the AI project manager, the key skill is not building the charts. It is making sure insights are communicated clearly and drive action. Good reports are tailored to the audience: executives need concise dashboards about feasibility and risk, while data scientists need detailed statistical detail. Findings may trigger decisions such as:
- Acquiring more data or using third-party sources.
- Generating synthetic data.
- Narrowing project scope.
- Returning to Business Understanding to redefine the problem, reflecting the iterative nature of CPMAI.

Ultimately, visualizations and reports reduce uncertainty, validate assumptions, and document data decisions for governance and auditability. This helps keep the AI initiative grounded in data reality rather than optimism, which is a leading cause of AI project failure.

In the PMI-CPMAI framework, Presenting Data Readiness to Stakeholders is a key activity within the Identify Data Needs domain, which aligns with the Data Understanding phase of the CPMAI methodology. After the team has identified the data an AI solution requires, located sources, and assessed their condition, the project manager must clearly communicate whether the data can realistically support the intended AI pattern and business objective. Because AI projects are data-centric, this presentation often serves as an important go/no-go checkpoint before significant investment in data preparation and model development.

An effective readiness presentation covers several dimensions. Availability and access explains which data exists, who owns it, and whether it can be obtained in time. Quantity addresses whether there is enough data, including sufficient labeled examples for supervised learning. Quality covers accuracy, completeness, consistency, timeliness, and representativeness, including potential bias. Governance and compliance addresses privacy, security, consent, licensing, regulatory constraints, and ethical or trustworthy AI considerations. Cost and effort estimates the work needed for cleansing, labeling, augmentation, or acquiring third-party data.

The project manager should translate technical findings into business language, tailoring the message to each audience. Executives need impact, risk, cost, and schedule implications. Data owners and IT need specifics on access and integration. Legal and compliance teams need clarity on sensitive data handling. Visual tools such as readiness scorecards, heat maps, and gap analyses help stakeholders grasp the situation quickly.

Transparency is essential. Gaps should be presented with options and recommendations, such as narrowing project scope, choosing a different AI pattern, collecting more data, using synthetic data, or delaying the project. Presenting unrealistic optimism risks failure later, which CPMAI aims to prevent through iterative, honest evaluation.

The outcome should be informed stakeholder decisions, documented assumptions and risks, secured commitments for data access and resources, and alignment on whether to proceed, iterate on business understanding, or stop. This reinforces trust and keeps the AI initiative grounded in data reality.

In PMI-CPMAI, the Identify Data Needs domain sits mainly in the Data Understanding phase of the CPMAI methodology. Its central idea is that AI projects are data projects. A key skill is translating technical data concepts into language business stakeholders can use to make decisions. Sponsors, product owners, and executives approve budgets, accept risk, and set priorities, but they rarely think in terms of feature engineering, data drift, or class imbalance. The AI project manager closes that gap.

Effective translation starts with business outcomes, not technical detail. Instead of saying the dataset has 30 percent missing values in key features, explain that nearly a third of customer records lack the information needed to predict churn, so forecasts may be unreliable for those customers. Instead of discussing labeled training data, describe the cost and time needed for experts to tag thousands of examples, and how that affects the schedule and budget.

Core concepts to translate include:

- Data quantity: whether there is enough history to support the pattern being predicted.
- Data quality: accuracy, completeness, and consistency, framed as risk to decision reliability.
- Data relevance and representativeness: whether the data reflects real customers or operations, linked to fairness and performance.
- Data access and ownership: legal, privacy, and contractual limits, framed as compliance and timeline risk.
- Labeling and preparation effort: often the largest hidden cost.

Useful techniques include analogies, visual data maps, concrete examples, and ranges of confidence instead of false precision. Tie every data gap to its impact on scope, cost, schedule, or risk. This lets stakeholders make informed go or no-go decisions, which CPMAI stresses before moving into data preparation and modeling.

Good translation also manages expectations. It makes clear that AI outcomes are probabilistic and depend on the data. This builds trust and prevents projects from failing because of unrealistic assumptions about data readiness. Ultimately, it aligns technical teams and business leaders on what data is needed, why it matters, and what it will take to obtain.

In the PMI-CPMAI methodology, Phase II: Data Understanding follows Business Understanding. It focuses on identifying, locating, and assessing the data needed to deliver the AI solution defined in Phase I. CPMAI treats AI projects as data-centric rather than code-centric, so this phase is often decisive: a well-defined business problem cannot be solved without the right data. Key questions include: What data is required for the chosen AI pattern (for example recognition, conversational, predictive analytics, patterns and anomalies, hyperpersonalization, autonomous systems, or goal-driven systems)? Does that data exist? Where is it stored, who owns it, and can the team legally and practically access it? Identifying data needs means turning business objectives into concrete data requirements. Teams list candidate internal and external data sources, then describe the data's type (structured, unstructured, or semi-structured), format, and granularity. They also evaluate it against the 'V's' of big data: volume (is there enough?), variety (how many formats and sources?), velocity (how quickly does it arrive or change?), and veracity (how accurate and trustworthy is it?). For supervised learning, teams check whether labeled data is available or whether labeling will be needed, and estimate the cost and effort involved. Phase II also covers data quality, completeness, representativeness, and potential bias, along with governance concerns such as privacy, security, consent, regulatory compliance, and ethical use. Practitioners explore and profile the data to spot gaps, outliers, and inconsistencies early. The main outputs are a documented inventory of data sources, an assessment of data quality and gaps, a record of access and compliance constraints, and an informed go/no-go decision. CPMAI is iterative, so if the data proves insufficient, the team may return to Business Understanding to rescope the problem rather than move forward on weak foundations. Catching data issues here prevents costly failures in later phases, which is why data problems are one of the most common reasons AI projects fail.

In the PMI-CPMAI framework, Data Governance Fundamentals for AI is a core part of the Identify Data Needs domain. AI systems depend on data, and data governance is the set of policies, roles, processes and controls that make sure data is accessible, trustworthy, secure, compliant and used ethically across the AI lifecycle. In CPMAI's data-centric approach, governance starts during Business Understanding and Data Understanding, before any model is built. Weak governance is a leading cause of AI project failure.

Key fundamentals include:

1. Ownership and stewardship: Define data owners, who are accountable for a dataset, and data stewards, who handle its day-to-day quality and use. Clear roles keep decisions about access, labeling and retention from stalling.

2. Data quality management: Set standards for accuracy, completeness, consistency, timeliness and relevance. AI amplifies data flaws, so quality criteria must be measurable and tied to the AI objective.

3. Lineage and provenance: Track where data originates, how it is transformed and who has modified it. This supports reproducibility, auditability and troubleshooting of model behavior.

4. Privacy, security and compliance: Identify personally identifiable or sensitive data and apply consent, anonymization, access controls and encryption. Ensure alignment with regulations such as GDPR, HIPAA, CCPA and emerging AI laws like the EU AI Act.

5. Ethical and responsible use: Assess datasets for bias, representativeness and fairness. Document the intended uses and limitations of each dataset.

6. Metadata and documentation: Maintain data catalogs, data dictionaries and datasheets so teams understand context, definitions and constraints.

7. Lifecycle management: Govern the collection, storage, versioning, retention and disposal of data, including training, validation and production data. This also supports monitoring for data drift.

For the AI project manager, applying these fundamentals means confirming early that the required data exists, can legally and ethically be used, is of sufficient quality and is governed by accountable stakeholders. Doing so reduces risk, builds trust and enables successful, iterative AI delivery.