Ansaitun arvon hallinta puolustusalan ohjelmistoihin

Ansaitun arvon hallinta sijoittuu kustannuslaskennan, aikataulunhallinnan ja ohjelmavalvonnan risteykseen — ja se on yksi vaativimmista vaatimustenmukaisuusjärjestelmistä, joita puolustusalan ohjelmistotoimittaja kohtaa. Ohjelma ilman uskottavaa EVMS:ää ei voi voittaa kustannusperusteisia sopimuksia DoD:n kynnysarvon yläpuolelta. Ohjelma, joka raportoi EVM-dataa huolimattomasti, laukaisee DCMA:n valvonnan, korjaavien toimenpiteiden pyynnöt ja lopulta menneisyyssuorituskykyyn kohdistuvat seuraukset. Mutta ohjelma, joka käyttää EVM:ää aitona johtamisvälineenä — ei vain raportointivelvoitteena — saa kvantitatiivisen ennakkovaroituksen kustannus- ja aikatauluongelmista kuukausia ennen kuin niistä tulee kriisejä.

Tämä opas kattaa koko EVMS-elinkaaren ohjelmistopainotteisille puolustusohjelmille: matematiikan, jota jokaisen CAM:n on hallittava, 32 ANSI/EIA-748-kriteeriä, jotka jäsentävät EVMS-vaatimustenmukaisuuden, MIL-STD-881:een linjatun WBS-rakenteen, IBR-valmistelun ja -toteutuksen, CAM-raportointiaikataulun ja varianssianalyysin, EAC-laskentamenetelmät sekä työkaluekosysteemin hallituksen tietojen toimittamista varten. Laajemmassa sopimusten täytäntöönpanon kontekstissa katso artikkelia puolustusmarkkinoiden käsikirja osa 4: sopimuksen täytäntöönpano ja EVM. Hinnoittelurakenteiden osalta, jotka määrittävät mitkä sopimuslajit edellyttävät EVMS:ää, katso puolustusalan ohjelmistojen hinnoittelumallit. Hankintapolun osalta, joka johtaa EVMS-sopimuksiin, katso puolustushankinta: tarjouspyynnöstä sopimukseen.

EVM:n perusteet puolustusalan ohjelmapäälliköille

EVM perustuu kuuteen lukuun. Jokainen kustannustilin vastaava, ohjelmapäällikkö ja hallituksen tarkastaja lukee nämä kuusi mittaria joka kuukausittaisella statussyklillä. Niiden merkityksen — ja sen, mitä ne eivät tarkoita — hallitseminen on koko oppialan perusta.

Suunniteltu arvo (PV) — aiemmin BCWS (Budgeted Cost of Work Scheduled) — on aikataulutettu budjetti: kumulatiivinen summa, jonka ohjelma suunnitteli käyttävänsä valtuutettuun työhön statuspäivään mennessä. PV on perusviiva. Se asetetaan kerran suunnitteluvaiheessa, lukitaan suorituskyvyn mittausperuslinjaan ja muuttuu vain virallisen perusviivan muutoksenhallinnan kautta. Jokainen sopimuksen dollari on jaettu PV-käyrään päivästä yksi sopimuksen päättymiseen.

Ansaittu arvo (EV) — aiemmin BCWP (Budgeted Cost of Work Performed) — on todella valmistuneen työn budjettiarvo samaan perusviivaan verrattuna. EV ei ole se, mitä työ maksoi; se on se, mitä valmistuneen työn suunniteltiin maksavan. Ohjelmistomoduuli, jonka budjetti on 200 000 dollaria, ansaitsee 200 000 dollarin EV:n kun se on valmis, riippumatta siitä maksiko se todellisuudessa 180 000 vai 240 000 dollaria.

Toteutuneet kustannukset (AC) — aiemmin ACWP (Actual Cost of Work Performed) — ovat se, mitä ohjelma tosiasiassa kulutti suoritettuun työhön. AC tulee taloudellisesta kirjanpitojärjestelmästä, ei arvioista. Se sisältää suorat työvoimakustannukset, suorat materiaalikustannukset, muut suorat kustannukset ja käytetyt välilliset hinnat.

PV:stä, EV:stä ja AC:stä johdetaan kaksi ensisijaista varianssimittaria:

