03 BREZ SPREMEMB NI PROJEKTA

Spremembe so stalnica v vseh fazah projekta

Ko so projektna dokumentacija, popis, terminski plan in pogodba pripravljeni, se pogosto ustvari vtis, da je projekt dokončno opredeljen.

Načrti so potrjeni.
Količine so določene.
Cena je dogovorjena.
Rok je postavljen.

Izvedba naj bi bila od tega trenutka naprej predvsem izvrševanje začetnega načrta.

Toda podpis pogodbe ne zamrzne resničnosti.

Med projektiranjem, razpisom in gradnjo nastajajo nove informacije. Razkrijejo se razmere, ki jih prej ni bilo mogoče v celoti poznati. Spremenijo se zahteve naročnika, soglasodajalcev ali uporabnikov. Pojavijo se napake, boljše tehnične rešitve, težave z dobavo, nove omejitve in nepredvideni dogodki.

Zato spremembe niso izjema, ki bi se pojavila samo pri slabo pripravljenih projektih.

Spremembe so normalen del razvoja projekta.

Sprememba sama po sebi še ni napaka.

Lahko je posledica nove informacije, spremenjene okoliščine, natančnejšega poznavanja objekta, nove zahteve uporabnika, tehnološkega razvoja ali izboljšane rešitve. Lahko pa seveda razkrije tudi napako v projektni dokumentaciji, popisu, načrtovanju, izvedbi ali odločanju.

Zato kakovosti projekta ne moremo presojati samo po številu sprememb.

Kakovost projekta se kaže predvsem v tem, kako zgodaj spremembe prepozna, kako dobro razume njihove vzroke in kako disciplinirano obvladuje njihove posledice.

Pri vsaki pomembni spremembi moramo zato znati odgovoriti na nekaj osnovnih vprašanj:

Kaj se je spremenilo?
Zakaj se je spremenilo?
Kdaj smo to lahko vedeli?
Katere možnosti smo imeli?
Kakšen je vpliv na kakovost, stroške, rok in nadaljnji potek projekta?

Šele takšna analiza omogoča razlikovanje med normalnim razvojem projekta, zavestno izboljšavo, posledico nove okoliščine in dejansko napako.

Da bi spremembo sploh lahko prepoznali in presojali, pa potrebujemo jasno začetno izhodišče.

strong>Začetni načrt je nujen, ni pa prerokba

Vsak projekt potrebuje jasno izhodišče:

• določen obseg,
• projektno rešitev,
• popis del,
• ocenjeno ali pogodbeno vrednost,
• terminski plan,
• razdelitev odgovornosti,
• pogodbene pogoje.

Brez takšnega izhodišča ni mogoče ugotavljati, ali projekt odstopa od načrtovanega stanja.

V projektnem vodenju takšnemu izhodišču pogosto rečemo osnovni plan oziroma baseline.

Baseline je odobrena slika projekta v določenem trenutku. Omogoča primerjavo med:

• načrtovanim in dejanskim obsegom,
• načrtovanimi in dejanskimi količinami,
• ciljnimi in dejanskimi stroški,
• načrtovanimi in dejanskimi roki.

Toda baseline ni napoved prihodnosti z absolutno gotovostjo.

Je najboljša strokovna opredelitev projekta na podlagi informacij, ki so bile v tistem trenutku na voljo.

Dober začetni načrt zato ni tisti, ki se nikoli ne spremeni.

Dober začetni načrt je dovolj jasen, da lahko vsako poznejšo spremembo prepoznamo, ocenimo in primerjamo z začetnim stanjem.

Projekt se skozi spremembe uči

Projekt skozi svoj razvoj pridobiva nove informacije.

Z raziskavami, projektiranjem, razpisom in predvsem izvedbo se del začetne negotovosti razjasnjuje. Bolje poznamo dejanske razmere, količine, izvedljivost rešitev, potrebe uporabnika ter posledice posameznih odločitev.

Razvoj projekta lahko zelo poenostavljeno prikažemo tudi kot zaporedje:

IDP → PZI → ponudba → pogodba → izvedba → spremembe → končno stanje

Vsaka od teh razvojnih stopenj predstavlja sliko projekta na podlagi takrat razpoložljivega znanja.

Zato je primerjava teh stanj izredno pomembna.

Po zaključku projekta bi morali znati odgovoriti:

Kje so se količine bistveno spremenile?
Katere projektne rešitve so se spremenile?
Kje je pogodbeno stanje odstopalo od projektantske ocene?
Katere spremembe so bile posledica novih okoliščin in katere pomanjkljivosti?
Kakšen je bil njihov vpliv na stroške in rok?
Kaj bi lahko pri naslednjem projektu vedeli ali naredili drugače?

