Luku 15 Muita projektinhallinnan menetelmiä

Transkriptio

1 Luku 15 Muita projektinhallinnan menetelmiä Johdanto Luvussa 15 tarkastellaan muutamia monista muista projektinhallinnan menetelmistä. Tämä luku on pikainen katsaus käsiteltävien menetelmien tyyliin, lähestymistapaan ja joissakin tapauksissa niissä käytettyihin metodologioihin. Ohjelmiston laadunvarmistus Ohjelmiston laadunvarmistuksen (SQA, software quality assurance) tarkoitus on antaa johdolle tarkka kuva ohjelmistoprojektissa käytetystä prosessista ja rakennettavista tuotteista. Ohjelmiston laadunvarmistukseen kuuluu ohjelmistotuotteiden, prosessien, menettelyjen, tehtävien ja välietappien katselmuksia ja auditointeja sen varmistamiseksi, että ne ovat asiaankuuluvien standardien mukaisia, sekä katselmuksista ja auditoinneista saatujen tietojen jakaminen projektipäälliköille ja muulle johdolle. Ohjelmiston laadunvarmistusryhmä työskentelee yhdessä ohjelmistoprojektin kanssa sen alkuvaiheissa luodakseen suunnitelmia, standardeja ja menettelyjä, jotka tuottavat ohjelmistoprojektille lisäarvoa ja noudattavat projektin rajoituksia ja organisaation käytäntöjä. Osallistumalla näiden suunnitelmien, standardien ja menettelytapojen kehittämiseen laadunvarmistusryhmä omalta osaltaan varmistaa, että ne sopivat projektin

2 Muita projektinhallinnan menetelmiä tarpeisiin, ja todentaa, että niitä voidaan käyttää katselmuksissa ja auditoinneissa koko ohjelmiston elinkaaren ajan. Laadunvarmistusryhmä katselmoi projektin tehtävät ja auditoi ohjelmistotyötuotteet koko ohjelmistonkehityksen elinkaaren ajan sekä pitää johdon ajan tasalla sen suhteen, noudattaako projekti sille asetettuja tavoitteita ja standardeja. Ohjelmiston laadunvarmistusprosessi kattaa laadunvarmistusryhmän toiminnan käytännöt. Käytännöt, joiden mukaan tietyt tehtävät ja työtuotteet valitaan laadunvarmistusryhmän katselmoitaviksi ja/tai auditoitaviksi, sisältyvät yleensä muille avainprosessialueille yhteisesti määritettyyn toteutuksen todentaminen - ominaisuuteen. Ohjelmiston laadunvarmistuksen tavoitteet ovat seuraavat: 1. Kaikki laadunvarmistustehtävät suunnitellaan. 2. Todennetaan objektiivisesti, että ohjelmistotuotteet ja tehtävät noudattavat asianmukaisia standardeja, menettelyjä ja vaatimuksia. 3. Niitä ryhmiä ja henkilöitä, joihin laadunvarmistus vaikuttaa, informoidaan laadunvarmistustehtävistä ja niiden tuloksista. 4. Standardien, menettelyjen ja vaatimusten noudattamista koskevat ongelmat, joita ei voida ratkaista projektin sisällä, annetaan ylimmän johdon käsiteltäviksi. Ohjelmiston laadunvarmistuksen korkean tason tehtävät ovat seuraavat: 1. Ohjelmistoprojektille laaditaan laadunvarmistussuunnitelma dokumentoitua menettelyä noudattaen. 2. Laadunvarmistusryhmä noudattaa toiminnassaan laadunvarmistussuunnitelmaa. 3. Laadunvarmistusryhmä osallistuu projektin ohjelmistonkehityssuunnitelman, -standardien ja -menettelyjen valmisteluun ja katselmuksiin. 4. Laadunvarmistusryhmä katselmoi ohjelmistotuotannon toiminnan todentaakseen, että se noudattaa suunnitelmia, standardeja ja menettelyjä. 5. Laadunvarmistusryhmä auditoi nimetyt sovelluskehitysprojektin työtuotteet todentaakseen, että ne noudattavat suunnitelmia, standardeja ja menettelyjä.

