Tänään on 05.12.2016 16:32 ja nimipäiväänsä viettää: Selma. MOBIILIVERSIO M.BLOGIVIRTA.FI

Perheyrittäjyys Family Business: Projektin sisällön ja muutosten ohjaus

Julkaistu: · Päivitetty:

Sisällön ja muutosten ohjaus (197-216) Projektin sisällön hallinnan tehtävä voidaan määritellä, että sen tavoitteena on varmistaa, että riittävä määrä työtä eikä yhtään enempää tehdään projektin tavoitteiden saavuttamiseksi. Tämä jakautuu kolmeen osa-alueeseen 1.  määrittelyn mukaisen työn aikaansaaminen, 2. varmistamine, ettei ylimääräisiä töitä tehdä ja 3. tehty työ edesauttaa projektin päämäärän ja liiketoiminnallisten tavoitteiden saavuttamista. (Pelin 2011, 197.) Sisällön määrittely ja ohjaus liittyy erityisesti seuraaviin projektin vaiheesiin. Projektin tavoitteiden pohjalta aikaansaatu projektin määrittely, projektin osoittaminen työpaketeiksi ja työpakettien rajaukset ja määrittely sekä tehtävien toimeksiannot ja ohjaus.  (Pelin 2011, 198.) Tärkeintä on saada projektin alussa aikaan selkeä ja kattava määrittely ja sopimus projektin toteutusta varten. On tehtävä ero toiveiden ja todella tärkeiden asioiden välillä. Pelin (2011, 198) toteaa, että monet projektit käynnistetään sisälön määrittelyn ollessa vielä epätäsmällistä, seurauksena on helposti sisällön laajeneminen projektin aikana. Hyväksytty projektisuunnitelma ja tekniset määrittelyt toimivat projektin ohjauksen perustana. (Pelin 2011, 198.) Sisällön ja vaatimusten määrittely Projektin liiketoiminnaliset tavoitteet (päämäärä) kuvaavat miksi projekti on käynnistetty ja miksi joku haluaa maksaa sen (Pelin 2011, 198). Projektin päämäärä ja tavoitteet tarkentuvat sidosryhmävaatimuksiksi (Stakeholder Requirements) ja käyttäjävaatimuksiksi (User Requirements). On tavallista, että vaatimuksia on paljon ja eri sidosryhmien vaatimukset ovat keskenään ristiriitaisia. Vaatimukset ovat tyypillisesti a) asikas- tai sidosryhmälähtöisiä, b) tuotelähtöisiä (T & K projektit) tai c) lainsäädännöllisiä. (Pelin 2011, 199.) Vaaatimukset ohjaavat suunnittelua ja niiden pohjalta määritellään suunnitteluratkaisut, jotka todennetaan vastaavia vaatimuksia vastaan.  (Pelin 2011, 202.) Termejä  tuoteominaisuudet (feature list) todentaminen (verification) kelpuutusvaihe (validation) ---- vatimukset voidaan järjestää tärkeysjärjestykseen esim.  - pakko-vaatimukset - toivottavat vaatimukset - minimi vaatimukset - optiot (Pelin 2011, 199.) Hyvä vaatimus täyttää seuraavat asiat - selkeä ja täsmällinen - ei rajoita liikaa suunnittelua - on helposti ymmärrettävä - ei ole ristiriidassa muiden vaatimusten kanssa (Pelin 2011, 1999). Vaatimustmäärittelyyn on löydettävissä mallipohjia. Tässä yksi aika selkeä  Mallipohja . (22.11.2016) Toimittajan on otettava huomioon esim. seuraavia vaatimusten tarkentamisseikkoja: - asikakkaan vaatimusten täsmentäminen ja yksiselitteisyys laskettaessa projektin kustannuksia - vaatimukset, jotka toimittajan aikaisempien kokemusten perusteella ovat olleet vastaavassa projektissa tärkeitä, haluaako asiakas myös nämä asiat - välttämättämät toiminnalliset ja lakisääteiset vaatimukset - toimittajaorganisaation omat vaatimukset (Pelin 2011, 202-203.) Todentamisvaiheeseen sisältyy seuraavia toimenpiteitä - testaukset (komponentit, prototyypit) - vikojen etsintä ja korjaaminen - vaatimusten todentaminen - tuotteen valmistettavuuden todentaminen - suunnittelun FMEA ja riskien analysointi Kelpuutusvaiheeseen sisältyvät seuraavat asiat - sisäinen/ulkoinen kelpuutus - ympäristövaatimusten testaus - tuotteen turvallisuus - asiakashyväksyntä, pilot-asiakkaat - täyttääkö tuote käyttäjävaatimukset. (Pelin 2011, 205.) Muutosten hallinta Projektin aikana saattaa ilmaantua syitä joidan takia projektin alussa asetettuja tavoitteita tai vaatimuksia pitää muuttaa. Syitä muutoksiin voivat olla esim. markkinatilanteen muutokset uudet innovaatiot kilpailijoiden toimenpiteet asiakkaan täsmentyneet tarpeet ulkoiset muutokset (viranomaiset, lait, organisaatiomuutokset) toiset kehitysprojektit tilaajan vaatimukset  Muutosten hallinnan vaiheet Muutosehdotuksen laatiminen Muutoksen vaikutusten arviointi Asiantuntijalausunnot Muutosten käsittely: hyväksyminen/hylkääminen Muutoksen suoritus Muutoksen dokuemntointi Tiedottaminen muutoksesta (Pelin 2011, 205-207.) Muutosehdotus on hyvä laatia  sitä varten suunnitellulle lomakkeelle. Lomake yhdenmukaista käytännön ja varmistaa, että oleelliset seikat otetaan  huomioon. Muutosehdotukseen tulevat seuraavat tiedot yleistiedot muutoksesta (nimi, numero, sisältö, laatija jne.) syy muutokseen ja perustelut muutoksen vaikutusten arviointi (projektiin, tuotantoon, ympäristöön, asiakkaaseen, muihin projekteihin) käsittelymerkinnät ja hyväksymiset (Pelin 2011, 209). Jos kysymys on toimitusprojektista on lisäksi saatava asiakkaan hyväksyntä (Pelin 2011, 209). Pari esimerkkiä muutosluettelosta (Change Log)  Lähde https://confluence.atlassian.com/jira063/files/683542546/683904303/1/1363847158655/jira-browse_project-changelog.png   Ks. myös  https://confluence.atlassian.com/jira063/browsing-a-project-s-change-log-683542546.html (24.11.2016). Lähde http://www.androidheadlines.com/wp-content/uploads/2015/09/Screenshot-94-e1442011810318.png ja teksti  http://www.androidheadlines.com/2015/09/google-posts-changelog-of-nexus-security-update-fixes.html (24.11.2016). Kuvan lähde http://blog.epmainc.com/wp-content/uploads/04%20Change%20Highlighting%20disabled.jpg   (24.11.2016) Ks. teksti http://blog.epmainc.com/disable-change-highlighting-microsoft-project-2010-and-2013/ (24.11.2016). Muutoksista laaditaan yleensä myös muutostiedote Tässä taoulukossa on listaus erilaisista projektiin liittyvistä dokumenteista   Kuvan lähde https://patriciambenedict.files.wordpress.com/2013/04/pmp-docs.jpg (24.11.2016).  Teksti tästä linkistä https://patriciambenedict.wordpress.com/step-6/ (24.11.2016) Kuvan lähde http://eng.pmdoc.ru/templates_relation.gif   sivun lähde http://eng.pmdoc.ru/templates.html (24.11.2016). Konfiguraation hallinta Konfiguraation hallinta on menetelmä, jolla ohjataan muutoksia, suunnitteluversioita ja tuotteen komponentteja. Konfiguraation on täydellinen tekninen kuvaus järjestelmästä tai laitteesta. Sen pohjalta voidaan valmistaa, testa, hyväksyä, käyttää tai ylläpitää järjestelmää. (Pelin 2011, 212) Etuja joita saavutetaan konfiguraation hallinnalla ovat muutoksen  tekemiseen tulee muodollinen prosessi, kaikki näkökulmat ja vaikutukset arvioidaan ennen muutosten tekemistä luvattominen muutosten teko estetään varmistaan tuotteen kokonaishallinnan muutoskustannukset alenevat aikatauluvaikutukset arvioidaan ennen muutosten tekoa suunnittelukatselmuksen käyttö eri suunnittelualueiden vuorovaikutusten anaysointi ja dokumentointi täsmällinen ja täydellinen kirjanpito kaikista muutoksista (Pelin 2011, 213.)  Konfiguraation alkiot (configuration item) määritelty piirustus, ohjelmistomoduuli, osaluettelo jne. jolle annetaan tunnistekoodi (spec.no., version no, drawing no, status. Konfiguraation alkio on kokonaisuus, jota ei muutosten hallinnan kannalta tarvitse jakaa pienempiin osiin. Alkiot ovat sellaisinaan ylläpidettäviä ja määriteltyjä ylemmän tason kokoonpanossa. Konfiguraation alkioita ovat: - suunnitteluanalyysit ja laskelmat - toiminnalliset määritelyt - ohjelmistot - laitemäärittelyt - kokoonpalopiirustukset - piirikaaviot - valmistuspiirustukset - osaluettelot - testisuunnitelmat - käyttöohjeet (Pelin 2011, 213.) Konfiguraation vaihetasot Aluksi tehdään konfiguraation vaihetasot (baseline), joihin sisältyy piirustusluettelo ja tuotannon materiaaliluettelo (bill of material) Teollisuusprojektin näljä päävaihetta ovat - sunnittelun vaihetaso - toteutuksen vaihetaso - tuotannon/valmistuksen vaihetaso - as-built konfiguraatio (Pelin 2011, 214.) Konfiguraation ohjaus - teknisiä ongelmia tai ohjelmistovikoja - sidosryhmiltä tulleet uudet vaatimukset - suunnitteluvirheet - materiaali tai komponenttimuutokset Muutokset voidaan jakaa kahteen kategoriaan 1. Itsenäiset muutokset - itsenäinen muutos ei vaikuta tuotteen toiminnallisuuteen. Lopputuote on aina vaihtokelpoinen tuotteen nykyisen version kanssa. Nämä muutokset käsitellän kevyemmällä muutoshallintaprosessilla. 2. Uusi versio muutos - tarvitaan uusi suunitteluversio. Tällöin käytetään muutospyyntöä (change request) ja muutos käsitellään yrityksen muutoshallintaprosessin mukaisesti. Kaksi tunnettua ohjelmistokehityksen sääntöä ovat: - mikään muutos ei ole pieni muutos - älä tee mitään muutoksia, ellei ole pakko tehdä (Pelin 2011, 215.) Konfiguraation todentaminen Konfiguraation todentaminen on systemaattinen menettely, jossa verrataan kunkin konfiguraation alkion suunnittelua (baseline) ja toteuttaa (actual / as-built) konfiguraatiota. Todentaminen suoritetaan suunnittelukatselmuksissa (Design Review) projektin vaiheiden aikana, toteaa Pelin (2011, 215) kirjoituksessaan. Katselmuksissa on useita tasoja. Kullekin dokumentille on katselmus (sisältövirheet, laatu). Sunnittelukatselmuksissa jäädytetään dokumentin kuvaama konfiguraatio ja tekniset ratkaisut. Tämän jälkeen muutosten tekeminen vaatii muutoshallintaprosessin noudattamista. Laajoille järjestelmille on omat katselmuksensa. Ylimpänä ovat projektin vaihekatselmukset (Phase Review) Kuvan lähde https://www.for.gov.bc.ca/hts/risc/pubs/aquatic/recon/assets/ch2-2-1-2.jpg ja lue lisää tästä linkistä (29.11.2016). Standardeja, jotka liittyvä konfiguraation hallintaan A number of standards support or include configuration management, [15] including: ANSI/EIA-649-1998 National Consensus Standard for Configuration Management EIA-649-A 2004 National Consensus Standard for Configuration Management TechAmerica/ANSI EIA-649-B 2011 Configuration Management Standard ISO 10007:2003 Quality management systems - Guidelines for configuration management Federal Standard 1037C GEIA Standard 836-2002 Configuration Management Data Exchange and Interoperability IEEE 829 Standard for Software Test Documentation 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering . 2012. doi : 10.1109/IEEESTD.2012.6170935 . ISBN   978-0-7381-7232-3 . MIL-STD-973 Configuration Management (cancelled on 20 September 2000) NATO STANAG 4427 Configuration Management in Systems Life Cycle Management including ACMP 2000 Policy on Configuration Management ACMP 2009 Guidance on Configuration Management ACMP 2100 Configuration Management Contractual Requirements CMMI CMMI for Development, Version 1.2 Configuration Management CMII-100E CMII Standard for Enterprise Configuration Management Extended List of Configuration Management & Related Standards ( Wikipedia 29.11.2016). Lähteet Configuration Management . Wikipedia. (29.11.2016). Pelin, Risto. (2011). Projektihallinnan käsikirja. 400 s. 7. uudistettu painos. Projektijohtaminen Oy Risto Pelin. Project management docs . Ilmaisia projektihallinnan dokumentteja. Lataa omalla vastuullasi. (24.11.2016). Projektin vaatimusmäärittely. Mallipohja . (22.11.2016) Seppänen, Vesa (2000).  Konfiguraatiohallinta .  Helsingin yliopisto. (24.11.2016).