Sisällön ja muutosten ohjaus

Sisällön hallinnan tehtävä

Projektin aikana voi ilmaantua syitä muuttaa projektille alussa asetettuja vaatimuksia tai tavoitteita. Projektin sisällönhallinta varmistaa, että riittävä määrä työtä eikä yhtään enempää tehdään projektin tavoitteiden saavuttamiseksi. Sisällönhallinta jakautuu kolmeen osa-alueeseen [Pel11]:

1. Määritellyn mukaisen työn aikaansaaminen.
2. Sen varmistaminen, että ylimääräisiä töitä ei tehdä.
3. Toimiminen niin, että tehty työ edesauttaa projektin päämäärän ja liiketoiminnallisten tavoitteiden saavuttamista.

Sisällön ja vaatimusten määrittely

Lähtökohta projektille on ongelma, asiakkaan tarve, uusi idea, ympäristön muutos tai yrityksen toiminnan kehittämistarve. Projektin liiketoiminnalliset tavoitteet kuvaavat, miksi projekti on käynnistetty. Projektin päämäärä ja tavoitteet tarkentuvat sidosryhmävaatimuksiksi ja käyttäjävaatimuksiksi. Vaatimukset asetetaan tärkeysjärjestykseen [Pel11]:

1. Pakko-vaatimukset
2. Toivottavat vaatimukset
3. Minimivaatimukset
4. Optiot.

Hyvä vaatimus on

•   otsikoitu lyhyesti ja ytimekkäästi
•   johdonmukainen - vaatimuksessa määritelty ja kuvattu vain yksi asia eikä se ole ristiriidassa muiden vaatimusten kanssa
•   täydellinen - määritelty täysin yhdessä paikassa eikä määrittelystä puutu informaatiota
•   oikea - vaatimus vastaa joko kokonaan tai osittain sidosryhmien liiketoiminnan tarpeisiin
•   voimassaoleva - aika ei ole tehnyt vaatimusta tarpeettomaksi
•   toteutettavissa - vaatimus on toteutettavissa ottaen huomioon projektin reunaehdot
•   helposti ymmärrettävä - vaatimus on ilmaistu asiakkaan terminologiaa käyttäen ilman väärintulkintojen riskiä
•   todennettavissa - toteutettuna vaatimus on testattavissa ja verifioitavissa (katselmointi, esittely, testaus).

Vaatimus painottuu vastaamaan kysymykseen ’mitä’ ottamatta tulisesti kantaa miten se toteutetaan. Vaatimusmäärittelyssä kannattaa varoa epämääräisiä ilmaisuja kuten esimerkiksi ’jotkut’, ’ilmeinen’, ’tavallisesti’, ’usein’, ’silloin tällöin’ ja ’satunnaisesti.’  Lauseet ja tekstikappaleet kannattaa pitää lyhyinä ja käyttää passiivin asemesta aktiivista muotoa. Sanat ’ja’ sekä ’tai’  pahimmassa tapauksessa ’ja/tai’  ovat merkkejä, että kyseessä onkin useita vaatimuksia yhden asemesta. Läpi kaikkien vaatimusten kannattaa pyrkiä yhtenäiseen ja johdonmukaiseen tarkkuustasoon.  Kukin vaatimus saa esiintyä vain yhteen kertaan.

Laadunhallinta

Projektin laadunhallinnassa on kaksi näkökulmaa: 1) projektin tuloksena toteutettavan tuotteen laatu, jolloin asiakasvaatimukset täyttyvät ja 2) projektinhallinnan laatu, jolloin projekti on toteutettu suunnitelman mukaan. Laadulla tarkoitetaan todettua yhdenmukaisuutta vaatimusten kanssa. Laatu koostuu suuresta joukosta pieniä asioita, jotka eivät välttämättä maksa mitään. Laatutoiminnassa kaiken a ja o ovat kokemus ja ammattitaito. Standardeilla ja sertifikaateilla varmistetaan pahimmillaan se, että kaikki tyrivät yhdenmukaisella tavalla [Ruu07, AMK06].

Muutosten hallinta

Muutostenhallinta on hyvä kuvata prosessina ja liittää prosessikuvaus projektisuunnitelmaan. Mitä pidemmälle projekti on  edennyt, sitä nihkeämmin muutosehdotuksiin on suhtauduttava. Vaikka lisätyön tekeminen ei sinällään veisi kuin muutaman päivän, niin uusilla piirteillä voi olla vaikutuksia lopputuotteen muihin osiin. Tämä taas edellyttää selvittelyä, ylimääräistä suunnittelua ja lisätestausta, jolloin kyse voikin olla jo viikon työstä [Ruu07]. Projektin muutoshallinnassa on seuraavat vaiheet [Pel11]:

1. Muutosehdotuksen laatiminen.
2. Muutoksen vaikutusten arviointi.
3. Asiantuntijalausunnot.
4. Muutosten käsittely, niiden hyväksyminen tai hylkääminen. Usein on helpointa sanoa "ei."
5. Muutoksen suoritus.
6. Muutoksen dokumentointi.
7. Tiedottaminen muutoksesta.

Muutospyyntölomakkeella on seuraavat tiedot [AMK06, Leh06]:

• muutospyynnön juokseva numero
• muutospyynnön nimi
• ehdottaja ja ehdotuspäivä
• ehdotetun muutoksen tarkempi kuvaus, jossa määritellään muutostarve, muutoksen lähde ja syy sekä muutoksen kohde
• perustelu, miksi muutos tarvitaan: hyödyt, haitat sekä seuraukset, jos muutosta ei tehdä
• vaikutus projektin aikatauluun
• vaikutus projektin hintaan ja laskutukseen
• käsittelymerkinnät ja hyväksymiset.

Hylätyt muutospyynnöt voi laittaa talteen mahdollisina kehitysideoina, koska ne voivat olla hyviä ideoita seuraavaan versioon. Kehitysideoihin on hyvä ihan aktiivisestikin ideoida asioita, vaikka niitä ei projektin muutospyyntöinä käsiteltäisikään [Leh06].