Kustannusvarianssi (CV)     = EV - AC
Aikatauluvarianssi (SV) = EV - PV

CV% = CV / EV × 100
SV% = SV / PV × 100

Negatiivinen CV tarkoittaa kustannusten ylitystä (työ maksoi enemmän kuin se ansaitsi). Negatiivinen SV tarkoittaa aikataulun viivästymistä (vähemmän työtä valmistui kuin suunniteltiin). Molemmat varianssit ilmaistaan dollareina ja prosentteina — prosenttimuotoa käytetään kynnysarvovertailuissa.

Kaksi suorituskykyindeksiä ovat mittareita, joita hallituksen tarkastajat tarttuvat ensimmäisinä:

Kustannustehokkuusindeksi (CPI)     = EV / AC
Aikataulutehokkuusindeksi (SPI) = EV / PV

CPI yli 1,0 tarkoittaa, että ohjelma toimii tehokkaammin kuin budjetoitu; alle 1,0 tarkoittaa kustannusten ylitystä. Humphreysin empiirinen havainto — että CPI 20 prosentin valmistumiskohdassa harvoin paranee merkittävästi ohjelman elinkaaren aikana — on syy siihen, miksi hallituksen ostajat pitävät jatkuvaa CPI:tä alle 0,9:n rakenteellisena ongelmana, ei korjattavana poikkeamana. SPI yli 1,0 tarkoittaa, että ohjelma on edellä aikataulua; alle 1,0 tarkoittaa myöhässä olemista. Huomaa, että SPI lähestyy arvoa 1,0 ohjelman päättyessä riippumatta aikataulun suorituskyvystä (koska EV vastaa lopulta PV:tä kun kaikki työ on valmis) — minkä vuoksi aikataulutehokkuusindeksi yksinään ei riitä myöhäisvaiheen aikataulun arviointiin ja sitä on täydennettävä integroidulla pääaikataululla.

Kuudes mittari, joka jokaisen CAM:n on hallittava, on valmistumisarvio (EAC) — ohjelman kaiken työn odotettu kokonaiskustannus. EAC = AC + Valmistumiseen tarvittava arvio (ETC). EAC:n ja budjettikaton (BAC) välinen suhde kertoo tarinan: VAC = BAC - EAC. Negatiivinen VAC on ennakoitu ylitys. VAC raportoidaan kuukausittain CPR-muoto 1:ssä ja on yksi tärkeimmistä hallituksen ohjausviranomaisen huomion laukaisijoista.

ANSI/EIA-748-ohjeet: 32 kriteeriä

ANSI/EIA-748 on konsensusstandardi, joka määrittelee mitä vaatimuksenmukaisen EVMS:n on tehtävä. Se ei määrää tiettyjä ohjelmistotyökaluja tai raportointimuotoja — se määrittelee 32 kriteeriä viidessä ohjeistusryhmässä. Toimittajan EVMS-järjestelmäkuvauksen on osoitettava, miten kukin kriteeri on toteutettu, ja DCMA vahvistaa toteutuksen valvonnan ja IBR:n kautta.

Ryhmä 1: Organisaatio (kriteerit 1-5). EVMS:n on perustuttava työn ositusrakenteeseen, joka kattaa 100 % valtuutetusta työn laajuudesta, ja kukin elementti on osoitettu yhdelle vastuulliselle organisaatioyksikölle. Sisäiset alihankintasopimukset ja merkittävät alihankkijat on integroitava EVMS:ään tasolla, joka mahdollistaa merkityksellisen kustannus- ja aikatauluvalvonnan. Organisaatiorakenne on dokumentoitava ja heijastettava EVMS-työkalussa. Kriteeri 5 — WBS:n integroiminen organisatoriseen hajotusrakenteeseen (OBS) kustannustilien määrittämiseksi — on avainlinkki: kustannustili on WBS:n ja OBS:n leikkauspiste, ja jokainen ohjelmabudjetin dollari sijaitsee täsmälleen yhdessä kustannustilissä.

