Projektin sisällön ja muutosten ohjaus



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. varmistaminen, 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 vaiheisiin. 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ällö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 liiketoiminnalliset 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) asiakas- tai sidosryhmälähtöisiä, b) tuotelähtöisiä (T & K projektit) tai c) lainsäädännöllisiä. (Pelin 2011, 199.)

Vaatimukset 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)
----
vaatimukset voidaan järjestää tärkeysjärjestykseen esim. 
- pakko-vaatimukset
- toivottavat vaatimukset
- minimivaatimukset
- 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).

Vaatimustäärittelyyn on löydettävissä mallipohjia. Tässä yksi aika selkeä  Mallipohja. (22.11.2016)

Toimittajan on otettava huomioon esim. seuraavia vaatimusten tarkentamisseikkoja:
- asiakkaan 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ä joiden 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
  1. Muutosehdotuksen laatiminen
  2. Muutoksen vaikutusten arviointi
  3. Asiantuntijalausunnot
  4. Muutosten käsittely: hyväksyminen/hylkääminen
  5. Muutoksen suoritus
  6. Muutoksen dokuementointi
  7. 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)

https://confluence.atlassian.com/jira063/files/683542546/683904303/1/1363847158655/jira-browse_project-changelog.png
 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).


http://www.androidheadlines.com/wp-content/uploads/2015/09/Screenshot-94-e1442011810318.png
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).


Muutoksista laaditaan yleensä myös muutostiedote

Tässä taulukossa on listaus erilaisista projektiin liittyvistä dokumenteista
 https://patriciambenedict.files.wordpress.com/2013/04/pmp-docs.jpg
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)


http://eng.pmdoc.ru/templates_relation.gif

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 analysointi 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äärittelyt
- ohjelmistot
- laitemäärittelyt
- kokoonpanopiirustukset
- 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 neljä päävaihetta ovat
- suunnittelun 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 suunnitteluversio. 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)

https://www.for.gov.bc.ca/hts/risc/pubs/aquatic/recon/assets/ch2-2-1-2.jpg


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).




(Edit 3.4.2017)

Comments