2.0 Projektin käyttöönoton vaiheet (osa 1)

Vihkiminen #

Hankkeen alkua kutsutaan alkuvaiheeksi. Tässä vaiheessa hankkeen ideaa tutkitaan ja kehitetään. Tämän vaiheen tavoitteena on nähdä, voidaanko projekti todella saada päätökseen. Valitaan, kuka johtaa työtä, mikä organisaatio osallistuu ja saako yritys tarpeeksi tukea asianosaisilta.

Tämä vaihe edellyttää nykyistä tai tulevaa projektipäällikköä valmistelemaan ehdotuksen, jossa esitetään edellä mainitut kohdat. Liiketoimintasuunnitelmat ja apurahahakemukset ovat esimerkkejä tällaisesta hanke -ehdotuksesta. Hankkeen mahdolliset sponsorit arvioivat hakemuksen ja myöntävät tarvittavan rahoituksen, jos se hyväksytään. Hanke alkaa muodollisesti hyväksynnän jälkeen. Alkuvaiheessa on vastattava seuraaviin kysymyksiin:

  • Miksi tämä projekti?
  • Onko se fyysisesti mahdollista?
  • Mitkä ovat toivotut tulokset?
  • Mitkä ovat hankkeen rajat (mikä sisältyy hankkeen laajuuteen)?

Kyky sanoa ”ei” on projektijohtajan kriittinen ominaisuus. Kun ihmiset innostuvat hankkeesta, sen laajuus kasvaa. ”Kun olemme sitä, voimme myös …” on taustalla oleva ajatus. Hankkeet, joihin lisätään lisätavoitteita, ja hankkeet, jotka kasvavat edelleen, ovat lähes taatusti myöhässä, eivätkä todennäköisesti saavuta alkuperäisiä tavoitteitaan.

Ensimmäinen askel on luoda yhteys kaikkien hankkeen sidosryhmien välille. Epärealistiset odotukset hankkeen tuloksesta voidaan välttää, jos laajuus ymmärretään hyvin. Aloita luomalla yhteys eri henkilöiden välille. On välttämätöntä ymmärtää lujasti sen soveltamisala.

Tietylle hankkeelle valitulla menetelmällä on merkittävä vaikutus sen tulokseen. Esimerkiksi tutkimus- ja kehitystyö voi antaa raportin sovelluksen teknisestä elinkelpoisuudesta. Projekti, joka johtaa prototyypin kehittämiseen, sisältää kaikki sovelluksen toiminnot. Niiden ei kuitenkaan tarvitse olla sopivia käytettäväksi tietyssä ympäristössä (esim. Sadat käyttäjät). Toimivan tuotteen tuottavan projektin on käsiteltävä myös ylläpitoon, dokumentointiin ja sovellusten hallintaan liittyviä kysymyksiä.

Lukuisia väärinkäsityksiä ja kiistoja esiintyy osallistuvien ihmisten vuoksi projektinhallinta on epäselvä näissä kohdissa. Asiakkaat voivat ennakoida toimivan tuotteen, kun taas projektitiimin jäsenet uskovat luovansa prototyypin. Vaikka sponsori voi ajatella, että projekti johtaisi hyödylliseen ohjelmistoon, ryhmän jäsenten on ensin määritettävä, onko konsepti teknisesti kannattava.

Määritelmä #

Hyväksytyn aloitussuunnitelman jälkeen hanke aloitti toisen vaiheen: määrittelyvaiheen. Tässä vaiheessa määritellään mahdollisimman tarkasti hankkeen tulokseen liittyvät vaatimukset. Tässä vaiheessa määritellään kaikkien hankkeen kehittämiseen osallistuvien osapuolten odotukset. Kuinka monta tiedostoa tarvitaan arkistointiin? Pitäisikö metatietojen olla Data Documentation Initiative (DDO) -muodossa vai riittääkö Dublin Core (DC)? Ovatko tiedostot sallittuja alkuperäisessä muodossaan vai vain ne, jotka noudattavat ”suositeltuja standardeja”? Onko tallettajan velvollisuus taata, että tietojoukko käsitellään asianmukaisesti arkistossa, vai onko tämä arkistonhoitajan vastuulla? Mitä takeita hankkeen tuloksista annetaan? Kyselyluettelo saattaa jatkua loputtomiin.