Ryhmä 2: Suunnittelu, aikataulutus ja budjetointi (kriteerit 6-14). Tämä on suurin ryhmä ja se, joka määrittää, onko PMB uskottava. Kaikki valtuutettu työ on aikataulutettava sopimuksen alusta sen päättymiseen. Lähitulevaisuuden työ on työtilaukset-pakkauksissa, joissa on objektiiviset alku- ja päättymiskriteerit; kauempana oleva työ on suunnittelupaketeissa kunnes se siirtyy liukuvan aallontoteutuksen piiriin. Hallinnollinen reservi pidetään ohjelmatasolla ja valtuutetaan vain ilmaantuville soveltamisalan töille. Jakamaton budjetti kattaa valtuutetun työn, jota ei ole vielä osoitettu kustannustileille. Budjettiperusviivan muutokset vaativat muodollisen dokumentoinnin budjettilokikirjaan. Kriteeri 12 — välillisten kustannusten rakenteen linjaaminen kirjanpitojärjestelmän kanssa — on kohta, jossa ohjelmistot kärsivät eniten, koska useita välillisiä korkokantoja (lisät, yleiskustannukset, Y&H) on rullattava ylös johdonmukaisesti sekä EVMS:n että taloushallintajärjestelmän välillä.

Ryhmä 3: Kirjanpitonäkökohdat (kriteerit 15-18). Toteutuneet kustannukset on kirjattava kustannustilin tasolla, samalla aikajaksolla kuin työ suoritettiin, käyttäen samaa WBS-elementtirakennetta. Kriteerit kieltävät toteutuneiden kustannusten arvioimisen (eli kertymät tai arviot todellisten laskujen sijasta eivät saa korvata todellista kustannusdataa yhden raportointijakson yli). Materiaalikustannukset on kirjattava vastaanoton tai kulutuksen hetkellä — kumpi tahansa linjautuu ohjelman kustannusjärjestelmän kanssa — johdonmukaisesti sovellettuna.

Ryhmä 4: Analyysi ja johdon raportit (kriteerit 19-27). Tämä ryhmä ohjaa analyysin tuloksia: varianssikynnyksiä, VAR-kertomuksia, EAC-menetelmiä, alihankkijavalvontaa ja hallituksen tietoraportteja. Kriteeri 22 — merkittävien varianssien tunnistaminen ja varianssianalyysikertomusten valmistelu — on operatiivisesti intensiivisin kriteeri CAM:lle. Kriteeri 27 — EAC:n kehittäminen vähintään neljännesvuosittain tai useammin kun varianssit ylittävät kynnysarvon — on kohta, jossa ohjelman ennustamisen uskottavuus rakentuu tai romahtaa.

Ryhmä 5: Tarkistukset ja tietojen ylläpito (kriteerit 28-32). Perusviivan muutokset on sisällytettävä muodollisesti ja ajallaan. Budjettilokikirja seuraa jokaista budjetin liikettä, johdon valtuuttamana, syykoodeineen. Takautuvat muutokset EV:hen — suorituksen hyvittäminen statuspäivän jälkeen — on kielletty. Järjestelmäkuvauksen itsensä on oltava ajantasainen. Kriteeri 32 — takautuvia oikaisuja, jotka eivät heijasta suorituskykyä, kieltävä kriteeri — on kriteeri, johon viitataan useimmin DCMA:n korjaavien toimenpiteiden pyynnöissä, koska takautuva EV-manipulointi on houkuttelevin lyhyen aikavälin korjaus negatiivisille variansseille.

Työn ositus puolustusalan ohjelmistoissa

WBS ohjelmistopainotteisessa puolustusohjelmassa ei ole tehtävälista eikä projektinhallinnan hierarkia. Se on tuotesuuntautunut hajotus koko sopimustoimitettavasta, linjattuna MIL-STD-881:een niin, että raportointi kartoittuu suoraan ohjausviraston kustannusmalliin.

MIL-STD-881 tarjoaa standardin WBS-elementtimäärittelyt puolustusalan järjestelmäohjelmille. Ohjelmistopainotteiselle järjestelmälle relevantit elementit sisältävät tyypillisesti: Järjestelmä (taso 1), Ohjelmisto (SE 03 tasolla 2), hajotettuna tietokoneohjelmiston kokoonpanoyksiköihin (CSCI) tasolla 3. Kukin CSCI kartoittuu suureen ohjelmistokomponenttiin — tehtäväjärjestelmän ohjelmistopakettiin, viestinnän käsittelyelementtiin, tiedonhallintapalveluun — vastaavaan allokoidun perusviivan arkkitehtuuriin. Kustannustilit perustetaan yleensä tasolla 3 (CSCI) tai tasolla 4 (tietokoneohjelmistokomponentti, CSC) ohjelman koon ja ohjelmistokompleksisuuden mukaan.