3 15. Muita projektinhallinnan menetelmiä Laadunvarmistusryhmä raportoi määräajoin toimintansa tuloksista ohjelmistotuotantoryhmälle. 7. Ohjelmistotuotannon toiminnassa ja työtuotteissa havaitut poikkeamat dokumentoidaan ja käsitellään dokumentoidun menettelyn mukaisesti. 8. Tarvittaessa laadunvarmistusryhmä katselmoi ajoittain omia toimiaan ja havaintojaan asiakkaan laadunvarmistushenkilöstön kanssa. Kokoonpanonhallinta Kokoonpanonhallinnan (CM, configuration management) tarkoitus on vakiinnuttaa ja ylläpitää ohjelmistoprojektin tuotteiden yhtenäisyys koko ohjelmiston elinkaaren ajan. Kokoonpanonhallintaan kuuluu ohjelmiston kokoonpanon (eli valittujen ohjelmistotyötuotteiden ja niiden kuvausten) tunnistaminen tiettyinä ajankohtina siten, että kokoonpanon muutoksia kontrolloidaan systemaattisesti ja kokoonpanon yhtenäisyyttä ja jäljitettävyyttä ylläpidetään koko ohjelmiston elinkaaren ajan. Jäljitettävyyttä seurataan usein matriisin avulla. Kokoonpanonhallintaan alistettuihin työtuotteisiin sisältyvät asiakkaalle toimitettavat ohjelmistotuotteet (esim. ohjelmiston vaatimusdokumentti ja lähdekoodi) ja sellaiset tuotteet, jotka ovat samankaltaisia näiden ohjelmistotuotteiden kanssa tai joita tarvitaan niiden valmistamisessa (esim. kääntäjä). Ohjelmistotuotteille luodaan pohjamäärittelyt. Pohjamäärittelyjen muutoksia ja ohjelmiston pohjamäärittelykirjaston perusteella rakennettujen ohjelmistotuotteiden julkistamista valvotaan systemaattisesti kokoonpanonhallintaohjelman muutostenhallinta- ja kokoonpanon auditointi -toimintojen kautta. Kokoonpanonhallinnan prosessi kattaa kokoonpanonhallinnassa tarvittavat käytännöt. Määrättyjen kokoonpanon osien/yksiköiden tunnistamisessa sovellettavat käytännöt sisältyvät niihin avainprosessialueisiin, jotka kuvailevat kunkin osan/yksikön kehittämistä ja ylläpitoa. On tärkeää, että kokonaisuus pysyy hallinnassa - siksi prosessia kutsutaan kokoonpanonhallinnaksi. Kokoonpanonhallinnan tavoitteet ovat seuraavat: 1. Kokoonpanonhallinnan toimet suunnitellaan ja dokumentoidaan. 2. Valitut työtuotteet nimetään, niitä valvotaan ja ne ovat saatavilla.