On tärkeää selvittää tarpeet mahdollisimman varhaisessa vaiheessa.

Wijnen (2004) määrittelee muistityypiksi seuraavan tyyppiset projektitarpeet:

  • Edellytykset
  • Toiminnallisuutta koskevat vaatimukset
  • Toiminnallisuutta koskevat vaatimukset
  • Suunnittelun rajoitukset

Edellytykset luovat puitteet, joissa projekti on toteutettava.

Lainsäädäntö, työoloja koskevat säännöt ja hyväksymismenettelyt ovat kaikki esimerkkejä. Nämä kriteerit ovat muuttumattomia projektin sisällä.

On tärkeää muistaa, että vaatimukset ovat spesifikaatioita, jotka liittyvät lopputuloksen laatuun – teknisiä eritelmiä, jotka liittyvät siihen, miten hankkeen tuloksia käytetään. Esimerkiksi virheiden määrää on vähennettävä 90% ohjelmistoprojektin päätyttyä. Suunnittelurajoitukset ovat toisaalta hankekohtaisia vaatimuksia. Vaarallisia kemikaaleja ja ulkomaisia kumppaneita, joilla on kyseenalaisia työstandardeja, ei voida sisällyttää hankkeeseen esimerkkinä.

Hankkeen määrittelyvaiheessa, joka sisälsi verkkosovelluksen rakentamisen suurten organisaatioiden yhteenliittymälle, ei tehty päätöksiä ohjelman tukemasta selaimesta. Konsortio ajatteli, että se olisi Microsoft Explorer, koska se oli kaikkien selain.

Kehittäjät rakensivat sovelluksen Firefoxiin, koska he tunsivat jo selaimen ja heillä oli useita erityisen hyödyllisiä ominaisuuksia koko kehityksen ajan. Koska useimmat Firefoxille suunnitellut sivustot näyttävät myös upeilta Explorerissa, muutos oli ensin huomaamaton. Hankkeen päätyttyä asiakas kuitenkin alkoi protestoida, että verkkosivusto ”ei näyttänyt hyvältä”. Ohjelmoijat, jotka pääsivät sivustoon Firefoxin kautta, olivat hämmentyneitä valituksesta.

Kun kävi ilmi, että nämä kaksi selainta eivät olleet yhteensopivia, ohjelmoijat vastasivat puolustavasti: ’Eivätkö he voi asentaa Firefoxia? Loppujen lopuksi se on ilmaista. ” Toisaalta organisaatiot velvoittivat hallituksen järjestelmänvalvojat, jotka jostain syystä kieltäytyivät asentamasta Firefoxia Explorerin rinnalle.

Vaikka he olisivat halunneet asentaa sen, menettely olisi ollut pitkä, ja järjestelmänvalvojien työhön käyttämästä ajasta olisi aiheutunut lisäkustannuksia. Lopuksi päätti, että sovelluksen on mukauduttava Exploreriin. Tämä vaati huomattavasti enemmän ponnisteluja, mikä johti siihen, että hanke oli myöhässä aikataulustaan jo aiemmin, mikä johti neuvottelemaan lisäkustannuksista. Myöhemmin tehty tutkimus paljasti, että eri organisaatiot käyttivät Microsoft Explorerin eri versioita.

On ratkaisevan tärkeää, että kaikki hankkeeseen osallistuvat sidosryhmät, erityisesti loppukäyttäjät, jotka hyödyntävät hankkeen tuloksia, osallistuvat koko määrittelyvaiheen ajan. Koska loppukäyttäjät eivät usein ole hankkeen tilaajat, he jätetään usein huomiotta. Määrittelyvaiheessa hanketta maksavaa asiakasta pyydetään osallistumaan vaatimuksiin. Aloite kuitenkin voittaa kutsumalla tulevia käyttäjiä. Lähtökohtana on hyödyllistä järjestää kokouksia kaikkien sidosryhmien kanssa koko hankkeen määrittelyvaiheen ajan.

Myöhemmin käyttäjät (nuoret) osallistuivat opettavaisen videopelin kehittämiseen. Kun peli oli melkein valmis, se päätti testata sitä ryhmän nuorten kanssa. Heidän ensimmäiset arviointinsa näyttivät kohtuullisilta ja sovinnollisilta. Työnnettäessä he kuitenkin myönsivät, että olivat kokeneet pelin ”erittäin tylsäksi” eivätkä ”pelaa sitä itse. Jos nämä nuoret tekisivät projektin alkuvaiheessa, peli olisi epäilemättä ollut menestys. Tällä hetkellä peli on lähes sijoittamaton Internet -sivustolle.