Liukuva aaltosuunnittelu on mekanismi, joka pitää WBS:n realistisena monivuotisessa ohjelmassa. Työ seuraavan 90 päivän sisällä (tai kaksi tai kolme raportointijaksoa) hajotetaan erillisiksi työtilaukspakkauksiksi, joissa on objektiiviset kriteerit. Työ liukuvan aaltohorisonttin ulkopuolella on suunnittelupaketeissa — budjetoitu mutta ei vielä täysin hajotettu. Ohjelman edetessä suunnittelupaketit muunnetaan työtilausten pakkauksiksi muodollisen muuntamisprosessin kautta, joka päivittää pääaikataulun, luo työn valtuutusdokumentin ja kirjaa muunnoksen budjettilokikirjaan.

Yleisiä WBS-virheitä ohjelmistoohjelmissa:

• Organisointi sprinteittäin tai ketterän tiimin mukaan eikä tuote-elementin mukaan. Ketterä toimitus voi elää rinnakkain EVM:n kanssa, mutta kustannustilin rakenne on seurattava WBS:ää (tuote), ei toimitusrytmiä (prosessi). Ketterät työtilaukset ansaitsevat arvon sprintin päättyessä objektiivisia hyväksymiskriteerejä vastaan.
• Järjestelmätekniikan ja integraatiotyön puuttuminen. Järjestelmätekniikka (SE 01), integrointi/kokoonpano/testaus ja tarkastus (SE 10) sekä ohjelmanhallinta (SE 12) ovat erillisiä MIL-STD-881-elementtejä, joilla kullakin on oltava omat kustannustilinsä. Ohjelmat, jotka yhdistävät nämä ohjelmistotileihin, luovat kustannustilin vastaavia, joilla on sekoitettu vastuu ja selvittämättömiä variansseja.
• WBS:n laajentamatta jättäminen alihankkijoille. Merkittävillä alihankkijoilla vaaditaan ANSI/EIA-748 kriteerin 4 nojalla raportoimaan EVM-dataa tasolla, joka mahdollistaa pääasiakkaan valvonnan. Pääasiakas, joka pitää suurta ohjelmistoalihankintaa yksittäisenä rivinä työtilauspaketissa, jolla on välitavoite-EV, ei täytä kriteeriä 4.

WBS-sanakirja on asiakirja, joka tekee WBS:stä operatiivisen: jokaiselle elementille sanakirja määrittelee työn laajuuden, vastuullisen CAM:n, vastuullisen organisaation, budjetin ja ansaintamenetelmän. Sanakirja on perusviivatettu sopimuksen alussa, päivitetään muutoksenhallinnan prosessin kautta ja tarkistetaan IBR-läpikäynneissä.

Integroidun perusviivan katselmus (IBR) valmistelu

IBR on hallituksen muodollinen vahvistus siitä, että toimittajan PMB on uskottava — että työn laajuus, aikataulu ja budjetti ovat yhdenmukaisia ja saavutettavissa. EVMS-kynnysarvon ylittäville ohjelmille IBR vaaditaan 180 päivän kuluessa sopimuksen myöntämisestä (DoD-ohje 5000.02 asettaa politiikan; yksittäiset ohjausvirastot voivat lyhentää tätä ikkunaa). IBR ei ole kertaluonteinen tapahtuma: se toistuu merkittävien sopimusmuutosten jälkeen ja minkä tahansa muodollisen uudelleenperusviivaustoimenpiteen jälkeen.

IBR:n tavoitteet hallituksen näkökulmasta. Hallituksen IBR-tiimi arvioi neljää asiaa: tekninen täydellisyys (kattaako WBS 100 % sopimuksen SOW:sta?), aikataulun saavutettavuus (voivatko välitavoitteet täyttyä allokoiduilla resursseilla?), budjetin realistisuus (perustuvatko budjetit laillisiin arvioihin eikä plugattu siten, että kokonaisarvo vastaa sopimuksen arvoa?) ja johtamisen tehokkuus (omistavatko CAM:t todellisuudessa tilinsä ja ymmärtävätkö he työtään?).