4 Muita projektinhallinnan menetelmiä 3. Nimettyihin ohjelmistotyötuotteisiin tehtyjä muutoksia valvotaan. 4. Ryhmät ja henkilöt, joiden toimintaan kokoonpanonhallinta vaikuttaa, pidetään ajan tasalla ohjelmiston pohjamäärittelyjen tilan ja sisällön suhteen. Vaatimustenhallinta Vaatimustenhallinta on menetelmä yhteisymmäryksen saavuttamiseksi asiakkaan, loppukäyttäjän tai johdon ja ohjelmistoprojektin kesken niistä vaatimuksista, joihin ohjelmistoprojektin tuotteilla vastataan. Vaatimustenhallinnassa sovitaan ohjelmistoprojektin vaatimuksista asiakkaan kanssa ja ylläpidetään tätä sopimusta. Sopimusta kutsutaan ohjelmistolle asetetuiksi järjestelmävaatimuksiksi. Asiakas voi olla järjestelmätuotantoryhmä, markkinointiryhmä, jokin muu sisäinen organisaatio tai ulkoinen asiakas. Sopimus sisältää sekä tekniset että ei-tekniset asiat (esim. resurssit, välietapit ja vaatimukset). Sopimus luo perustan ohjelmistoprojektin toiminnan kustannusarvioinnille, suunnittelulle, toteuttamiselle ja seuraamiselle koko ohjelmistonkehityksen elinkaaren ajan. Ohjelmiston, laitteiston ja muiden resurssien järjestelmävaatimukset voi asettaa myös jokin projektitiimiin ulkopuolinen ryhmä (esim. järjestelmätuotantoryhmä), eikä projektitiimi välttämättä pysty suoraan vaikuttamaan vaatimuksiin. Projektitiimi ryhtyy tarvittaviin toimenpiteisiin projektin rajoitusten sallimissa rajoissa varmistaakseen, että ohjelmistolle asetetut järjestelmävaatimukset, joiden toteuttamisesta tiimi on vastuussa, dokumentoidaan ja niitä valvotaan. Projektitiimi valvoo vaatimuksia tarkastamalla ohjelmiston alkuperäiset ja korjatut järjestelmävaatimukset ja ratkaisee sitten löytämänsä ongelmat, ennen kuin vaatimukset yhdistetään ohjelmistoprojektiin. Aina kun ohjelmistolle asetettuja järjestelmävaatimuksia muutetaan, ohjelmistosuunnitelmia, työtuotteita ja toimenpiteitä muokataan päivitettyjä vaatimuksia vastaaviksi. Vaatimustenhallinnan tavoitteet ovat seuraavat: 1. Projektikohtaisia ohjelmistolle asetettuja vaatimuksia valvotaan, jotta voidaan luoda pohjamäärittely ohjelmiston tuotantoa ja hallintaa varten.

5 15. Muita projektinhallinnan menetelmiä Kaikki ohjelmistoon liittyvät suunnitelmat, tuotteet ja toimenpiteet pidetään ohjelmistolle asetettujen järjestelmävaatimusten mukaisina. Vaatimustenhallinnan korkean tason tehtävät ovat seuraavat: 1. Projektitiimi tarkastaa asetetut vaatimukset, ennen kuin ne yhdistetään ohjelmistoprojektiin. 2. Projektitiimi käyttää asetettuja vaatimuksia ohjelmistosuunnitelmien, työtuotteiden ja tehtävien pohjana. 3. Asetettuihin vaatimuksiin tehdyt muutokset tarkastetaan ja yhdistetään ohjelmistoprojektiin. 4. Hyvin suurissa projekteissa saatetaan tarvita vaatimustenhallintapäällikkö ja -tiimi. SWOT-analyysi SWOT-analyysi on tehokas tapa tunnistaa omat vahvuudet ja heikkoudet sekä tarkastella edessä olevia mahdollisuuksia ja uhkia. Usein pelkkä SWOT-analyysi riittää paljastamaan hyödyllisiä muutoksia, joita voidaan tehdä. Jossain mielessä SWOT-analyysia voidaan myös pitää eräänlaisena riskienhallintana. Kaikkien projektitiimin jäsenten pitäisi osallistua analyysin tekemiseen, ja jokaiselle tulisi antaa mahdollisuus ilmaista mielipiteitään. SWOT-analyysissa projektitiimien täytyy vastata seuraaviin kysymyksiin: 1. Vahvuudet Mitkä ovat vahvat puolemme? Missä me olemme hyviä? Näitä kysymyksiä pohditaan omalta kannalta sekä niiden ihmisten kannalta, joiden kanssa ollaan tekemisissä. Ole realisti, mutta älä ole vaatimaton. Jos tehtävä tuntuu vaikealta, kannattaa kokeilla omien ominaisuuksien listaamista paperille.

