Obvladovanje generičnih rizikov na projektih razvoja programske opreme

1. Obvladovanje generičnih rizikov na projektih razvoja programske opreme Pripravila: Irena Krajnc,NKBM

2. Kratka vsebina • Statistika • Izvedba projektov • Vzroki za uspeh in neuspeh projektov • Upravljanje z uporabniškimi zahtevami • Pomanjkljivo sodelovanje z uporabniki • Razvoj uporabniških zahtev • Upravljanje s spremembami • Projektno vodenje • Podpora vodstva in sponzorstvo projekta • Upravljanje s tveganji • Strokovno znanje in zasedba vlog v projektnem teamu • Nadzor projekta • Generalni indikatorji statusa projekta • Opozorilni znaki in korektivne akcije • Bazični ukrepi za vzpostavitev kontrole projekta

3. Izvedba projektov • Povprečna prekoračitev sredstev je za velike organizacije 178%, za srednje 182% in za majhne 214% • Povprečna prekoračitev rokov je za velike organizacije 230%, za srednje 209% in za majhne 239% • Povprečen % dokončanih funkcionalnosti je za velike organizacije 42%, za srednje 65% in za majhne 74%

4. Vzroki za uspeh Vzroki za uspeh % vprašanih Skupina Sodelovanje uporabnikov 15.9 % A Podpora in sponzorstvo vodstva 13.9 % B Čiste in stabilne uporabniške zahteve 13.0 % B Ustrezno planiranje 9.6 % B Realistična pričakovanja 8.2 % A Krajša obdobja 'mejnikov' 7.7 % B Usposobljen team 7.2 % C Jasno lastništvo projekta 5.3 % AB Jasna vizija in cilji projekta 2.9 % AB Trdo delo teama 2.4 % C Ostali vzroki 13.9 % C

5. Vzroki za neuspeh Vzroki za neuspeh % vprašanih Skupina Pomanjkljivo sodelovanje z uporabniki 12.8 % A Nepopolne zahteve in specifikacije 12.3 % A Spreminjajoče se zahteve in specifikacije 11.8 % A Pomanjkanje podpore in sponzorstva vodstva 7.5 % B Nekompetentnost teama 7.0 % C Pomanjkanje sredstev 6.4 % B Nerealistična pričakovanja 5.9 % A Nejasni cilji 5.3 % B Nerealistično postavljanje rokov 4.3 % AB Nepreizkušena tehnologija 3.7 % C Ostalo 23.0 % D

6. Pomanjkljivo sodelovanje z uporabniki • Kritični dejavnik • kdo je pravi in odgovorni uporabnik. • uporabniške zahteve • Pogoste napake • spregledamo razliko med skupinami uporabnikov (vodje, operativci) • prevelika ‘kreativnost’ programerjev • nepotrebno obremenjevanje programja • vključitev šele v uporabniškem testu - t.i. sprožilec – poraba časa in stroški projekta začnejo nekontrolirano naraščatiprav v tej točki. • Preprečevanje: • vgrajevanje manjših, uporabniško orientiranih neformalnih revizij • razmerje med odpravljenimi in obstoječimi težavami.

7. Razvoj uporabniških zahtev • Proces definiranja zahtev • zbiranje kandidatov za zahteve • specificiranje zahtev • analiza zahtev • razvrščanje zahtev po njihovi pomembnosti • Predvidevanje in občutek za posledice • kaj se lahko zgodi zanesljivo, verjetno ali zelo malo verjetno • kakšne analize bo mogoče pridobiti iz podatkov čez nekaj let • s katerimi zunanjimi subjekti je IS povezan • kako občutljiv bo naš sistem za spremembe od zunaj

8. Upravljanje s spremembami • dobro definirane uporabniške zahteve • discipliniranje uporabnikov • 'Change board' • v kakšni meri se bo produkt izboljšal, • koliko uporabnikov potrebuje novo oz. spremenjeno funkcionalnost • kakšni so ti uporabniki (operativni ali pisarniški delavci, ki si lahko pomagajo tudi z drugimi orodji) • stroški • podaljšanje trajanja projekta • časovno zaporedje • ali jo je mogoče združiti • vpliv na stabilnost produkta • dodatni viri