Aikatauluriskiarviointi. Ennen IBR:ää toimittajan tulisi suorittaa kvantitatiivinen aikatauluriskianalyysi pääaikataulusta — tyypillisesti Monte Carlo -simulaatio käyttäen Primavera Risk Analysis -ohjelmistoa tai vastaavaa. Aikatauluriskianalyysi tunnistaa kriittisen polun, lähikriittiset polut ja keskeisten välitavoitepäivien luottamustason. Hallituksen IBR-tiimit kysyvät erityisesti aikatauluperuste-varasta: mikä on toimitusväliaivojen liikkumavara ja mitkä riskit voivat kuluttaa sen? Ohjelmat, jotka saapuvat IBR:ään nollalla liikkumavaralla kriittisellä polulla ja ilman aikataulureserviä, kohtaavat uskottavuusongelman.

CAM-riskien läpikäynnit. IBR:n ydin on kahdensuuntainen läpikäynti kunkin CAM:n ja hallituksen IBR-tiimin välillä. CAM esittelee kustannustilinsä: työn laajuuden, aikataulun, budjetin, resurssikuormituksen, keskeisimmät riskit ja valmistumisarvion. Hallituksen tiimi haastaa CAM:n olettamukset ja tutkii aukkoja. Kuusi kysymystä, joihin jokaisen CAM:n on pystyttävä vastaamaan ilman epäröintiä:

• Mitä täsmälleen sisältyy kustannustilini soveltamisalaan ja mitä on nimenomaisesti suljettu pois?
• Mitkä ovat työtilaukspakkauksissani olevien objektiiviset valmistumiskriteerit?
• Mitä ansaintamenetelmää käytän ja miksi se soveltuu tähän työhön?
• Mitkä ovat kaksi tai kolme riskiä, jotka todennäköisimmin aiheuttavat kustannus- tai aikatauluvariansseja tilissäni?
• Riittääkö budjettini työn suorittamiseen? Jos ei, mistä hankkisin lisää?
• Mikä on ETC:ni ja miten laskin sen?

Hallituksen IBR-tarkistuslistan kohdat. Hallituksen tiimi arvioi tyypillisesti: (1) WBS-SOW-jäljitettävyysmatriisi; (2) pääaikataulun verkostologiikka — ei avoimia toimintoja, ei keinotekoisesti aikataulua nopeuttavia rajoitteita; (3) resurssiladattu aikataulu — ovatko pääaikataulussa olevat tunnit yhdenmukaisia EVMS:n työvoimabudjetin kanssa?; (4) riskikirjaston integraatio — ovatko tunnistetut riskit jäljitettävissä aikatauluvaraan tai hallinnalliseen reserviin?; (5) alihankkijan IBR-tila — ovatko siirtymiskynnyksen ylittäneet alihankkijat suorittaneet omat IBR:nsä?; (6) järjestelmäkuvauksen ajantasaisuus — heijastuuko EVMS-järjestelmäkuvaus todella käytössä oleviin työkaluihin ja prosesseihin?

IBR tuottaa toimenpideluettelon (AI:t) ja merkittävien varianssien luettelon (SV:t). AI:t ovat läpikäynneissä tunnistetut erityiset puutteet, jotka toimittajan on korjattava tyypillisesti 30-60 päivän kuluessa. SV:t ovat vakavampia — ne osoittavat, että osa perusviivasta ei ehkä ole saavutettavissa — ja ne voivat vaatia muodollista uudelleensuunnittelua. Puhdas IBR (vähän AI:ta, ei SV:tä) on tärkein varhaisen ohjelman uskottavuusmerkki hallituksen ohjausvirastolle.

Kustannustilin vastaavan (CAM) raportointi

CAM on EVMS-toteutuksen peruselementti. Ohjelmistoohjelmassa tyypillinen CAM omistaa 3-8 työtilaukspakkausta, jotka kattavat heidän ohjelmistokomponenttinsa suunnittelun, koodauksen, yksikkötestauksen ja integrointitoiminnot. CAM:n kuukausittainen sykli ohjaa koko ohjelman EVM-datan laadun.