6 Muita projektinhallinnan menetelmiä Toivottavasti jotkut ominaisuudet ovat myös vahvuuksia! 2. Heikkoudet Missä on parantamisen varaa? Mitä tehdään huonosti? Mitä pitäisi välttää? Näitäkin kysymyksiä mietitään sekä omalta että muiden kannalta. Näkevätkö muut ihmiset heikkouksia, joita en itse huomaa? Pärjäävätkö kilpailijat yhtään paremmin? On parempi olla realisti tässä vaiheessa ja kohdata epämiellyttävät totuudet mahdollisimman pian. Ole heikkouksien suhteen suora ja avoin. 3. Mahdollisuudet Mistä hyvät tehtävät löytyvät? Mitkä ovat mielenkiintoiset trendit? Esimerkiksi seuraavat tapahtumat voivat avata hyödyllisiä mahdollisuuksia: sekä pienet että suuret tekniikan ja markkinoiden muutokset muutokset viranomaisten suhtautumisessa omaan alaan sosiaalisten mallien, väestöprofiilien, elämäntyylien ym. muutokset paikalliset, kansalliset, kansainväliset tapahtumat. 4. Uhat Minkälaisia esteitä meillä on edessämme? Mitä kilpailijamme tekevät? Muuttuvatko työlle, tuotteille tai palveluille asetetut vaatimukset? Uhkaako tekniikan muutos asemaamme? Onko meillä johdon tuki? Onko meillä oikea määrä resursseja? Onko tuotteen laajuus karkaamassa käsistä? Käytämmekö oikeita työkaluja, ohjelmia ja alustoja?

7 15. Muita projektinhallinnan menetelmiä 193 Projektitiimien ja -päälliköiden on suoritettava SWOT-analyysi määrätyin väliajoin. Tulokset ovat usein valaisevia, koska ne sekä osoittavat, millaisia toimenpiteitä tarvitaan että asettavat ongelmat oikeisiin mittasuhteisiinsa. Julkistuksenhallinta Julkistuspäällikkö on sovelluksen tai järjestelmän julkistuksen valvoja, joka seuraa kehitys- ja testausprosessia, arvioi jatkuvasti projektin edistymistä ja tiedottaa ylemmälle johdolle riskeistä ja ongelmista. Julkistus voi myös sisältää muutospyyntöjen perusteella tuotantotuen ympäristöön tai arkkitehtuuriin tehtyjä muutoksia. Julkistus voi koostua monista eri kokoisista projekteista, joiden kompleksisuus ja arvot vaihtelevat. Julkistuspäällikkö kokoaa aiempien muutostenhallintaprosessien sekä tuotteen laajuuden määritys-, kustannusarvio- ja hyväksymisprosessien tiedot ja priorisoi niiden perusteella julkistukseen sisällytettävät muutokset. Valitaan projektipäälliköt ja -tiimit, jotka johtavat ja kehittävät yksittäisiä projekteja. Julkistuspäällikkö valvoo kaikkea dokumentaatiota julkistuksen ja projektien asettamiskirjeistä julkistuksen loppuraporttiin. Kun julkistus on asennettu, kehityksen ydintiimin rooli vaihtuu tuotannon tueksi. Julkistuksenhallinnan tavoitteet ovat seuraavat: 1. Ohjelmiston julkistus hallitaan ja toteutetaan onnistuneesti. 2. Julkistukseen liittyvät riskit hallitaan ja niitä lievennetään. 3. Ohjelmistoprojektit julkistetaan järjestelmällisesti. Julkistuksenhallinnan korkean tason tehtävät ovat seuraavat: 1. Neuvotellaan ja sovitaan julkistuksen sisällöstä loppukäyttäjien ja johtoportaan kanssa sekä julkaistaan julkistuksen asettamiskirje. 2. Valitaan työntekijät projektitiimeihin julkistuksen toteuttamiseksi. 3. Arvioidaan julkistusten edistyminen, testitulokset ja laatu sekä kootaan mittareiden tulokset. 4. Hallitaan julkistuksen käyttöönotto ja siirtäminen tuotantoon. 5. Arvioidaan julkistus käyttöönoton jälkeen ja dokumentoidaan projektissa opitut asiat.