9. Podpora vodstva in sponzorstvo projekta • večinoma formalne narave • močna ( vsaj formalno ) na začetku projekta, skozi življenjsko dobo projekta pa vedno bolj popušča • možna menjava vodstva • premajhno znanje vodstva s področja poslovne informatike in vodenja projektov • potrebno je poznavanje vsaj generalnih indikatorjev statusa projekta

10. Strokovno znanje in zasedba vlog v projektnem teamu • V fazi razvoja uporabniških zahtev je narejenih cca 20 % 'GO – NO GO' odločitev(Stroški za odpravo napake od 1: 50 do cca 1 : 200 ) • primerni visoko strokovno usposobljeni razvijalci • neizkušeni člani teama - opazovalci in kot neformalni revizorji rezultatov • V fazi designa, kodiranja in testiranja • neizkušeni člani teama lahko oz. morajo v teh fazah aktivno sodelovati • okrepiti zasedbo • Strokovne funkcije nadzora projekta • izkušen kader

11. Generalni indikatorji statusa projekta • pogostost menjave planov/mejnikov • doslednost v organizacijski strukturi projekta v primerjavi z originalnimi plani • nihanja v projektni zasedbi in ocene velikosti sistema • težavnost pristopa do informacij o projektu • količina nadur za doseganje posameznega cilja • nivo poznavanja in kontroliranja podrobnosti razvijanega sistema s strani projektnega vodje in sponzorja projekta

12. Opozorilni znaki in korektivne akcije • problemi z zahtevami in specifikacijami • število uporabniških zahtevkov, ki še niso specificirani je višje od povprečja na podobnih projektih in ne upada • število postavljenih uporabniških vprašanj je višje od števila odgovorjenih oz. narašča • veliko število modifikacij že izdelanih specifikacij • veliko število zahtevkov za spremembe oz. naraščanje števila • problemi z designom sistema • število razvitih komponent sistema je manjše kot je predvideno v planu za to fazo - slabe smernice vodje teama, neizkušenost razvijalcev, nova tehnologija oz. pogoste spremembe zahtevkov

13. Opozorilni znaki in korektivne akcije • problemi z implementacijo sistema • število kodiranih, testiranih in integriranih komponent sistema je manjše kot je predvideno v planu za to fazo • število kodiranih, testiranih in integriranih komponent sistema je dosti večje kot je predvideno v planu za to fazo • odpravljene napake se znova pojavljajo • problemi pri testiranju sistema • faza testiranja je zaradi zakasnitev predhodnih faz občutno skrajšana • nizka količina odkritih napak

14. Opozorilni znaki in korektivne akcije • problemi pri planiranju razvoja • razvojne aktivnosti so neenakomerne, storilnost pade takoj po doseganju mejnika • osebje dela na projektu samo delno • konstantno zamikanje rokov • strokovnost teama je bila precenjena oz. smernice niso dovolj stabilne • zamik rokov zaradi zamenjave članov teama • dva nova člana z visokim nivojem znanja in izkušenj namesto vsakega ključnega člana • ena oseba namesto neizkušenegačlana teama, znanje in izkušnje vsaj en nivo višje

15. Bazični ukrepi za vzpostavitev kontrole projekta • Ustavitev trenutnih aktivnosti na prizadetem delu sistema in ocenitev škode • Zmanjšanje števila osebja na upravljiv nivo • Zamenjava članov teama z izkušenimi razvijalci • Zaključek predhodnih (!) aktivnosti • Povečanje in razširitev vodstvenega nadzora • Povečanje števila vmesnih produktov • Zmanjšanje obsega projekta • Revizija projekta z neodvisnimi revizorji in UPOŠTEVANJE njihovih priporočil

16. Zaključek • Vprašanja in odgovori