Zašto su Bussiness Analysis procesi nezaobilazni u velikim projektima Miroslav Aničin, MScEE, PMP, PBA, ACP, CBAP, CSM, CSPO

Podsjetnik

Medijski pokrovitelj: Hvala sponzorima Medijski pokrovitelj:

Sadržaj uvod zaplet rasplet pogovor zaključak pitanja i odgovori

I put od tisuću milja počinje prvim korakom uvod

Uspješnost IT projekata

Zašto IT projekti nisu uspješni? Loše upravljanje programima i projektima Loše planiranje projekta Nejasni i nedefinirani ciljevi (goals and objectives) Neusaglašenost sa poslovnom strategijom Problem pokretne mete – ciljevi se mijenjaju tokom izvođenja projekta Nekompletni i nejasno definirani zahtjevi Nerealistične procjene resursa Nepostojanje podrške managementa Loša komunikacija na projektu Nefunkcioniranje kao jedinstven tim Nedovoljno iskustva ili loše odabrani članovi tima Nepostojanje metrike za vrijednovanje uspješnosti projekta Nepostojanje upravljanja rizicima Nesposobnost upravljanja promjenama

Kako stvari funkcioniraju u agilnom okruženju?

Suština svih Agile metodologija

Zašto IT projekti nisu uspešni? Loše upravljanje programima i projektima Loše planiranje projekta Nejasni i nedefinirani ciljevi (goals and objectives) Neusaglašenost sa poslovnom strategijom Problem pokretne mete – ciljevi se mijenjaju tokom izvođenja projekta Nekompletni i nejasno definirani zahtjevi Nerealistične procjene resursa Nepostojanje podrške managementa Loša komunikacija na projektu Nefunkcioniranje kao jedinstven tim Nedovoljno iskustva ili loše odabrani članovi tima Nepostojanje metrike za vrijednovanje uspješnosti projekta Nepostojanje upravljanja rizicima Nesposobnost upravljanja promenama

In 2009, IAG Consulting conducted a Business Analysis Benchmark survey that classified 74% of companies as having a low level of requirements management maturity, resulting in missed deadlines, budget overruns and wasted resources.

37% PMI’s 2014 annual global Pulse of the Profession® study revealed that “inaccurate requirements gathering” remained a primary cause of project failure in 2014

Kako još definirati neuspeh projekta? Projekti mogu biti uspješni prema ranijoj definiciji, pa da ipak budu neuspješni prema drugim kriterijima Google search kada ukucate “Project Failure” identifikuje skoro isključivo IT Project Failure! Neuspjeh projekta je nemogućnost da projekat isporuči željene benefite za stakeholdere Neuspjeh je relativan i postoji više nivoa neuspjeha, od kompletnog neuspjeha do djelimičnog i svaki od njih mora se razmatrati u kontekstu

Kompleksnost uspešnosti Neuspjeh je veoma jednostavan: bilo koji dio ili link može da uzrokuje grešku ili neuspjeh. Milioni su načina da se to desi Uspjeh je veoma težak: postoji samo JEDAN način da se uspije – ispravnim balansiranjem svih elemenata projekta

Nivoi neuspješnosti 1/2 Totalni neuspjeh Ozbiljan neuspjeh Projekat prekinut prije završetka Greška nakon implementacije je toliko ozbiljna da se sve moralo vratiti na raniju verziju ili na raniji način rada. Organizacija značajno gore funkcionira nego ranije Ozbiljan neuspjeh Produkt (rezultat projekta) je funkcionalan ali ne daje pune benefite Manje je efikasan i efektivan od starog sistema Više troškova od benefita

Nivoi neuspješnosti 2/2 Srednji neuspjeh Lagani neuspjeh Neki benefiti su ostvareni, ali ne svi Mnogo toga je tolerirano Potrebno je uraditi značajne prepravke Lagani neuspjeh U najvećoj mjeri su benefiti isporučeni uz manje tolerancije (vrijeme, troškovi, kvalitet, prijenos znanja,...)

(Ne)uspjeh Razmatranje (zbog lakšeg razumijevanja) nekoliko direktnih razloga neuspjeha projekata Slučajni projektni menadžer Usputna business analiza Nerazlikovanje obuhvata rješenja od obuhvata projekta Neusaglašavanje projekta sa poslovnom strategijom Kruto pridržavanje projektne metodologije bez razumijevanja

(Ne)uspjeh Razumijevanje obuhvata vodi ka razumijevanju osnovnih razloga (ne)uspješnosti projekata Obuhvat rješenja - Solution Scope Set karakteristika neophodan da bi se ispunili poslovni zahtjevi Obuhvat projekta - Project Scope Posao potreban da bi se implementiralo rješenje