8 Muita projektinhallinnan menetelmiä Ohjelmistoalihankinnan hallinta Ohjelmistoalihankinnan hallinnan tarkoitus on valita päteviä alihankkijoita ja hallita niitä tehokkaasti. Ohjelmistoalihankinnan hallinta käsittää ohjelmistoalihankkijan valinnan, molemminpuolisista velvoitteista sopimisen sekä alihankkijan toiminnan ja sen tulosten seuraamisen ja tarkastamisen. Nämä käytännöt kattavat pelkän ohjelmistoalihankintasopimuksen hallinnan sekä ohjelmia, laitteita ja mahdollisesti muitakin järjestelmäkomponentteja sisältävän alihankintasopimuksen ohjelmistokomponentin hallinnan. Alihankkija valitaan sen kyvykkyyden perusteella. Päähankkijalla on monia syitä tehdä alihankintasopimus: alihankkija saatetaan valita esimerkiksi strategisten liittoutumien tai teknisten tekijöiden perusteella. Tärkeän alihankintaprosessin käytännöt seuraavat perinteistä hankintaprosessia, johon liittyy työn määrätyn osan antaminen jonkin toisen organisaation tehtäväksi. Kun jokin projektin osa annetaan alihankkijan tehtäväksi, laaditaan tekniset ja muut vaatimukset (esim. toimitusajat) sisältävä kirjallinen alihankintasopimus, joka toimii alihankinnan hallinnan pohjana. Lisäksi dokumentoidaan alihankkijan tehtäväksi annettu työ ja sen suorittamista varten laaditut suunnitelmat. Myös pää- ja alihankkijan standardien täytyy olla yhdenmukaisia. Alihankkija seuraa ja valvoo työn suorittamista. Päähankkija puolestaan varmistaa, että suunnittelu-, seuranta- ja valvontatehtävät hoidetaan kunnolla ja että alihankkijan valmistamat ohjelmistotuotteet täyttävät aiemmin määritellyt ja sovitut hyväksymiskriteerit. Pää- ja alihankkija huolehtivat yhdessä tuote- ja prosessirajapintojen toimivuudesta. Alihankinnan hallinnan tavoitteet ovat seuraavat: 1. Päähankkija valitsee yhden tai useamman pätevän alihankkijan ja valvoo niiden toimintaa. 2. Pää- ja alihankkija hyväksyvät velvoitteensa tekemällä alihankintasopimuksen. 3. Pää- ja alihankkija viestivät jatkuvasti keskenään ja pitävät säännöllisiä työn edistymisen seurantakokouksia. 4. Päähankkija seuraa alihankkijan työtä vertaamalla todellisia tuloksia ja suorituskykyä sitoumuksiin ja sopimusvelvoitteisiin.

9 15. Muita projektinhallinnan menetelmiä 195 Alihankinnan hallinnan korkean tason tehtävät ovat seuraavat: 1. Alihankkija valitaan alihankintatarjouksen tehneen yrityksen kyvykkyydestä tehdyn arvioinnin perusteella. Arviointi suoritetaan dokumentoidun ja ennalta sovitun menettelyn mukaisesti sekä suositusten ja muiden ammatillisten tarkistusten perusteella. 2. Alihankkijan tehtäväksi annettava työ määritellään ja suunnitellaan dokumentoidun ja ennalta sovitun menettelyn, työkuvauksen ja projektisuunnitelman mukaisesti. 3. Pää- ja alihankkijan välistä sopimusta käytetään alihankinnan hallinnan pohjana. 4. Päähankkija tarkastaa ja hyväksyy säännöllisesti alihankkijan tekemän dokumentoidun projektisuunnitelman. 5. Alihankkijan dokumentoitua ja hyväksyttyä projektisuunnitelmaa käytetään ohjelmistotehtävien seuraamisessa ja projektin edistymisen raportoinnissa. 6. Alihankkijan työkuvaukseen, alihankintasopimuksen ehtoihin ja muihin velvoitteisiin tehtävät muutokset käsitellään ennalta sovitun ja dokumentoidun menettelyn mukaisesti tai tarvittaessa välimiesmenettelyn kautta. 7. Päähankkijan johto suorittaa yhdessä alihankkijan johdon kanssa määräajoin projektin edistymis- ja koordinointikatselmuksia ja auditointeja. 8. Ohjelmistoalihankkijan kanssa pidetään säännöllisiä teknisiä katselmuksia ja palavereja. 9. Alihankkijan aikaansaamia tuotteita ja tuloksia katselmoidaan valituissa välietapeissa dokumentoidun ja ennalta sovitun menettelyn mukaisesti. 10. Päähankkijan laadunvarmistusryhmä seuraa alihankkijan laadunvarmistustoimia dokumentoidun ja ennalta sovitun menettelyn mukaisesti. 11. Päähankkijan kokoonpanonhallintaryhmä seuraa alihankkijan kokoonpanonhallinnan toimia dokumentoidun ja ennalta sovitun menettelyn mukaisesti.

