Tony Collins IT Projects -blogista on listannut parikymmentä totuutta IT-projekteihin liittyen ja ikävän todelta useat listan kohdista ovat parin vuoden aikana osoittautuneet olevan. Listassa on kyllä useita kohtia, jotka ovat hieman yliampuvia. Tässä muutama oma poiminta listalta.
- Projekti myöhästyvät aina alkuperäisestä suunnitelmasta
- Useat projektit ovat jo lähtökohdiltaan suunniteltu liian tiukalle aikataululle, mutta edellisistä projekteista harvoin opitaan ja aina yritetään puskea eteenpäin mahdottomilla aikatauluilla.
- Alkuvaiheessa pitäisi keskittyä löytämään oikeat kysymykset
- On parempi aloittaa sovelluskehitys selvittämällä, mitä oikeasti ollaan tekemässä ja mitä asiasta pitäisi kaikkiaan tietää. Heikoilla alkutiedoilla aloitetaan tekemään turhaa työtä ja myöhemmin asioiden muuttaminen on aina hankalampaa.
- Käyttäjä on henkilö, joka hylkää järjestelmän, koska se on mitä haluttiin
- Välillä projekteissa tuntuu, että ollaan kehittämässä järjestelmää, joka tekee kaiken mahdollisen, mutta ei kokonaisuutena ole kuitenkaan sellainen, jota asiakas halusi. Tietenkin asiakkaan toiveita ja vaatimuksia toiminnallisuuksien suhteen on kuunneltava, mutta kaiken mahdollisen toteuttamisessa ei välttämättä ole järkeä.
- Onnistuneen ja epäonnistuneen projektin ero on hyvässä tiedottamisessa
- Kommunikaatio ja tiedottaminen projektin eri osapuolien välillä on tärkeää ja sen merkitys korostuu, kun projekti alkaa menemään sivuraiteille ja aikataulut venyvät.
- Mikään ei ole mahdotonta henkilölle, joka ei joudu sitä tekemään
- Kaikki on mahdollista ja usein helppoa, ainakin sellaisen henkilön mielestä, joka asiaa ei joudu käytännössä toteuttamaan. Kaikkia ominaisuuksia ei vain voi, eikä kannata sovellukseen toteuttaa.
- Alkuperäiset suunnitelmat muuttuvat aina
- Projektin edetessä sovellukselta vaadittavat ominaisuudet tarkentuvat ja ne usein tarkoittavat alkuperäisten määrittelyiden ja suunnitelmien muuttamista. Mitä aikaisemmin muutostarpeet havaitaan, sitä helpompi on on sovellukseen viedä.
- Koskaan ei ole riittävästi aikaa, joten tee se kerralla oikein
- Kun asiat tehdään kerralla oikein, ei niihin tarvitse myöhemmin palata ja muuttaa toimintoa, joka mahdollisesti vaikuttaisi moneen muuhun sovelluksen osaan ja dominoefekti olisi taattu.
- Koskaan ei ole riittävästi aikaa tehdä se ensimmäisellä kerralla kunnolla oikein
- Jos asiat tehtäisiin kerralla kunnolla, ei niitä tarvitsisi myöhemmin ”korjata”, mutta koska projektin aikataulut ovat tiukkoja, tehdään asiat ”kunhan toimii” ja ”viimeistellään kun on aikaa”. Etenkin dokumentointi on usein tällainen asia.
- Ymmärsit mitä sanoin, et mitä tarkoitin
- Kommunikoinnin merkitystä projekteissa ei voi yliarvioida, sillä sitä on aina liian vähän.
- Jokainen haluaa vahvan projektipäällikön, kunnes saavat sellaisen
- Projektipäällikkö on projektin johtohahmo ja suuri osa projektin toimivuutta. Heikko projektipäällikkö ei vedä projektia eteenpäin riittävällä voimalla ja useat asiat jäävät ilmaan. En ole vielä vahvaa projektipäällikköä tavannut, joka sanoisi asiakkaallekin vahvasti takaisin, joten jään innolla odottamaan.
- Projektit eivät epäonnistu lopussa, ne epäonnistuvat määrittelyssä
- Projektin alkuvaiheet ovat projektin tärkeimmät vaiheet, ja jos projektin määrittelyä ei hoideta kunnolla, voi sovelluskehitystä verrata kerrostalon rakentamiseen suomaalle. Paalutetaan perusta, kun rakennus on jo kallistumassa.
- Vaikein tie on usein helpoin
- Tekemällä kaikki asiat aina helpolla ja totutulla tavalla, ei hyödynnetä kaikkia mahdollisuuksia. Joskus kannattaa käyttää aikaa vaikean asian tekemiseen, sillä se voi myöhemmin palkita.
- Realisti on henkilö, joka on kaukonäköisesti pettynyt tulevaisuudessa
- Etenkin projektien suhteen, kannattaa jo ennakkoon olla skeptinen projektin sujuvuudesta ja kaikkien osa-alueiden toimivuudesta. Projekti menee kuitenkin pitkin mäntyjä, ainakin joltain osin.
Vastaa