DCMA 14-POINTS

În 2005, Agenția americană de gestionare a contractelor de apărare a implementat o

evaluare a programelor de 14 puncte pentru a ajuta Departamentul Apărării să
evalueze volumul enorm de contracte și orare în care au fost însărcinați să gestioneze.

Anii mai târziu, evaluarea programelor de 14 puncte de la DCMA a devenit o orientare

care este utilizată pe scară largă și a fost încorporată în multe instrumente software
cum ar fi Acumen Fuse și Primavera P6 EPPM .

Dar ce anume este verificarea evaluării programelor de 14 puncte de la DCMA?

În esență, evaluează dacă un program este bine construit - fie că aderă la un set de
bune practici considerate importante pentru succesul și gestionarea unui
proiect. Aceste bune practici sunt împărțite într-o listă cu 14 verificări

1) Verificarea logicii
Este logica completă? Există link-uri care lipsesc. Știm cu toții că un program este o
rețea și dacă această rețea nu este completă din cauza lipsei logicii, nu este
posibilă o Cale Criticală precisă .

2) Cautam lideri
Negativele sunt adesea denumite "timpul de plumb". Neglijările negative pot provoca
tot felul de probleme. Plus ele pot fi confuze. Aici, obiectivul este să nu aveți niciun
decalaj negativ în programul dvs.

3) Căutați Lags
DCMA este un pic mai iertător atunci când vine vorba de decalajul pozitiv, dar scopul
aici este de a minimiza utilizarea lor în programul dumneavoastră. Scopul este că nu
mai mult de 5% dintre relații ar trebui să aibă un decalaj. Iată cum ați putea găsi aceste
decalaje .

4) Tipurile de relații corecte

P6 și alte tipuri de software suportă 4 tipuri de relații, dar asta nu înseamnă că trebuie
să construiți un program folosind doar relațiile Start-Start. Finish-Start este cel mai
bun. DCMA spune că programul dvs. ar trebui să utilizeze Finish-Start 90% din timp
(sau mai mult).

5) Cât despre aceste Constrângeri Hard

Constrângerile grele pot afecta cu adevărat logica (după cum v-am spus noi ) și pot
dezactiva un program de a fi logic. Spun că poți face fără constrângeri tari. DCMA
spune că nu au constrângeri greșite în mai mult de 5% din toate activitățile constrânse.

6) Reintroduceți flota dvs. totală

44 de zile este tot ce ai. Activitățile High Float pot să nu fie corelate corect și pot
provoca dezastru pe calea ta critică. Această verificare caută activități cu valori totale
ale plutitorului de peste 44 de zile. Din nou, obiectivul este că mai puțin de 5% din
activități pot avea valori Float de 44 de zile sau mai mult.

7) Float negativ nu este niciodată bun

Dacă urmăriți aceste verificări până aici, este posibil să nu aveți o problemă cu Floating
Negative. În mod ideal, DCMA spune că evitați să aveți în planul tău Negative
Float. Dacă faceți asta, asigurați-vă că ați documentat un plan de atenuare a întârzierii.

8) Împărțiți aceste durate lungi

Când este o activitate prea lungă? Când este mai mult de 2 luni, spune oamenii de la
DCMA. Veți dori să limitați activitățile de lungă durată la maximum 5% din totalul
activităților. Sau doar rupeți aceste activități lungi într-o serie de cele mai scurte pentru
mai multe detalii.

9) Verificați datele nevalabile

Nu Data actuală în viitor, dincolo de Data Data; și nu există date anticipate din trecut
înainte de Data Data. Primavera P6 poate să nu permită unele dintre aceste condiții,
dar amintiți-vă că aceste verificări pot fi aplicate la un program construit în orice pachet
software.
10) Încărcați-l cu resurse și costuri
DCMA îi place programele să fie resurse și costuri. Și dacă urmăriți și această cale,
asigurați-vă că nu veți lăsa activități funcționale; nu sunt incluse.

11) Slippage Activity Subvert

Cu toții vrem să livrăm la timp. Acest control analizează câte activități au terminat cu
întârziere față de linia de bază. Este o verificare generică bună pentru a vedea dacă
proiectul dvs. va fi livrat la timp sau nu.

12) Integritatea căii critice

Cea de-a 12-a verificare este cea care testează integritatea cursei critice a programului
dvs. , căutând fluiditatea condusă de o legătură logică bună. Aici, DMCA verifică faptul
că introducerea unei întârzieri în rezultatele programării în data finalizării proiectului
este întârziată în mod egal.

13) Indicele lungimii căii critice (CPLI)

Acest control este un pic dificil de explicat. Am amânat explicația lui Ron Winter, care a
rezumat astfel:

"Indicele Lungimii Calei Critice (CPLI) este unul dintre" verificările Wire Trip ", care ar
trebui să evalueze realismul finalizării proiectului la timp. Cei mai mulți planificatori de
construcții vor găsi acest test un pic bizar. Vom măsura raportul dintre lungimea
parcursului critic al proiectului și floatul total al proiectului la lungimea parcursului critic
al proiectului. Lungimea căii critice este timpul în zilele lucrătoare de la data de stare
curentă până la "sfârșitul programului". Numărul țintă este 1,0 cu o valoare mai mică de
95% ca fiind un eșec. "

Mulțumesc, Ron.

14) Indicele de execuție de bază (BEI)

Indicele de execuție de bază este menit să vă ajute să înțelegeți cât de bine lucrați
împotriva liniei de bază a proiectului. BEI rezumă câte activități sunt înaintea sau în
spatele graficului în raport cu linia de bază. Un BEI de 1.0 înseamnă că ești pe drumul
cel bun. DCMA spune că un BEI de mai puțin de 0,95 vă pune la cunoștință.

Puteți obține mai multe informații de la DCMA cu privire la verificarea programului de

14 puncte aici .
Așadar, trebuie să utilizați aceste linii directoare așa cum sunt prezentate de DCMA?

Există opinii diferite cu privire la această întrebare. Cele mai multe dintre aceste
orientări sunt acceptate ca cele mai bune practici pentru practicienii din multe
industrii. Cele mai multe dintre acestea sunt ușor de verificat manual în cadrul
Primavera P6, cu excepția ultimelor 3 care sunt puțin mai implicate.

Indiferent dacă credeți că verificările efectuate de DCMA au un rezultat bun sau nu,
sunt destul de sigur că vom vedea mai multe dintre ele în viitor, deoarece tot mai multe
instrumente încep să le pună în aplicare în software.