10 Muita projektinhallinnan menetelmiä 12. Päähankkija suorittaa hyväksymistestauksen osana alihankkijan valmistamien ohjelmistotuotteiden toimitusta dokumentoidun ja ennalta sovitun menettelyn mukaisesti. 13. Ohjelmistoalihankkijan suorituksia arvioidaan määräajoin, ja arvioinnin tulokset käydään läpi alihankkijan kanssa. Laatukatselmukset Laatukatselmusten tarkoitus on poistaa virheet ohjelmistotyötuotteista ajoissa ja tehokkaasti. Katselmukset ovat tärkeitä, koska ne auttavat ymmärtämään paremmin työtuotteita ja löytämään niistä virheitä, jotka voitaisiin estää. Näin vältetään ongelmat projektin elinkaaren myöhemmissä vaiheissa. Laatukatselmuksissa työtuotteiden valmistajien kollegat etsivät työtuotteista järjestelmällisesti vikoja ja muutoksia edellyttäviä alueita. Tuotteet, jotka alistetaan laatukatselmukseen, nimetään projektin ohjelmistoprosessissa, ja katselmuksille laaditaan aikataulu osana projektisuunnittelua. Laatukatselmusprosessi käsittää laatukatselmusten suorittamiskäytännöt. Laatukatselmukseen alistettavien työtuotteiden valitsemiskäytännöt sisältyvät niihin avainprosessialueisiin, jotka kuvailevat kunkin ohjelmistotyötuotteen kehittämistä ja ylläpitoa. Kaikissa projekteissa tulisi pitää laatukatselmuksia virheiden vähentämiseksi ja prosessien parantamiseksi. Laatukatselmusten tavoitteet ovat seuraavat: 1. Katselmukset suunnitellaan ja ajoitetaan suoritettaviksi sopivin väliajoin projektin elinkaaren aikana. 2. Virheet tunnistetaan ja poistetaan. 3. Prosessia parannetaan jatkuvasti. Laatukatselmusten korkean tason tehtävät ovat seuraavat: 1. Katselmukset suunnitellaan ja ajoitetaan, ja suunnitelmat dokumentoidaan. 2. Asiantunteva henkilökunta pitää katselmukset dokumentoidun menettelyn mukaisesti.

11 15. Muita projektinhallinnan menetelmiä Katselmusten suorittamisesta ja tuloksista kirjoitetaan raportti. 4. Mittaustulokset tallennetaan ja niitä käytetään jatkossa suunnittelun perustana. Kriisinhallinta Kriisinhallintatiimi koostuu pääasiassa ylimmästä johdosta. Tiimi johtaa strategista reaktiota kriisiin, antaa varoja käyttöön lyhyellä varoitusajalla ja varmistaa, että yrityksen arvoja ja etiikkaa sovelletaan. Se kontrolloi viestintää sidosryhmille, tiedotusvälineille, työntekijöille ja muille tahoille, joihin tilanne vaikuttaa. Tiimiä johtaa yrityksen pääjohtaja tai joku muu riittävän vaikutusvaltainen ja arvostettu ylimpään johtoon kuuluva henkilö. Kriisinhallinta on äärimmäinen reaktio projektia tai liiketoimintaa uhkaavaan riskiin, ja kriisinhallinnan käytännöt ja menettelyt pitäisi kehittää ja dokumentoida osana projektin varasuunnitelmaa. Tiimin on toimittava nopeasti, kun olosuhteet sen sallivat, koska se on päävastuussa kriisin selvittämisestä. Tiimin jäsenillä on teknistä ja liikkeenjohdollista kokemusta, jonka turvin he hoitavat kriisin seuraukset. Kriisinhallinnan toinen tärkeä alue on tiedottaminen. Tiedottaminen on elintärkeää kriisitilanteessa. Kriisinhallintatiimi keskittyy viestimään tiedotusvälineiden, poliisin, armeijan, yleisön, työntekijöiden ja osakkaiden kanssa ja välittää uutisia - sekä hyviä että huonoja - ja tietoa siitä, mitä tilanteen korjaamiseksi parhaillaan tehdään. Kriisinhallinnan tavoitteet ovat seuraavat: 1. Vastataan nopeasti organisaatiota uhkaavaan kriisiin. 2. Kootaan tiimi, joka reagoi ja toimii kriisitilanteessa sekä eliminoi kriisin tai rajoittaa sen vaikutuksia. 3. Tiedotetaan kriisistä kaikille osapuolille, joihin kriisi vaikuttaa. Kriisienhallinnan korkean tason tehtävät ovat seuraavat: 1. Laaditaan kriisinhallintasuunnitelma. (Esimerkkisuunnitelma löytyy liitteestä D.) 2. Perehdytään kriisejä laukaiseviin tekijöihin ja reagoidaan niihin kriisitilanteessa.

