Computational Resource Requirements and Constraints

Overview
In the PMI Cognitive Project Management for AI (PMI-CPMAI) methodology, the first phase, Identify Business Needs and Solutions (aligned with CRISP-DM's Business Understanding), asks the project team to decide early whether an AI solution is worth pursuing and whether it can be delivered. One key input to that decision is an honest assessment of Computational Resource Requirements and Constraints: the compute, storage, networking, tooling, and related budget needed to build, train, deploy, and run the AI solution, along with the limits that restrict those resources.

Why It Is Important
1. Feasibility gate: A technically elegant model is useless if the organization cannot afford or access the GPUs, cloud capacity, or edge hardware it needs. CPMAI stresses answering the question "Is this AI project feasible?" before heavy investment. Compute is one of the main feasibility dimensions, alongside data, skills, and business value.
2. Cost control and ROI: Training large models, hyperparameter tuning, and continuous retraining can consume large cloud budgets. Inference costs at scale often exceed training costs over the solution's life. Underestimating these costs damages the business case.
3. Avoiding project failure: Many AI projects fail because teams discover late that the infrastructure cannot support the data volumes, latency targets, or retraining frequency. Early identification prevents rework.
4. Scoping the right solution: Constraints shape the solution. A limit such as 50 ms on-device latency with no connectivity may rule out a large cloud model and point toward a smaller, optimized model or a non-AI approach.
5. Iterative delivery: CPMAI favors small, fast iterations. Knowing resource limits helps define a minimum viable model and a realistic first iteration instead of an oversized "boil the ocean" project.
6. Compliance and security: Data residency, privacy regulations, and security policies may forbid some cloud regions or third-party services. That limits where computation can happen.

What It Is
Computational resource requirements are the technical capacities the AI solution needs across its lifecycle:
- Processing power: CPUs, GPUs, TPUs, or specialized accelerators for data preparation, training, tuning, and inference.
- Memory and storage: RAM or VRAM for large models and datasets, plus storage for raw data, prepared data, feature stores, model artifacts, and versioned datasets.
- Networking and bandwidth: Moving large datasets, distributed training, and serving predictions to users or devices.
- Environment and tooling: ML platforms, MLOps pipelines, experiment tracking, containerization, orchestration, and model registries.
- Deployment target: Cloud, on-premises, hybrid, or edge/IoT devices, each with different capacity and cost profiles.
- Operational load: Expected inference volume, concurrency, peak loads, latency and throughput service levels, availability, and retraining frequency.

Constraints are the limits on those resources:
- Budget: Capital and operating expense caps, and cloud spend limits.
- Availability: GPU scarcity, procurement lead times, and shared cluster quotas.
- Organizational policy: Approved vendors, cloud restrictions, and security standards.
- Regulation: Data sovereignty, privacy (for example GDPR or HIPAA), and auditability requirements.
- Physical or edge limits: Power, size, memory, connectivity, and heat on devices.
- Time: Training windows and project deadlines.
- Skills: Staff capability to run distributed or specialized infrastructure.
- Sustainability: Energy consumption and carbon goals.

How It Works in Practice
Step 1: Start from the business need and the AI pattern. Identify which cognitive pattern applies, such as recognition, conversational, predictive analytics, patterns and anomalies, personalization, goal-driven systems, or autonomous systems. Recognition and conversational systems built on deep learning usually demand far more compute than a simple predictive regression model.

Step 2: Define non-functional requirements. Capture the following:
- Latency, such as real-time versus batch.
- Throughput, such as predictions per second.
- Scale, such as number of users or devices.
- Accuracy targets and retraining cadence.
These drive the compute sizing.

Step 3: Estimate resource needs across the lifecycle. Consider each stage:
- Data preparation, including ETL and labeling.
- Training and experimentation.
- Validation.
- Deployment and inference.
- Monitoring and retraining.
Remember that operationalization is continuous, not one-time.

Step 4: Inventory current capacity. Compare needs against existing infrastructure, cloud contracts, MLOps maturity, and team skills. Identify the gaps.

Step 5: Identify constraints and trade-offs. Document budget, regulatory, policy, and physical limits. Evaluate options such as:
- Using pre-trained models, transfer learning, or vendor APIs instead of training from scratch.
- Smaller or compressed models, using quantization, pruning, or distillation.
- Batch rather than real-time scoring.
- Cloud elasticity versus on-premises control.
- Edge deployment versus centralized processing.
- Phased scope, so the first iteration needs less compute.

Step 6: Feed the go/no-go decision. Include compute costs in the ROI and business case. If constraints make the solution infeasible, the correct CPMAI response is to:
- rescope the solution,
- choose a simpler approach,
- acquire resources, or
- decide not to proceed with AI.

Step 7: Revisit iteratively. CPMAI phases loop. Data Understanding may reveal larger data volumes, and Model Development may show a need for more complex models, so revisit requirements at each iteration.

Example
A retailer wants real-time product image recognition in stores with poor connectivity. Requirements include sub-second inference on in-store devices and a limited hardware budget per store. The constraints rule out large cloud-only models. Feasible options are:
- a pre-trained, compressed vision model deployed at the edge,
- periodic syncing for model updates, and
- a pilot in a few stores first.
If the hardware cost per store exceeds the expected value, the project should be rescoped or paused.

Common Pitfalls
- Planning only for training and ignoring ongoing inference and retraining costs.
- Assuming cloud resources are unlimited or free.
- Choosing the most complex model before confirming that simpler models meet the need.
- Ignoring data residency rules that restrict where processing can occur.
- Discovering edge or latency limits only during deployment.
- Overlooking the MLOps tooling and skills needed to run the infrastructure.

Exam Tips: Answering Questions on Computational Resource Requirements and Constraints
1. Think feasibility first. In this phase, the best answer usually assesses whether the organization can support the solution before building it. Pick the option that evaluates resources early over one that starts modeling immediately.
2. Business need drives technology. Prefer answers that derive compute requirements from business objectives and non-functional requirements (latency, scale, accuracy), not from a desire for the newest technology.
3. Choose the simplest adequate solution. When constraints are tight, the CPMAI-aligned answer is often a pre-trained model, a vendor service, a smaller model, batch processing, or reduced scope. Do not escalate to costly infrastructure first.
4. Remember the full lifecycle. Answers that account for inference, monitoring, and retraining (model drift) beat answers focused only on training.
5. Iterate small. Favor options that start with a pilot or minimum viable model sized to available resources, then scale. This reflects CPMAI's iterative, agile nature.
6. Respect non-technical constraints. Regulatory, privacy, security, and budget constraints are real constraints. An answer that violates data residency to get cheaper compute is wrong.
7. A no-go is a valid outcome. If a scenario shows resource needs far exceeding value or capacity, the right answer may be to rescope, find an alternative, or stop. CPMAI treats an early no-go as a success, not a failure.
8. Watch the keywords. Terms like real-time, edge, offline, millions of users, limited budget, sensitive data, or on-premises only signal which constraint the question tests.
9. Involve stakeholders. Correct answers often include consulting IT/infrastructure, finance, security, and compliance teams to validate requirements and constraints, not deciding alone.
10. Spot the phase. If the question describes the early phase (business understanding or feasibility), choose assessment and planning actions. Leave procurement or tuning actions for later phases unless the scenario clearly sits there.
11. Eliminate extremes. Discard answers that ignore cost entirely or assume unlimited resources. Also discard answers that abandon AI without first exploring alternatives.
12. Link to ROI. When asked how compute requirements affect the project, connect them to the business case: total cost of ownership versus expected value.

Quick Summary
Computational resource requirements and constraints define what infrastructure an AI solution needs and what limits apply. In CPMAI's first phase, assessing them early:
- determines feasibility,
- shapes the solution scope,
- protects ROI, and
- prevents late-stage failure.
On the exam, favor early, business-driven, lifecycle-aware, iterative, and constraint-respecting answers, and remember that rescoping or a no-go can be correct.