- Erota järjestelmän määrittely toteutuksesta.
Määrittely on itsessään iso kokonaisuus ja kun määrittelyssä tarpeeton järjestelmän kehittäjätiimi ei ole kustannuksilla aiheuttamassa paineita edetä, tulee määrittelystäkin laadukkaampi. Ja voihan olla, että jollakin on jo valmis järjestelmä joka pystyy toteuttamaan suurimman osan tarpeistasi. Et vain tiedä sitä ennen tarpeiden määrittelyä. Tämän lisäksi on helppoa pyytää tarjouksia kun toiminallisuustarve on tiedossa, eikä haittaa että samalla tulee määriteltyä järjestelmän testausvaatimukset. Varmista että määrittelylle on riittävästi aikaa!
- Palkkaa ikioma projektipäällikkö.
Palkkaa projektipäällikkö joka raportoi vain ja ainoastaaan sinulle. Järjestelmän toteuttajalla on varmasti oma projektipäällikkö, mutta hänen tavoitteensa ei ole sinun etujen valvominen, vaan hän saa palkkansa asetettujen järjestelmätoiminnallisuuksien saavuttamisesta. Asiahan on kunnossa jos kaikki asetetut tavoitteet ovat kaikki osattu määritellä juuri sinun tarpeitten mukaisesti. Projektipäällikkösi tehtävä on pitää huoli aikatauluista ja kustannuksista ja hänen onnistuminen mitataan vain sillä kuinka tyytyväinen sinä, asiakkaana, olet lopputulokseen.
- Jokainen muutos on hinnoiteltava
Kun varsinainen järestelmän kehitystyö on aloitettu, tulee jokainen muutos hinnoiteltava jotta voidaan päättää onko muutos oikeasti sen arvoinen. Joskus on parempi toteuttaa hyväksytty konsepti ja perustaa myöhemmin toinen projekti muutosten tekemiseen. Voihan olla että yritys tai organisaatio pärjää hienosti jo sovitulla kokonaisuudella. Mikäli järjestelmä aiheuttaa vain kuluja ilman mitattavia hyötyjä, se ei ole vaivan ja rahan arvoinen.
- Tee vähän ja ota heti käyttöön
Yksi perisynneistä on tehdä massivinen järjestelmämuutos jossa muutetaan kaikkia toimitoja samanaikaisesti. Järjestelmä ehtii vanhentua ennen käyttöönottoa ja kustannushyöty jää saamatta. Parempi on tehdä vähän fiksusti ja ottaa se saman tien käyttöön. Muutosvastarinta on pienempi kun edetään pienin uudistuksin.
Ison järjestelmän yhtäaikainen kehitystarve kielii huonosta arkkiterhtuurisuunnittelusta.
- Omista ratkaisut
Sopimuksessa varmista, että organisaatiosi omistaa ratkaisun ja tarvittavat lähdekoodit. Tällöin muutokset pystyy tekemään toinenkin yritys, jolloin et ole jumissa alkuperäisen tekijän kanssa. Samalla kaikki haluaa tehdä parhaansa koska kukaan ei halua mainetta huonon koodin tekijänä.
- Kehittäjän näkymä (UI) ei ole sama kuin käyttäjän näkymä (UI)
Liian usein kehittäjätiimi kuvittelee heidän näkymänsä tai näkemyksensä olevan sama kuin käyttäjän. Koska käyttäjän ei tarvitse olla tietoinen kuinka monimutkaisesti tai helposti asiat järjestelmässä toimii, tulee käyttäjän näkymän palvella puhtaasti hänen tarpeitaan. Luonnollisesti tietyt lainalaisuudet (esimerkiksi tiedon elinkaari) tulee ymmärtää ja tulee näyttää myös käyttäjän näkymässä.