CAM-statustapaamisen aikataulu. Ohjelmistoohjelmille paras käytäntö on viikoittainen 30 minuutin CAM-statusseurantapiste: ohjelman valvonta-analyytikko (PCA) käy läpi kunkin tilin kuluvan kauden toteutuneet kustannukset, CAM vahvistaa tai korjaa valmistumisprosentin arviot, uudet riskit merkitään ja esiin nousevat varianssit käsitellään ennen kuin ne ilmestyvät kuukausiraporttiin. Kuukausittainen päätöspalaveri (tyypillisesti kirjanpitokauden päätyttyä ensimmäisellä viikolla) on se, missä muodollinen EV-vaade lukitaan, varianssit lasketaan ja varianssianalyysikertomukset osoitetaan CAM:lle, jotka ylittävät kynnysarvon. Ohjelmat, jotka tiivistävät kaiken tämän yhdeksi kuukausittaiseksi statuspalaverksi, tuottavat heikolaatuisempaa dataa ja menettävät viikoittaisen aikataulun tarkoituksen — varhaisen varoituksen.

Varianssianalyysin kynnysarvot: 10%/10-sääntö. Yleisin sopimuslauseke edellyttää kirjallista varianssianalyysikertousta (VAR), kun kumulatiivinen kustannusvarianssiprosentti ylittää 10 % kumulatiivisesta EV:stä tai kun kumulatiivinen aikatauluvarianssiprosentti ylittää 10 % kumulatiivisesta PV:stä. Useimmat sopimukset määrittävät myös absoluuttisen dollarikynnyksen (esim. 10 000 dollaria kustannustilitasolla, 100 000 dollaria ohjelma-tasolla) niin, että pienet tilit, joilla on suuri prosentuaalinen varianssi mutta pieni dollariarvo, eivät tuota pakollisia kertomuksia. Kun kustannustili ylittää kynnysarvon sekä kustannus- että aikatauluvarianssin osalta samanaikaisesti, yksi VAR, joka kattaa molemmat, on hyväksyttävä, mutta juurisyyanalyysin on käsiteltävä kutakin varianssimittaria erikseen.

Valmistumisvarianssikertomusta (VAC) koskeva kertomus. Kausi- ja kumulatiivisten varianssien lisäksi ANSI/EIA-748 kriteeri 27 edellyttää, että EAC päivitetään vähintään neljännesvuosittain, ja CPR-muoto 1 edellyttää VAC-raportointia kustannustilin tasolla kuukausittain. Kun CAM:n VAC muuttuu negatiiviseksi (ennakoitu ylitys), VAR-kertomuksen on käsiteltävä paitsi kuluvaa kautta myös tilin koko elinkaarta. Mitä tapahtui, miksi se tapahtui, mikä on ennakoitu vaikutus koko sopimuksen ajan, ja erityisesti mitä CAM tekee palautumisen eteen — tai, jos palautuminen ei ole mahdollista, mitä työn laajuuden supistamista, aikataulumuutosta tai hallinnollisen reservin nostoa ehdotetaan. VAC-kertomukset, jotka vaikuttavat kopioilta edellisen kuukauden tekstistä, ovat yleisin laukaisin hallituksen pyynöille henkilökohtaisesta ohjelmakatselmuksesta.

Valmistumisarvion (EAC) menetelmät

EAC on EVMS:n tarkimmin tutkittu tulos. Se on toimittajan paras arvio siitä, mitä ohjelma tulee kokonaisuudessaan maksamaan, toimitetaan kuukausittain hallitukselle CPR-muoto 1:ssä. EAC, joka on jatkuvasti optimistisempi kuin CPI-trendit viittaisivat, on dataintegriteettisignaali, joka laukaisee hallituksen tiedustelun. Useita EAC-menetelmiä olisi laskettava kuukausittain puolustettavimman luvun kolmiomittausta varten.

EAC = BAC / CPI (tehokkuuspohjainen menetelmä). Yksinkertaisin ja usein tilastollisesti puolustettavin EAC ohjelmistoohjelmille: jaetaan budjettikatto nykyisellä kumulatiivisella CPI:llä. Jos BAC on 10 000 000 dollaria ja kumulatiivinen CPI on 0,87, niin EAC = 10 000 000 / 0,87 = 11 494 253 dollaria. Tämä menetelmä olettaa, että nykyinen kustannustehokkuus jatkuu sopimuksen loppuun asti. Tutkimukset suurten ohjelmatietokantojen pohjalta osoittavat johdonmukaisesti, että tämä menetelmä päihittää johdon harkinnanvaraisen EAC:n sen jälkeen, kun ohjelma on 20-25 % valmis.