Takšna analiza ni samo obračun preteklosti.

Je povratna informacija projektantom, popisovalcem, planerjem, naročniku, inženirju in izvajalcu.

Projekt, ki zna spremembe analizirati tudi po zaključku, ustvarja znanje za naslednji projekt.

Spremembe se začnejo že pred gradnjo

Ko govorimo o spremembah, običajno pomislimo na dodatna dela med izvedbo.

Toda projekt se spreminja skozi celoten življenjski cikel.

Faza projekta	Značilne spremembe
Priprava investicije	sprememba potreb, programa, lokacije, proračuna ali načina financiranja
Projektiranje	sprememba tehničnih rešitev, materialov, dimenzij, zahtev uporabnika ali soglasodajalcev
Razpis	pojasnila dokumentacije, popravek popisa, sprememba količin, rokov ali pogodbenih zahtev
Izvedba	nepredvidene razmere, spremembe tehnologije, napake in neusklajenosti dokumentacije, zahteve naročnika
Predaja in zagon	prilagoditve sistemov, rezultati testiranj, zahteve uporabnikov, dopolnitve dokumentacije

Nekatere spremembe so majhne in nimajo pomembnih posledic.

Druge lahko vplivajo na:

• funkcionalnost objekta,
• kakovost,
• varnost,
• količine,
• stroške,
• terminski plan,
• pogodbena razmerja,
• dovoljenja,
• obratovanje in vzdrževanje.

Zato sprememb ne smemo obravnavati samo kot finančne postavke, ki se pojavijo ob koncu gradnje.

Sprememba je najprej tehnično in projektno vprašanje. Šele nato lahko postane tudi finančno, terminsko ali pogodbeno vprašanje.

Vse spremembe nimajo istega vzroka

V javnih razpravah se spremembe pogosto samodejno razumejo kot dokaz napake projektanta, slabega naročnika ali neupravičene zahteve izvajalca.

V praksi so razlogi bistveno bolj raznoliki.

Razvoj potreb naročnika

Med pripravo ali izvedbo se lahko spremenijo:

• zahteve uporabnikov,
• organizacija dejavnosti,
• potrebne zmogljivosti,
• standard opreme,
• funkcionalni program.

Takšna sprememba je lahko popolnoma zavestna poslovna odločitev naročnika.

Nove informacije

Pri rekonstrukcijah, zemeljskih delih in posegih v obstoječo infrastrukturo vseh razmer pogosto ni mogoče vnaprej popolnoma poznati.

Med izvedbo se lahko odkrijejo:

• drugačna sestava tal,
• neznani vodi,
• skrite poškodbe konstrukcije,
• nevarni materiali,
• neustrezna obstoječa dokumentacija,
• odstopanja dejanskega stanja od posnetkov.

Nova informacija ne pomeni nujno, da je nekdo storil napako. Lahko pomeni, da se je del negotovosti projekta šele zdaj razjasnil.

Napake ali pomanjkljivosti

Nekatere spremembe so posledica:

• projektantske napake,
• pomanjkljive koordinacije,
• napačne količine,
• nepopolnega popisa,
• nepravilne izvedbe,
• nepravočasne odločitve.

Tudi takšne spremembe je treba jasno prepoznati in ustrezno obravnavati.

Toda ugotavljanje odgovornosti ne sme nadomestiti prve naloge projekta: čim hitreje določiti strokovno ustrezno rešitev in preprečiti nadaljnjo škodo.

Zunanje okoliščine

Projekt lahko spremenijo tudi okoliščine, ki jih posamezni udeleženci neposredno ne obvladujejo:

• nove zahteve pristojnih organov,
• spremembe predpisov,
• motnje v dobavnih verigah,
• nedostopnost materiala ali opreme,
• vremenski in naravni dogodki,
• spremembe prometnih ali logističnih pogojev.

Optimizacija projekta

Sprememba je lahko tudi izboljšava.

Izvajalec, projektant ali Inženir lahko predlaga rešitev, ki:

• poenostavi izvedbo,
• skrajša rok,
• zmanjša stroške,
• izboljša kakovost,
• zmanjša negotovost ali izpostavljenost tveganjem,
• olajša poznejše vzdrževanje.

Prepoved vseh sprememb bi zato pomenila tudi prepoved strokovnega izboljševanja projekta.

Negotovost, tveganje, sprememba in zahtevek niso ista stvar

Ti izrazi se pogosto uporabljajo kot sopomenke, čeprav opisujejo različne pojave.

