Galvenais izaicinājums ir precīzi vadīts ātrums un spēja efektīvi izvēlēties risinājumus, metodes un resursus. Neskatoties uz elastīgās ātrās (veiklās) projektu vadības (Agile Project Management) metožu pieejamību jau no teju astoņdesmitajiem gadiem, tajā skaitā Latvijā, iespējams pazīstamākās „Scrum” metodes pieejamību no deviņdesmitajiem, projekti lielā skaitā gadījumu tiek gan aprēķināti, gan vadīti pēc klasiskās metodes. Taču Scrum sapulces ik rītu vēl nepadara projektu par „ātru” un iesaistītie izstrādātāji tādēļ nestrādā „ātrākā” veidā. Šaurā vieta ātrai izstrādes metodei ir ilgtermiņa konsistences trūkums. Citiem vārdiem, paša projekta izstrādes stabilitāte ilgtermiņā, ko veicina apstākļi, ka visas prasības ne vienmēr ir zināmas un gala rezultāts ir aprakstīts tikai konceptuāli, nevis precīzas specifikācijas izskatā.
Iemesli ir vairāki. Pirmkārt pasūtītājs vēlas redzēt prototipa fāzi maksimāli ātri, tajā pašā laikā veic neskaitāmas prasību izmaiņas, kamēr projekts atrodas izstrādes stadijā. Katra nākamā iterācija, iespējams, satur iespējas vai funkcijas, kas plānošanas fāzē nemaz nepastāvēja.
Iespējams, tādēļ arvien lielāku popularitāti iegūst tā saucamā DAD (Disciplined Agile Delivery) projektu vadības metode. Atšķirība ir tajā, ka tiek ieviests papildus posms pašā projekta sākumā – „Inception”, kura laikā tiek ātri izveidots prototips ar pamatfunkcijām. Tam ir vairāki ieguvumi: pirmkārt, izstrādātājam nav iespējams aprēķināt visa projekta vērtību, kamēr nav zināms precīzs apjoms, bet izstrādātājs visai precīzi zina savu vairāku darba nedēļu cenu, kas tiks pavadīta „inception” fāzē. Savukārt pasūtītājs, kas „mīl ar acīm”, iegūst risinājuma demo, kas viņam pašam palīdz saprast precīzāk, kas īsti viņam ir nepieciešams un kādai ir jābūt gaidāmai funkcionalitātei.
Otrs ievērojams laika vadības uzdevums ir pārbaužu un ieviešanas fāze. Lai nodrošinātu šādu izstrādi termiņos, budžetā un bez kļūdām, protams, pirmais kas tiek meklēts ir gatavas platformas risinājumi, kas sniedz iespēju ātri tikt pie strādājoša prototipa. Izstrādes veikšana mākoņrisinājumu vidē likvidē izstrādes un produkcijas vides kā atsevišķas, samazinot tehniskās ieviešanas laiku un izmaksas. Arvien vairāk parādās nepieciešamība pēc risinājumiem, kas strādā vienotā platformā, lai samazinātu integrāciju izstrādes izmaksas. Šī vienotā vide savukārt nosaka arī piesaistāmās puses projekta izstrādē, kas ir piegādātāji un apakšuzņēmēji, kuru darbs arī ir jāvada un jākontrolē.
Trešais ievērojamais uzdevums ir pasūtītāja iesaiste un vienota vide izstrādes iterāciju plānam, izmaiņu pieprasījumu un izstrāžu vadībai. Pasūtītājs no savas puses vēlas būt lietas kursā par notiekošo, tomēr tam ir jāsaprot, ka iesaiste šādā līmenī uzliek pienākumu aktīvai un ātrai atgriezeniskajai saitei un lēmumu pieņemšanai tempā, kas iespējams pasūtītāja organizācijas procesos nemaz nav iespējama. Vienkāršiem vārdiem runājot, liela daļa no pasūtītājiem šādam darbam nav gatava.
Izstrādātāji ātri piegādā produkta relīzes, jeb iterācijas, kas sarežģī fāzi, kad produkts jau ir „gaisā” un strādājošs. Operāciju nodrošinājuma nodaļa konfliktē, jo ir nepieciešams nodrošināt sistēmas nepārtrauktu darbu, tie ir motivēti neko nemainīt, lai viss strādā bez pārtraukumiem un pārsteigumiem. Šeit var palīdzēt servisu virtualizācija, lai notestētu jauno moduļu darbību un ietekmi uz visu produktu. Tāpat nepieciešama relīžu piegāžu automatizācija, klasterēta arhitektūra, virtuāls infrastruktūras tīkls, lai transakcijas nepazustu atjaunojumu laikā u.c.
Jāpiebilst, ka šāda veida izstrāde prasa komandu ar atvērtu prātu, spēju pielāgoties, dalīties savās zināšanās un spēju sastrādāties komandā. Šādu komandu vadība pieprasa ļoti spējīgus vadītājus ar kompetenci un pieredzi, kas ļauj ātri un efektīvi virzīt un motivēt resursus. Cilvēkus, kuriem nepastāv tikai „balts un melns”.
Un pēdējais. Ne mazāk svarīga ir precīza iesaistīto resursu uzskaite. Tās nav tikai stundas, bet arī savu metriku izveide, lai uzskaitītu izdošanās un kļūdas, to ietekmi uz projektu. Ja nav šo metriku, ir grūti aprēķināt projekta vadības lēmumu ietekmi. Ja nav šo metriku, nav iespējams precīzi redzēt, ko laika un naudas izteiksmē patiesībā prasīs vienas vai otras pasūtītāja vēlmes īstenošana, kādas koda daļas tiks ietekmētas, ko tas maina produkta funkciju testēšanā.
IBM inovāciju konferencē, iepazīstoties ar piedāvātajiem risinājumiem IT produktu izveidē un ieviešanā liela daļa no uzrunātajiem IT uzņēmumu pārstāvjiem atzina, ka projektu vadībā nereti tiek izmantots vidusceļš, jo uzņēmuma struktūra un risinājumu ieviešanas un uzturēšanas metodes „netiek līdzi” aktīvam izveides procesam. Tomēr visi atzīst, ka konkurence ir augsta un risinājums izstrādes cikla posmu paātrināšanai ir akūti nepieciešams, tiek meklēti veidi kā samazināt izmaksas.
Faktiski pasūtītājs pieprasa kvalitāti, bet realitātē ne pasūtītājam, ne izstrādātājam nav laika un budžeta ideālam un gatavam produktam.
Budžetu papildus noēd jau izstrādes laikā radušās jaunas prasības un prasību izmaiņas, kas sarežģī izstrādes ciklu un palielina kļūdu risku. Lūk, jautājums, kurš no izstrādātājiem ir spējīgs labi izstrādāt, piemēram, Marsa visurgājēja programmatūru. Viena kļūda (kādu ir daudz mūsu ikdienas produktos) un miljonus maksājošs visurgājējs paliek par stāvošu. Šeit varam vilkt paralēles ar pašmāju izstrādātiem IT projektiem, kas nav veiksmīgi īstenoti, „stāvot plauktā” ēd infrastruktūras uzturēšanas izmaksas vai ir realizēti, taču lietotājiem sagādā galvassāpes. Šādu produktu saglābšana, pilnveidošana un atkārtots ieviešanas mēģinājums maksā ļoti dārgi, un nereti tiek izvēlēts ceļš darīt no jauna. Tas nebūtu nekas slikts, ja vien lietotāji iegūtu tiešām labi strādājošu produktu un ja vien iepriekšējais nebūtu jau izmaksājis dārgi un tapis lēni. Tādēļ „sākt no maza pamata ar pamatfunkcijām” un „augt ar iterācijām pēc pieprasījuma prioritātēm” ir labs risinājums. Te gan vienīgi jāpiebilst, ka šobrīd iepirkumu likums nav īsti piemērots ilgtermiņa darbam ar vienu piegādātāju valsts un pašvaldību projektos.