EAC (vain CPI)      = BAC / CPI
EAC (CPI x SPI)     = AC + (BAC - EV) / (CPI x SPI)
EAC (alhaalta ylös) = AC + Summa(CAM ETC:t)
EAC (johto)         = AC + ETC johdon harkinnan perusteella

TCPI (vs BAC)       = (BAC - EV) / (BAC - AC)
TCPI (vs EAC)       = (BAC - EV) / (EAC - AC)
VAC                 = BAC - EAC

EAC:n yhdistelmämenetelmät (CPI x SPI). Ohjelmille, joissa aikataulun viivästyminen on itsessään kustannuskasvun ajuri — koska jatkuva aikataululiukuma jatkaa työvoimakustannuksia lisäkausille — yhdistelmämenetelmä soveltaa sekä CPI:tä että SPI:tä tehokkuusnimittäjänä: EAC = AC + (BAC - EV) / (CPI x SPI). Tämä menetelmä on aggressiivisempi kuin pelkän CPI:n menetelmä (se tuottaa suuremman EAC:n) ja hallituksen riippumattomat kustannusarvioijat käyttävät sitä usein ristiintarkistuksena. Yhdistelmämenetelmällä on taipumus yliarvioida EAC ohjelmille, joissa aikataululiukuma heijastaa riskien etukuormitusta eikä järjestelmällistä tehottomuutta.

Hallituksen riippumattoman kustannusarvion (IGCE) täsmäyttäminen. Ohjausvirasto ylläpitää IGCE:tä — heidän riippumatonta näkemystään ohjelman kustannuksista — kehitettynä hankintavirkamiehen edustajan tai omistetun kustannusarviointitiimin toimesta. Kun hallitus julkaisee IGCE:n tai kun sellainen voidaan päätellä hallituksen lausunnoista ohjelmakatselmusten aikana, toimittajan on täsmäytettävä EAC:nsa IGCE:tä vastaan ja dokumentoitava erot. Toimittajan EAC, joka on huomattavasti optimistisempi kuin IGCE ilman dokumentoitua, sisällöllisesti perusteltua selitystä, on uskottavuusongelma. Täsmäytyskertomuksen on selitettävä nimenomaisesti miksi toimittajan arviolaskelma eroaa hallituksen laskelmasta — eri työvoimahintojen oletukset, eri tuottavuustekijät, eri alihankkijoiden kustannusennusteet — ei yksinkertaisesti väittää, että toimittajan EAC on oikea.

Valmistumiseen tarvittava tehokkuusindeksi (TCPI) on sisäinen johdonmukaisuustarkistus: TCPI vs. BAC = (BAC - EV) / (BAC - AC). Jos TCPI vs. BAC on 1,15 ja nykyinen CPI on 0,88, ohjelma ennustaa 31 pisteen tehokkuuden parantumista ilman osoitettua perustetta. Tämä on epärealistisen EAC:n matemaattinen tunnusmerkki, ja hallituksen tarkastajat merkitsevät sen heti. Käytännön sääntö: kun TCPI vs. BAC ylittää 1,10, toimittaja tarvitsee joko alhaalta-ylös ETC:n, joka selittää parantumisen, tai tarkistetun EAC:n, joka myöntää ylitystrendin.

EVMS-työkalun valinta ja tietojen toimittaminen

EVMS-työkalun valinta määrittää analyyttisen kyvyn lisäksi myös hallituksen tietojen toimittamisen käytännöllisen helppouden. Hallitus vaatii nyt IPMDAR:n (Integrated Program Management Data and Analysis Report) jäsennelyssä digitaalisessa muodossa, ja työkalun on vietävä vaatimustenmukaiset tiedostot.

Deltek Cobra. Hallitseva EVMS-työkalu DoD-ohjelmissa. Cobra käsittelee PMB-hallinnan, ansaintamenetelmäkonfiguraation, varianssien laskemisen, budjettilokikirjan ylläpidon ja CPR/IPMDAR-viennin. Cobra integroituu natiivisti Primavera P6:een aikataulu-kustannusintegraatiota varten ja Deltek Costpointiin toteutuneiden kustannusten tuontia varten. Sen ensisijainen vahvuus on natiivi IPMDAR-vientimoduuli, joka tuottaa hallituksen vaatiman JSON-datapaketin suoraan Cobra-tietokannasta. IPMDAR-kynnysarvon ylittäville ohjelmille (yli 20 milj. dollaria kustannusperusteiset) Cobra on käytännössä standardi.