Negotovost pomeni, da določenega dela prihodnosti ali dejanskega stanja še ne poznamo.

Tveganje je prepoznana in ovrednotena možnost dogodka, ki bi lahko vplival na projekt.

Dogodek ali nova informacija pomeni, da se je nekaj dejansko zgodilo oziroma razjasnilo.

Predlog spremembe je možen odziv na novo stanje, zahtevo ali priložnost.

Odobrena sprememba je odločitev, da se osnovni obseg, rešitev, rok, strošek ali drug element projekta spremeni.

Zahtevek je uveljavljanje pogodbenega, časovnega ali finančnega upravičenja ene od pogodbenih strani.

Aneks je eden od možnih načinov formalne ureditve spremembe pogodbenega razmerja.

Osnovno zaporedje lahko poenostavljeno prikažemo tako:

negotovost → dogodek ali nova informacija → analiza → predlog → odločitev → sprememba → izvedba

Zahtevek in aneks se lahko pojavita kot pogodbeni posledici tega procesa, nista pa sam proces obvladovanja spremembe.

Zato:

• vsaka sprememba ni dodatno delo,
• vsaka sprememba ne povzroči zahtevka,
• vsak zahtevek ni avtomatično upravičen,
• vsaka sprememba ne zahteva nujno aneksa,
• aneks pa sam po sebi še ne dokazuje, da je bila sprememba kakovostno obravnavana.

Aneks ni proces obvladovanja sprememb

Na nekaterih projektih se spremembe začnejo sistematično obravnavati šele, ko je treba pripraviti aneks.

Takrat so dela pogosto že izvedena, roki že podaljšani, količine že povečane, prvotne odločitve pa razpršene po zapisnikih, elektronski pošti in ustnih dogovorih.

Nato se za nazaj ugotavlja:

• kdo je spremembo zahteval,
• kdaj je bila odobrena,
• zakaj je bila potrebna,
• katere druge možnosti so bile preverjene,
• kakšen je njen dejanski strošek,
• ali je vplivala na rok,
• kdo je za posledice odgovoren.

To je obratna logika.

Aneks bi moral biti morebitni formalni rezultat že izvedenega postopka odločanja, ne pa začetek raziskovanja, kaj se je na projektu sploh zgodilo.

Kakovosten proces mora obstajati pred izvedbo spremembe oziroma takoj, ko je potreba po njej prepoznana.

Kako naj poteka obvladovanje spremembe?

Postopek mora biti prilagojen velikosti in kompleksnosti projekta, osnovna logika pa je podobna pri vseh projektih.

Korak	Ključno vprašanje
Evidentiranje	Kaj se je zgodilo oziroma kaj se predlaga?
Opredelitev vzroka	Zakaj je sprememba potrebna?
Tehnična presoja	Katere rešitve so možne?
Ocena vplivov	Kaj sprememba pomeni za kakovost, stroške, rok in negotovosti?
Določitev odgovornosti	Kdo mora pripraviti podlage in kdo lahko odloči?
Odločitev	Ali se sprememba odobri, zavrne ali dopolni?
Pogodbena ureditev	Ali ima sprememba pogodbene ali finančne posledice?
Izvedba	Kako in kdaj bo sprememba izvedena?
Posodobitev podatkov	Kateri načrti, popisi, plani in evidence se morajo spremeniti?
Zaključek	Ali je bila odločitev izvedena in ustrezno dokumentirana?

Pri manjšem projektu je ta postopek lahko zelo preprost.

Pri kompleksnem projektu pa mora biti formaliziran, saj posamezna sprememba lahko vpliva na več projektantov, izvajalcev, pogodb in rokov hkrati.

Spremembe se ne ocenjujejo samo po ceni

Najbolj vidna posledica spremembe je pogosto njena cena.

Zato se razprava hitro zoži na vprašanje:

Koliko dodatno stane?

Toda sprememba ima lahko tudi druge, bistveno pomembnejše posledice.

Pri presoji je treba preveriti vsaj:

• tehnično ustreznost,
• funkcionalnost,
• kakovost,
• varnost,
• vpliv na dovoljenja in soglasja,
• vpliv na količine in stroške,
• vpliv na terminski plan,
• vpliv na druge izvajalce,
• vpliv na logistiko in faznost,
• vpliv na obratovanje in vzdrževanje,
• nove negotovosti in tveganja, ki jih sprememba ustvarja.

Cenejša rešitev ni nujno boljša, če podaljša izvedbo ali poveča stroške vzdrževanja.

Hitrejša rešitev ni nujno boljša, če zmanjša kakovost.

Tehnično boljša rešitev ni nujno izvedljiva, če je dobavni rok opreme predolg.

