Naslednji korak procesa snovanja projekta je podrobna opredelitev končnega proizvoda (izdelka, rezultata, storitve, dogodka ali sestavine) – »kaj naj bi nastalo« ob zaključku oziroma do zaključka projekta in »kako bo izgledalo«? Vhodni dokument za opredelitev proizvodov je predlagana rešitev, ki pa jo je potrebno natančneje opredeliti na podlagi potreb uporabnikov. Napisal sem »proizvodov«, saj običajno projekt ne ustvari le enega – projekt razvoja novega izdelka ima npr. naslednje »proizvode«: nov izdelek, dokumentacijo (navodila za uporabo, promocijski brošuro, ipd.), zagotovljene proizvodne zmogljivosti s priučenimi delavci, pridobljene tipske odobritve na ciljnih trgih, ipd.

Celoten nabor predvidenih proizvodov projekta stroka vključuje v »obseg«, ki sem ga časom že na kratko predstavil. Po navedbah avtorjev obstajata dva »tipa« obsega – obseg dela (angl. scope of work ali project scope) in obseg proizvodov (angl. product scope, PMBOK 2004). V fazi snovanja projekta govorimo seveda o slednjem (to, kar sem opisal v prejšnjem odstavku), medtem ko se obseg dela običajno izdela v fazi priprave projekta (taktika izvedbe in planiranje aktivnosti), kar pa je že naloga projektnega tima.

Če smo torej z obsegom opredelili, kaj bo potrebno ustvariti, morajo snovalci v naslednjem koraku te proizvode natančno opredeliti (oblika, karakteristike, funkcionalnost…), dokument pa se običajno imenuje specifikacije (proizvodov), v Sloveniji poimenovan tudi »tehnični zahtevnik« ali pa »projektna naloga«. Pri več avtorjih sem našel delitev specifikacij na »funkcionalne« in »tehnične«. Frame (2003) navaja, da funkcionalne zahteve opisujejo karakteristike proizvodov v običajnem, »netehničnem« jeziku, saj morajo biti razumljive uporabnikom. Tehnične zahteve pa opisujejo karakteristike proizvodov s »tehničnim« jezikom (parametri, strokovni izrazi, pogoji delovanja, ipd.).

Priprava specifikacij – proces in primer

Opredelitev specifikacij projekta*

Na podlagi obsega in specifikacij projektni tim točno ve, kaj se od njega pričakuje, predstavlja osnovo za pripravo plana izvedbe, ob zaključku projekta, ob predaji proizvodov, pa na podlagi specifikacij naročnik (stranka) preveri ustreznost oziroma usklajenost proizvodov s specifikacijami.

Poleg obsega proizvodov so vhod v pripravo specifikacij predvsem zahteve (angl. requirements) uporabnikov, zato je naloga pobudnika in snovalcev projekta, da čim bolj analizirajo želje in potrebe uporabnikov. Če se bo projekt izvedel za lastne potrebe (npr. razvoj IT podpore procesu), potem se analiza izpelje neposredno s pogovori z uporabniki, v primeru razvoja novega izdelka za trg, pa se zahteve opredelijo s pomočjo tržne analize.

V primeru, da je podjetje v vlogi (pod)izvajalca in naj bi izvedlo projekt proti plačilu za zunanjega naročnika, pa pričakuje, da bo večino zgoraj omenjene dokumentacije pripravil naročnik. Pri tem je seveda vprašljiva strokovnost snovalcev in uporabnikov pri naročniku (sicer bi mogoče projekt izvedli kar sami), zato je smiselno, da obe združbi specifikacije izdelata skupaj. Kdaj se podpiše pogodba in ali vključuje tudi storitev priprave specifikacij, bomo govorili kdaj drugič.

V povezavi s zahtevami in specifikacijami pa moram omeniti še »konfiguracije« in management konfiguracij (angl. configuration management), ki sem ga tudi že omenil. Burke (2010) navaja, da je konfiguracija (skupaj s študijo izvedljivosti in taktiko izvedbe) vhod v opredelitev obsega del, vendar je še bolj pomembno to, kar navaja Cleland (1999) – da management konfiguracije vključuje obvladovanje funkcionalnih in fizičnih karakteristik proizvodov skozi celoten projekt. Predvsem se to nanaša na morebitne spremembe proizvodov – glavna naloga managementa konfiguracij po potrjenih specifikacijah proizvodov je, da poskrbi za formalno obravnavo predlaganih sprememb specifikacij (vključno z oceno posledic spremembe), ter da s spremljanjem nastajanja proizvodov zgodaj odkrije morebitne poskuse nekontroliranega spreminjanja.

Nekateri avtorji vključujejo pripravo obsega in specifikacij med naloge projektnega managerja, vendar bi se osebno tukaj raje držal drugih priporočil – manager projekta mora predvsem zagotoviti, da so zahteve (obseg, specifikacije) pred začetkom planiranja projekta čim bolj podrobne in nedvoumne, da bo plan realnejši, da ne bo kasnejših konfliktov in sprememb. Poleg tega pa, kot pravi Thomsett (2002), naj manager projekta ne bi bil pobudnik projekta, zaradi česar ne bo »čustveno vezan« na pričakovane proizvode in bo lažje zastopal načelo »povejte mi, kaj naj naredimo, in to bomo storili«. Seveda tako on, kot člani tima lahko sodelujejo pri snovanju (oziroma je celo priporočljivo), a le kot svetovalci – poznajo zmožnosti tehnologije, predlagajo tehnične rešitve, alternative … a na koncu se odločajo uporabniki ali skrbnik projekta! Včasih specifikacije lahko nastanejo šele v sklopu priprave projekta, ko je ožji projektni tim že sestavljen, a še vedno imajo glavno besedo uporabniki…