Nimeni nu v-a spus că proiectele AI sunt diferite. Și asta e o problema.

 Când am început să lucrez cu echipe care implementau soluții AI, am observat ceva ciudat.

Toți știau să facă managementul de proiect. Unii erau certificati PMP. Alții lucrau în Agile de ani de zile. Oameni competenți, cu experiență reală.

Și totuși — proiectele AI eșuau.

Nu spectaculos. Nu cu un incident dramatic.

Ci lent, pe nesimțite, în felul cel mai frustrant posibil: proiectul părea să meargă bine, stakeholderii erau mulțumiți, modelul AI era pus in “live”, deployed pe mediile de productie— și apoi, undeva între trei și nouă luni mai târziu, lucrurile începeau să se strice.

Predicții din ce în ce mai slabe. Reclamații de la utilizatori. Nimeni care să înțeleagă exact de ce.

Ce se întâmpla de fapt

Am stat mult să mă gândesc la asta. Și răspunsul e simplu, chiar dacă nu e comod:

Proiectele AI nu sunt proiecte software.

Sună banal. Dar implicațiile sunt profunde — și majoritatea companiilor care implementeaza solutii AI,  nu le-au înțeles încă.

Când livrați un sistem software, există o relație directă și previzibilă între codul sursa scris de programatori și ce face sistemul. Un bug e un bug. Îl găsești, îl repari, îl declari finalizat. Calitatea e măsurabilă, reproductibilă, controlabilă.

Un model AI nu funcționează așa.

Un model AI functioneaza probabilistic, produce probabilistic outputs. Nu răspunsuri. Nu certitudini. Ci, intervale de probabilitate. Un model de clasificare cu 93% acuratețe înseamnă că 7 din 100 de predicții sunt greșite — și nu știți care 7. Un sistem AI (recommendation engine) care funcționează excelent în octombrie poate produce recomandări mediocre în martie, nu pentru că cineva a stricat ceva, ci pentru că comportamentul utilizatorilor s-a schimbat imperceptibil (data drift, model drift).

Adăugați la asta cel mai mare mister al proiectelor AI: datele sau data, daca va place in engleza.

În proiectele software, datele sunt  input. Le primești, le procesezi, le afișezi. În proiectele AI, datele sunt este materie primă — ca argila unui olar. Calitatea lor, cantitatea, modul în care au fost colectate și etichetate (labeling) — toate astea determină dacă modelul tău AI va funcționa sau nu, mai mult decât algoritmul ales, mai mult decât puterea de calcul, mai mult decât orice altceva.

Și nimeni nu vă spune asta la cursul de PMP sau in Agile.

Momentul în care am înțeles că lipsea ceva

Am văzut echipe care aplicau Agile la proiecte AI. Sprint-uri bine definite, backlog îngrijit, retrospective regulate. Și totuși — undeva în Sprint 4 sau 5, când pregatirea datelor (data preparation) se dovedea de trei ori mai complexă decât a fost estimat, tot planul se prăbușea.

Am văzut echipe care aplicau Waterfall. Cerințe detaliate, analiză completă, plan solid. Și totuși — în momentul în care au descoperit că datele disponibile nu aveau calitatea necesară pentru modelul planificat, s-au trezit că trebuie să reia totul de la zero.

Problema nu era că oamenii nu știau să facă management de proiect. Problema era că aplicau framework-uri de management de proiect concepute pentru o realitate diferită.

Un proiect AI nu eșuează pentru că echipa e incompetentă. Eșuează pentru că are nevoie de o abordare diferită.

CPMAI™ — harta pentru teritoriul AI

CPMAI™ (Cognitive Project Management in Artificial Intelligence) este metodologia dezvoltată de Project Management Institute special pentru proiectele de AI și Machine Learning.

Nu e o adaptare a altceva. Nu e Agile cu câteva slide-uri despre AI adăugate la final. E o metodologie construită pornind de la întrebarea: cum arată, de fapt, un proiect AI bine condus?

Răspunsul e structurat în șase faze — și fiecare fază adresează o vulnerabilitate specifică pe care framework-urile tradiționale (waterfall, Agile, Hibrid) o ignoră.

Faza I — Business Understanding

Înainte de orice model, înainte de orice date, înainte de orice decizie tehnică — o întrebare simplă și incomodă:

Avem nevoie cu adevărat de AI pentru asta?

Business Understanding nu este o formalitate. Este momentul în care definiți ce înseamnă succesul în termeni de business — nu în termeni tehnici. Ce KPI-uri îmbunătățim? Cu cât? La ce riscuri de eroare suntem dispuși să ne expunem?

Include și primul Go/No-Go Assessment din CPMAI: nouă factori evaluați sistematic printre care — fezabilitate de business, date disponibile, capacitate de execuție. Mulți bani s-ar fi economisit dacă echipele ar fi aplicat acest filtru înainte să înceapă.

Una dintre metodele mele preferate din această fază: AI Pattern Identification. Există șapte tipare fundamentale de soluții AI — Recognition, Predictive Analytics, Conversational, Anomaly Detection, Goal-Driven Systems, Autonomous Systems, Hyper-Personalization. Să știi din start în ce categorie se încadrează problema ta simplifică enorm tot ce urmează in implementarea de AI.

Faza II — Data Understanding

Dacă Business Understanding răspunde la ce vrem să facem, Data Understanding răspunde la cu ce o vom face.

Și de foarte multe ori, răspunsul e: cu mai puțin decât credeam.

Data Understanding este faza în care confruntati realitatea datelor disponibile cu cerințele modelului pe care vreți să-l construiți. Volum, varietate, calitate,  acuratețea etichetelor (labeling) — toate intră în ecuație. Rezultatul este un Data Quality Report cinstit: ce aveți, ce lipsește, ce trebuie transformat.