12 Muita projektinhallinnan menetelmiä 3. Toimitaan suunnitelman mukaan. 4. Tiedotetaan kriisistä tiedotusvälineille, osakkaille, suurelle yleisölle ja muille osapuolille, joihin kriisi vaikuttaa. Projektipäälliköt voivat olla erittäin tehokkaita kriisinhallintatiimin jäseniä, koska heillä on koulutusta ja kokemusta käsitellä monenlaisia haasteita. Hyvät projektipäälliköt pystyvät tekemään päätöksiä ja toimimaan nopeasti kriisin vaikutusten rajoittamiseksi. It-toimintoihin vaikuttavien kriisien, kuten tulipalojen, tulvien, pyörremyrskyjen ja maanjäristysten, varalta on liiketoiminnan jatkuvuussuunnitelmien oltava nopeasti saatavilla toimeenpanoa varten. Muita, yritystoimintaan liittyviä kriisejä kuten väärää tietoa, tuotteen markkinoilta poistamista tai muunlaisia tietokriisejä varten saatetaan tarvita erityissuunnittelua. Kirjallisuutta Seuraavista aihepiireistä on saatavilla lisämateriaalia: Ohjelmiston laadunvarmistus Ginac, Frank P. Customer-Oriented Software Quality Assurance. Prentice Hall, Perry, William E. Quality Assurance for Information Systems: Methods, Tools, and Techniques. John Wiley & Sons, Schulmeyer, G. Gordon. The Handbook of Software Quality Assurance. Prentice Hall, Kokoonpanonhallinta Berlack, H. Ronald. Software Configuration Management. John Wiley & Sons, Leon, Alexis. A Guide to Software Configuration Management. Artech House, Lyons, David Douglas. Practical CM: Best Configuration Management Practices for the 21st Century. Raven Press, 1999.

13 15. Muita projektinhallinnan menetelmiä 199 Vaatimustenhallinta Mumford, Enid. Effective Systems Design and Requirements Analysis: The Ethics Method. MacMillan Publishing USA, Wiley, Bill. Essential System Requirements: A Practical Guide to Event- Driven Methods (Addison-Wesley Information Technology Series). Addison- Wesley Publishing Co., SWOT-analyysi Johnson, Nick and Cooper, Simon. SWOT A Level Law. William Gaunt & Sons, Alihankinnan hallinta Wangemann, Mary Ann P Subcontract Management Manual. Harcourt Brace & Company, Laatukatselmukset Kan, Stephen H. Metrics and Models in Software Quality Engineering. Addison-Wesley Publishing Co., Kriisinhallinta Henry, Rene A. You d Better Have a Hose if You Want to Put Out the Fire: The Complete Guide to Crisis and Risk Communications. MIT Press, Lerbinger, Otto. The Crisis Manager: Facing Risk and Responsibility. Lawrence Erlbaum, Regester, Michael and Larkin, Judy. Risk Issues and Crisis Management: A Casebook of Best Practice. Kogan Page, 1998.

14 Muita projektinhallinnan menetelmiä