(Ne)uspjeh Project Manager je odgovoran za obezbjeđivanje rješenja korisniku na vrijeme, u zadatom budžetu, obuhvatu i kvalitetu. Business Analyst je odgovoran da obezbjedi rješenje u skladu sa definiranim zahtjevima. Razlika u fokusu je razlog zašto su obje uloge na projektu kritične. Zanemarivanje jedne od ovih uloga direktno izaziva razloge neuspjeha

(Ne)uspjeh Business Analiza Obezbjeđuje razumijevanje: Kako organizacija funkcionira Zašto organizacija postoji Koji su ciljevi koje organizacija želi postići Kako će organizacija postići te ciljeve Na koji način organizacija treba da se promijeni kako bi postigla definirane ciljeve i prevazišla probleme Definira obuhvat rješenja i samo rješenje Definira zahtjeve (requirements) svih nivoa

(Ne)uspjeh Poslovni analitičar obezbjeđuje da projekat postigne zahtjeve business-a. On pomaže poslovnom okruženju da prepozna i razumije svoje potrebe, te da specificira zahtjeve koji će voditi do optimalnog rješenja čija će isporuka postići željene rezultate.

(Ne)uspjeh Poslovni analitičar Funkcionira kao veza među stakeholderima sa ciljem da razumije strukture, pravila, procedure i operacije organizacije i da predloži rješenja koja će omogućiti organizaciji postizanje ciljeva Razumije kako organizacija funkcionira da bi ispunila svoju svrhu Definira organizacione strateške ciljeve Kako su ti strateški ciljevi povezani sa specifičnim ciljevima Određuje smjer aktivnosti koje business treba preuzeti kako bi postigao te specifične i strateške ciljeve Definira kako različite organizacione jedinice i stakeholderi u organizaciji trebaju surađivati

Zahtjevi (Requirements) Definicija Prema BABOK®,  zahtjev u poslovnoj analizi je Stanje ili sposobnost potrebna stakeholderu da riješi problem ili postigne cilj. Stanje ili sposobnost koja se mora postići ili posjedovati od strane komponente rješenja kako bi se zadovoljio ugovor, standard, specifikacija ili druga formalno definirana dokumenta. Dokumentirana prezentacija stanja ili sposobnosti navedenih pod (1) ili (2).

Vrste Zahteva Business zahtjevi – Business Requirements Zahtjevi visokog nivoa, poslovne potrebe, strateški ciljevi poduzeća Zahtjevi Stakeholdera – Stakeholder requirements Zahtjevi stakeholdera koji definiraju njihove potrebe, njihovu interakciju sa budućim rješenjem Zahtjevi rješenja - Solution Requirements Funkcionalni Nefunkcionalni Prijelazni zahtjevi - Transition Requirements Implementacioni zahtjevi za prelazak sa starog na novo rješenje

Vrste Zahteva Business Requirements Enterprise Analysis Stakeholder Requirements Solution Requirements Functional Requirements Nonfunctional Requirements Transition Requirements Enterprise Analysis Requirements Analysis Solution Assesment & Validation

Tko je sve uključen? Regul Spon Business Analyst Business Analyst Project Manager Regulator Project Manager Regul Regulator nager Implement- ation SME Sponsor Implement- ation SME n SME Spon Sponsor Domain SME Supplier Domain SME Supplier Business Analyst Customer Tester Business Analyst Customer Tester

Životni ciklus projekta Page no 42, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition, ©2013 Project Management Institute

Životni ciklus projekta Page no 43, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition, ©2013 Project Management Institute

Poslovna analiza u projektnom kontekstu Project Solution Evaluation Need Assessment Need Assessment, Planning, Analysis, Traceability Monitoring and Evaluation

Domen poslovne analize Analysis Solution Evaluation Need Assessment Planning Traceability and Monitoring Its not a sequential process but iterative

Page no 51, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition, ©2013 Project Management Institute

Elicitation and Analysis of Solution Requirements Business Stakeholder Solution Elicitation and Analysis of Solution Requirements

Traceability and Monitoring Source Implementation Traceability Propose Analysis Development Implementation Monitoring

Rezime Dati business analizi ključnu poziciju na projektu Izbjeći situaciju „analiza – paraliza“ Prilagoditi requirement modele stakeholderima Pretjerati sa komunikacijom I nakon toga komunicirati

Pitanja

Deming cycle