O întrebare pe care puțini și-o pun aici: există modele deja facute ( foundation models) sau seturi de date deja disponibile (third-party) care ne-ar economisi luni de muncă? Uneori răspunsul e da — și merită investigat serios înainte să construiți de la zero.

Faza III — Data Preparation

Vă spun direct: aceasta este faza pe care toată lumea o subestimează și pe care o veți trăi cel mai intens.

Data preparation — data selection, data cleansing, data enhancement, data labeling — consumă în mod tipic între 60% și 80% din efortul tehnic al unui proiect AI. Nu este o exagerare. Este o realitate pe care o vei descoperi personal dacă nu ai descoperit-o deja.

Livrabilul critic din această fază nu sunt datele pregatite pentru utilizare (clean data). Este pipeline-ul documentat și reproductibil. Pentru că modelul va trebui re-antrenat (retrained). Datele vor trebui reprocesate. Dacă procesul există doar în memoria unui singur data engineer, ai un risc de proiect — nu un flux de lucru.

Faza IV — Model Development

Aceasta este faza în care persoanele specializate pe date (de ex. data scientists) lucrează. Managerul de proiect nu construiește modele — dar gestioneaza procesul.

Ce înseamnă asta concret? Să înțelegeți suficient din sistemele AI pentru a pune întrebările corecte. Să știți când să aprobați o decizie de algoritm și când să cereți mai multă justificare. Să evaluați compromisurile între acuratețe, interpretabilitate și costul de inferență.

Nu trebuie să știți să scrieți cod in Python. Dar trebuie să înțelegeți diferența dintre supervised learning, unsupervised learning și reinforcement learning — și ce implicații are fiecare pentru planificarea proiectului. Trebuie să știți ce este hyperparameter optimization și de ce poate extinde durata proiectului cu săptămâni. Trebuie să înțelegeți când AutoML e o soluție rezonabilă și când e o scurtătură periculoasă.

Faza V — Model Evaluation

Acesta este momentul în care mulți manageri de proiect se simt cel mai inconfortabil — și pe bună dreptate.

Cum evaluezi un model AI? Ce metrici contează? Ce înseamnă accuracy de 91% — e bine sau e periculos? Depinde de context. Un model de recomandare de filme cu 91% accuracy e excelent. Un model de detecție a tumorilor medicale cu 91% accuracy e complet inacceptabil.

Model Evaluation în CPMAI nu este o decizie tehnică. Este o decizie de business. Sunteți voi, ca manager de proiect, cei care traduceți termenii de  precision, recall, F1 score în limbaj pe care stakeholderii îl pot înțelege — și cei care facilitați decizia: mergem mai departe sau nu?

Inca un momement de  Go/No-Go din CPMAI. Poate cel mai important.

Faza VI — Model Operationalization

Faptul ca aplicatia AI este “live” pe mediile de productie (Deployed) nu este linia de finish. Este punctul în care proiectul tău AI devine un produs viu — și  înseamnă că poate să se degradeze.

Model drift este realitatea pe care nimeni nu vrea să o discute în faza de planificare: modelul AI tău va performa mai slab în timp, pe măsură ce datele reale se îndepărtează de datele de antrenare. Dacă nu ați construit un sistem de monitorizare și un mecanism de re-antrenare (retraining), nu ați terminat proiectul. Ați creat o problema tehnică (technical debt) programată.

Faza VI acoperă strategia de deployment (batch, real-time API, edge, cloud, on-premise), integrarea cu sistemele existente, change managementul pentru utilizatorii finali — și mai ales framework-ul de management post-deployment: cine monitorizează, ce monitorizează, când se declanșează re-antrenarea modelului, cine aprobă noua versiune.

Ce face CPMAI™ diferit față de orice altceva

Trei lucruri.

Primul: Este construit în jurul datelor, nu al funcționalităților. În Agile, User Story-urile descriu ce face sistemul. În CPMAI, Data Understanding și Data Preparation sunt faze de sine stătătoare — pentru că datele sunt prima constrângere a oricărui proiect AI.

Al doilea: Proiectul este iterativ prin design, nu prin adaptare. CPMAI nu pretinde că proiectele AI urmează un flux liniar. Echipele revin din Faza III în Faza II, din Faza V în Faza IV, din Faza VI în Faza I. Aceasta nu este o excepție — este norma. Și metodologia CPMAI este construită să o acomodeze.

Al treilea: Aceasta metodologie CPMAI este proiectata pentru manageri, nu pentru data scientists. CPMAI nu vă va învăța să construiți modele. Vă va învăța să gestionati procesul prin care modelele AI sunt construite — și asta e o competență complet diferită, la fel de valoroasă.

O observație sinceră, la final

Există o tentație, în lumea managementului de proiect, de a trata orice metodologie nouă cu scepticism. Și e un scepticism sănătos — industria a suferit destule fad-uri.

CPMAI™ nu este un fad.

Este răspunsul pragmatic la o problemă reală: organizațiile investesc milioane în AI și pierd o bună parte din acei bani, nu pentru că AI nu funcționează, ci pentru că nu știu cum să-l faca managementul acestei sistem.

Dacă conduceți proiecte de AI — sau dacă compania voastră plănuiește să o facă — această metodologie merită atentia si timpul vostru. Nu pentru că este nouă sau pentru că vine de la PMI. Ci pentru că adresează probleme reale pe care le veți întâlni, indiferent dacă aveți un framework sau nu.

Diferența e că, cu CPMAI™, le veți anticipa.

Trilex Training este PMI® Authorized Training Partner și livrează trainingul Managing AI Projects with CPMAI™ Methodology în România, cu pregătire pentru certificarea PMI-CPMAI™.