Obvladovanje sprememb je zato izrazito interdisciplinaren proces.

Ena sprememba ustvari verigo posledic

Sprememba ni samo nov načrt ali nov dokument.

Spremenjena tehnična rešitev lahko zahteva tudi spremembo:

• projektne dokumentacije,
• BIM-modela,
• popisa del,
• količin,
• cene,
• kalkulacije,
• terminskega plana,
• nabave,
• pogodbenega obsega,
• situacij,
• poročil,
• dokumentacije izvedenih del.

Če se sprememba vnese samo v en dokument, projekt izgubi enotno resnico.

Načrt lahko prikazuje novo rešitev, popis pa staro. Terminski plan lahko še vedno temelji na prvotni tehnologiji. Nabava lahko naroči opremo po prejšnji specifikaciji. Situacija pa se nato obračuna po tretji razlagi.

Zato je sprememba predvsem povezava med podatki in odločitvami.

Kakovostno obvladovana sprememba mora povezati:

vzrok → predlog → strokovno presojo → odločitev → strošek → rok → izvedbo → končno dokumentacijo

Prav ta povezava je eden ključnih gradnikov digitalnega dvojčka projekta.

Register sprememb ni seznam dodatnih del

Register sprememb se včasih razume samo kot finančni seznam:

• številka spremembe,
• izvajalec,
• opis,
• vrednost,
• status aneksa.

To je premalo.

Dober register mora odgovoriti tudi na vprašanja:

• Kdo je spremembo predlagal?
• Kdaj je bila prepoznana?
• Kaj jo je povzročilo?
• Na katere dele projekta vpliva?
• Katera dokumentacija je povezana z njo?
• Katere možnosti so bile obravnavane?
• Kakšen je vpliv na rok?
• Kdo je pristojen za odločitev?
• Kdaj je bila odločitev sprejeta?
• Ali je sprememba že izvedena?
• Ali so bili vsi povezani podatki posodobljeni?

Pomemben je tudi status spremembe. Na primer:

• evidentirana,
• v pripravi podlag,
• v tehnični presoji,
• v finančni in terminski analizi,
• v odločanju,
• odobrena,
• zavrnjena,
• v izvedbi,
• zaključena.

Če projekt ne loči med predlagano, odobreno in izvedeno spremembo, zelo hitro nastane več različnih razlag dejanskega stanja.

Najnevarnejše so nevidne spremembe

Projekt brez evidentiranih sprememb ni nujno stabilen projekt.

Lahko je projekt, na katerem se spremembe:

• obravnavajo samo ustno,
• skrivajo v zapisnikih,
• izvajajo brez predhodne odobritve,
• prikazujejo kot manjše prilagoditve,
• finančno urejajo šele ob zaključku,
• v terminski plan sploh ne vključijo.

Takšen projekt ima navidezno malo sprememb, v resnici pa postopoma izgublja nadzor nad svojim obsegom, rokom in vrednostjo.

Najnevarnejše spremembe zato niso vedno najdražje.

Najnevarnejše so tiste, za katere različni udeleženci niti ne vedo, da jih razumejo različno.

Register sprememb ni seznam krivcev

Eden od razlogov za pozno evidentiranje sprememb je strah.

Kdor spremembo prijavi, se lahko boji, da bo avtomatično označen kot odgovoren za napako ali povečanje stroškov.

Zato se problem najprej zmanjšuje, preimenuje ali prelaga. Čaka se, da bo rešitev morda nastala sama od sebe. Medtem pa se zmanjšuje število možnih ukrepov in povečujejo posledice.

Zrelo projektno vodenje mora ločiti dve vprašanji:

1. Kaj moramo storiti, da zaščitimo projekt?
2. Kdo je pogodbeno ali strokovno odgovoren za nastalo stanje?

Obe vprašanji sta pomembni.

Toda če se najprej ukvarjamo samo z iskanjem krivca, lahko izgubimo čas, v katerem bi še lahko omejili posledice.

Zgodnje evidentiranje spremembe zato ne sme pomeniti avtomatičnega priznanja odgovornosti.

Pomeniti mora, da je projekt prepoznal novo stanje in začel organizirano odločati.

Dober sistem sprememb ne pomeni, da sprejmemo vse

Trditev, da so spremembe normalen del projekta, ne pomeni, da je treba vsako predlagano spremembo odobriti.

Nasprotno.

Urejen proces omogoča, da se sprememba:

• odobri,
• zavrne,
• spremeni,
• odloži,
• združi z drugo rešitvijo,
• izvede brez spremembe pogodbene vrednosti,
• ali vrne v dodatno strokovno presojo.