Määrittelyvaihe tuottaa luettelon tarpeista kaikilta hankkeessa mukana olevilta sidosryhmiltä. Jokaisella ehdolla on tietysti käänteinen tilanne.

Mitä monimutkaisempi työ, sitä enemmän aikaa ja rahaa tarvitaan. Lisäksi jotkut kriteerit voivat olla ristiriidassa keskenään. Uudet kopiokoneet, jotka on suunniteltu ympäristöystävällisemmiksi; niiden on myös täytettävä paloturvallisuusstandardit. Paloturvallisuutta koskevat määräykset velvoittavat käyttämään palonestoaineita, jotka ovat vähemmän ympäristöystävällisiä. Kuten tässä kuvassa näkyy, siihen on puututtava.

Lopuksi luodaan luettelo tietyistä kriteereistä ja toimitetaan hankkeen päättäjille hyväksyttäväksi. Luettelon hyväksymisen jälkeen suunnitteluprosessi voi alkaa – suurin osa asiakkaan ja projektitiimin välisistä sopimuksista on saavutettu määrittelyvaiheen loppuun mennessä.

Vaatimusluettelo määrittää parametrit, joiden sisällä hankkeen on toimittava.

Tätä luetteloa käytetään arvioimaan projektiryhmää. Tämän seurauksena asiakas ei voi lisätä lisävaatimuksia määrittelyvaiheen jälkeen.

Osana projektia luotu tietokoneasennus sisältää uuden näyttelyn museossa. Koska hankkeessa ei ollut määrittävää vaihetta, museon ja laitoksen rakentamisesta vastuussa olevien välillä ei päästy konkreettisiin neuvotteluihin. Kun asennuksen tietokone epäonnistui puolessa välissä, museo uskoi, että hankkeen takuu kattaa sen. Projektiryhmä oli päinvastaisessa asemassa – edellytti neuvotteluja johtajien välillä päästäkseen sopimukseen.

Design #

Määrittelyvaiheen vaatimuksia voidaan käyttää suunnittelupäätösten ohjaamiseen. Suunnitteluvaiheessa luodaan yksi tai useampi malli, jotka näyttävät täyttävän hankkeen tavoitteen. Suunnitteluvaihe voi tuottaa dioramoja, piirustuksia, vuokaavioita, sivustopuita, HTML -näytön malleja, prototyyppejä, kuvamateriaaleja ja UML -kaavioita projektin aiheesta riippuen. Projektin vetäjät käyttävät näitä piirustuksia projektin lopullisen suunnittelun valitsemiseen. Sen jälkeen tulee kehitysvaihe. Kun malli on valittu, se ei voi muuttua projektin myöhemmissä vaiheissa kuten määrittelevässä lauseessa.

Ilmaus ”suunnitteluosasto” ei ollut tässä tapauksessa sopiva; pikemminkin se viittasi suunnittelijaryhmään, joka teki yhteistyötä. Lisäksi kaikki olivat aivan liian kiireisiä, mukaan lukien osaston päällikkö.

Yksi hanke vaati luomaan erilaisia malleja, jotka olivat kriittisiä hankkeen menestyksen kannalta. Suunnittelut, jotka on kehittänyt nuori suunnittelija projektitiimissä. Vaikka suunnittelutiimin päällikkö oli viime kädessä vastuussa suunnitelmista, hän ei koskaan ollut läsnä projektiryhmän kokouksissa, joissa tarkasteltiin suunnitelmia. Projisoiva pomo kutsui häntä jatkuvasti ja lähetti hänelle sähköpostit, joissa oli nuoren kollegansa piirustuksia, mutta sähköpostit jätettiin huomiotta. Projektipäällikkö ja nuori suunnittelija uskoivat väärin, että osastonjohtaja oli hyväksynyt mallit. Toteutusvaihe alkoi. Kun projekti oli melkein valmis, toimitti tulos osastonjohtajalle, joka raivostui ja määräsi, että koko asia voidaan tehdä uudelleen.