Microsoft Project EVM-lisäosineen. Pienemmissä ohjelmissa (alle 20 milj. dollaria, kiinteähintainen vapaaehtoisella EVM:llä tai sisäiseen käyttöön), Microsoft Project EVM-moduulilla (Steelray tai projektin natiivikenttä EVM) on laajasti käytetty. MS Project ei tuota natiivisti IPMDAR-vaatimustenmukaisia vientejä ja edellyttää lisätyökaluja tai manuaalista tietomuunnosta hallitukselle toimittamista varten. Sen etu on tuttuus — käytännössä jokainen ohjelmapäällikkö tuntee sen — ja tiivis integraatio Microsoft 365 -ympäristöihin, jotka ovat yleisiä puolustusalan urakoitsijaympäristöissä.

Oracle Primavera P6. P6 on aikatauluviranomainen suurimmissa ohjelmissa. Se ei ole natiivi EVMS-työkalu — se ei käsittele budjetointia, EV-vaatimista tai varianssianalyysia natiivisti ANSI/EIA-748:n vaatimassa syvyydessä — mutta se on integroitu pääaikataulualusta, joka syöttää Cobraa tai muita EVMS-työkaluja aikatauludatalla. P6-Cobra-integraatio, oikein konfiguroituna, mahdollistaa sen, että pääaikataulu ja EVMS jakavat yksittäisen auktoritatiivisen aikataulun, eliminoiden "irrotettu aikataulu" -vikatilan, joka on yksi yleisimmistä DCMA-tarkastuslöydöksistä.

IPMDAR- ja CPR-tietomuodot. Contractor Performance Report (CPR) on viidessä muodossa:

• Muoto 1 — WBS-elementin suorituskyky: PV, EV, AC, BAC, EAC, VAC WBS-elementin mukaan
• Muoto 2 — Organisaatiosuorituskyky: sama data organisaatioelementin mukaan järjestettynä
• Muoto 3 — Budjettilokikirja: rekisteri kaikista PMB-muutoksista raportointikaudella
• Muoto 4 — Henkilöstö: toteutuneet ja suunnitellut henkilötyötunnit ammattialan mukaan
• Muoto 5 — Selitykset ja ongelma-analyysi: kertomusosio, joka kattaa merkittävät varianssit, EAC-perustelun ja riskikeskustelun

IPMDAR korvaa vanhentuneen IPMR-muodon ja toimitetaan jäsennellyssä JSON/XML-paketissa. IPMDAR-skeeman validointi vaaditaan ennen toimittamista — työkalut, jotka tuottavat ei-vaatimustenmukaista skeematuotosta, johtavat hallituksen tietojärjestelmän hylkäämiseen. Toimittaminen tapahtuu tyypillisesti Wide Area Workflow (WAWF) -järjestelmän tai DoD:n EVM Central -portaalin kautta ohjelman nimetyn datavastaanottotoimiston mukaan. Sopimuksen CDRL (Contract Data Requirements List) määrittää eräpäivät — tyypillisesti 25 päivää kauden päättymisen jälkeen kuukausiraportoinnin osalta.

Työkalun valinnassa on otettava huomioon kolme tekijää: hallituksen hyväksyttävyys (EVMS-järjestelmäkuvauksen on kuvattava työkalu ja DCMA:lla on oltava näkyvyys sen konfiguraatioon), integraatio olemassa olevien talous- ja aikataulujärjestelmien kanssa (manuaalinen tietojen uudelleensyöttö taloushallintajärjestelmän, aikataulutyökalun ja EVMS:n välillä on virheiden lähde ja valvonnan punainen lippu), ja organisaation osaaminen (tiimi, joka tuntee Cobran hyvin, suoriutuu paremmin kuin tiimi, joka opettelee teoreettisesti paremman työkalun kesken ohjelman). Uusien ohjelmien käynnistyessä investointi Cobran ja Primavera P6:n integraatioon on perusteltu kuukausittaisen raportointitaakan vähenemisellä ja sen tuottamien IPMDAR-vientien laadulla.