Namen procesa ni olajšati potrjevanja dodatnih del.

Namen je zagotoviti, da se o vsaki pomembni spremembi sprejme strokovno, pravočasno in dokumentirano odločitev.

Projekt, ki sprememb ne obvladuje, ima običajno dve skrajnosti:

• spremembe se zavračajo samo zato, da se ohranja videz nespremenjenega projekta;
• ali pa se izvajajo brez zadostne presoje, ker jih je treba na gradbišču hitro rešiti.

Obe skrajnosti sta nevarni.

Preprečevanje in obvladovanje sprememb se ne izključujeta

Dobra priprava projekta lahko prepreči številne nepotrebne spremembe.

Kakovostnejše raziskave, boljša projektna dokumentacija, usklajen popis, realen terminski plan in zgodnje vključevanje ključnih strok zmanjšujejo število sprememb, ki nastanejo zaradi napak ali pomanjkljivosti.

Toda cilj dobre priprave ni ustvariti iluzijo, da se projekt ne bo več spremenil.

Zrel pristop vključuje oboje:

• preprečevanje sprememb, ki bi jih bilo mogoče preprečiti;
• učinkovito obvladovanje sprememb, ki jih ni bilo mogoče ali smiselno preprečiti.

To je bistvena razlika med načrtovanjem in prerokovanjem.

Načrtovanje postavi smer, cilje in izhodišče.

Projektno vodenje pa zagotavlja, da se projekt tudi ob novih informacijah in spremembah še vedno premika proti svojim ciljem.

Sprememba kot projektno znanje

S tem pa se proces ne bi smel končati.

Če spremembo samo evidentiramo, imamo zapis.

Če razumemo njen vzrok, preverjene alternative, sprejeto odločitev ter posledice za stroške, rok in izvedbo, imamo projektno znanje.

Če to znanje po zaključku analiziramo in prenesemo v projektiranje, popise, normative, kalkulacije, terminske plane in pripravo naslednjih projektov, dobimo organizacijsko učenje.

Prav zato so zaključne primerjave med začetnimi ocenami, projektno dokumentacijo, pogodbo in dejansko izvedbo tako pomembne.

Projektantu lahko pokažejo, katere količine so bile napačno ocenjene. Popisovalcu, katere postavke so manjkale. Naročniku, katere zahteve so se razvijale med projektom. Planerju, kateri vplivi so povzročili zamike. Celotni organizaciji pa, katere negotovosti mora naslednjič obravnavati bolje.

Največja napaka zato ni, da se projekt spremeni. Največja napaka je, da iz spremembe ničesar ne izvemo.

Prav sposobnost povezovanja začetnega stanja, sprememb, odločitev, izvedbe in pridobljenega znanja je ena ključnih vrednosti digitalnega dvojčka projekta.

MYTHBUSTERS

❌ MIT

Spremembe so predvsem dokaz slabo pripravljenega projekta.

✅ REALNOST

Nekatere spremembe so posledica napak, številne pa nastanejo zaradi novih informacij, zunanjih okoliščin ali zavestnih odločitev.

💡 KLJUČNA MISEL

Kakovosti projekta ne določa odsotnost sprememb, ampak kakovost njihovega obvladovanja in učenja iz njih.

❌ MIT

Spremembe bomo uredili z aneksom ob koncu projekta.

✅ REALNOST

Aneks je lahko formalni rezultat odločitve, ne more pa nadomestiti pravočasne tehnične, finančne in terminske presoje.

💡 KLJUČNA MISEL

Spremembo je treba obvladovati takrat, ko nastane, ne takrat, ko jo je treba za nazaj pojasnjevati.

Ključne ugotovitve

• Spremembe nastajajo v vseh fazah projekta in niso omejene samo na izvedbo.
• Dober začetni načrt je nujen, vendar ne more odpraviti vseh negotovosti.
• Sprememba sama po sebi ni dokaz napake.
• Sprememba, zahtevek, dodatno delo in aneks niso isti pojmi.
• Vsaka pomembna sprememba potrebuje tehnično, finančno in terminsko presojo ter jasno odločitev.
• Register sprememb mora povezovati vzrok, odločitev, stroške, rok, izvedbo in posodobljeno dokumentacijo.
• Projekt brez evidentiranih sprememb ni nujno dobro voden; spremembe so lahko samo nevidne.
• Zaključna analiza sprememb mora postati vir znanja za naslednje projekte.

Zaključna misel

Vprašanje ni, ali bodo spremembe nastale. Vprašanje je, ali bomo spremembe obvladovali mi – ali bodo one obvladovale projekt.