Paraku, ei saa ka liiga suurest kasutatavusele mõtlemisest (ja ka kõikide meetodite õigest kasutamisest), ära hoida kehvemapoolse keskpärase kasutatavusega infosüsteemi loomist.
Kujutage ette tellija imestust, kui projekt justkui läheb edukalt ja siis esitatakse talle süsteem, mis logiseb loogika vigadest :S.
Paraku on mul õnnestunud olla paari sellise süsteemi loomise tunnistajaks 
.
Mis siis valesti läks? On vähemalt neli elementi IT projektides, mis suudavad halvemal juhul kogu kasutatavuse tööle suure ja rasvase kriipsu peale tõmmata.
Huvitavad uued mõtted.
See on oht projektides, kus kasutatavuse tööde tulemusena tarnitakse loodava süsteemi prototüüp ning hiljem enam kasutatavusega tegelevaid isikuid ei kaasata.
Kuna pilt, milline süsteem peaks saama, on nüüd ilusti silme ees, tekib meeskonnas hilisemaid huvitavaid nägemusi, kuidas saaks kasutatavust veelgi tõsta.
Kuna aga meeskonnas pole ühtegi inimest, kes varasemad läbi käidud rajad uues valguses läbi analüüsiks või vähemalt mustrite kohaselt kontrolliks uute ideede sobivust (nt. kasvõi järjepidevuse osas), on need uued ideed tavaliselt realiseeritud läbimõtlematult. Tihti juhtub tavapärasest loogikast olulisi kõrvalekaldeid ning muudatused loovad keerulise õpitavusega infosüsteemi.
Ühe nupu liigutamine või juurde lisamine tundub esmalt küll väike muudatus aga kogu süsteemi mastaabis on neid imepisikesi muudatusi lõpuks väga palju.
Lisaks kiputakse probleeme tühjast kohast juurde mõtlema. Kellelegi tundub, et loodav lahendus tundub ikkagi kasutajatele liiga keeruline. Muidugi parandame selle probleemi kohe ära 
. Tavaliselt projektis kaasas käies tuletame siinkohal meelde, et testisime seda kasutajate peal ja nad said sellega suurepäraselt hakkama 
.
Uued mõtted ja muudatused ei tohiks olla väga lihtsad otsused. Kui neid siiski on vaja teha, tuleks kaasata kasutajaliidese spetsialist olemasolevat uues valguses läbi analüüsima.
Hilisemad skoobimuudatused.
Kui kasutajaliidest välja töötame, teeme suure töö ära selles osas, et informatsioon ja funktsioonid looksid ühtse loogilise kasutusjada ning terviku. Kui sa vähendad skoopi võtad sa osa sellest jadast ära.
Skoobimuudatused on teinekord äärmiselt olulised ja selle käigus annab ka kasutajasõbralik kasutajaliides säilitada, kuid see vajab siiski tööprotsessipõhist kasutajaliidese elementide üle analüüsimist ning muutmist või täiendamist.
Sarnased probleemid tekivad ka hilisema skoobi suurendamisega. Mõlemal juhul tuleb teha vähemalt osa sellest kasutajaliidese loomise protsessist uuesti.
Vähene järelvalve.
Usaldus on imeilus asi ja ilma selleta kunagi ei saa. Ametialaselt aga on vaid edukad need, kes küll usaldavad aga ka kontrollivad.
Tõin siin enne välja, et konsensuse saavutanud ning targa meeskonna poolt tehtud muudatused tekitavad kasutatavuse probleeme. Proovi kasutajana rinda pista üksi tehtud viimase hetke muudatuste ja kohandustega ning sa näed kuidas terve talupojamõistus su peas ümber defineeritakse .
Pole tegelikult vahet, kas ajendiks on liialt keeruline tehniline realisatsioon, arhitektuuri sobimatus uuele presentatsioonikihile või hoopis kasutajaliidese sellisel kujul loomise põhjuste teadmatusest tingitud kergekäeline parandusprotsess – tulemus on pea alati ebaloogiline ning keeruline kasutajaliides.
Selliseid muudatusi saab pea alati ära hoida korraliku projekti tulemite järelvalvega.
Tellija ebakindlus nõuete esitamisel.
Kõik soovivad olla meeldivad koostööpartnerid ja paraku tihti just peale mitmekordset eelnevalt esitatud nõuetele mittevastavat töötulemi esitamist antakse justkui alla ja lõpetatakse nõuetele vastavuse nõudmine.
Sisuliselt võrdub see sellega, et tellid sellise mõnusa koorest vaniljejäätise retsepti loomise. Sulle luuakse täpselt sinu jaoks keemiliselt ja struktuurilt sobiv jäätise retsept. Maksad selle retsepti eest vägagi kopsaka summa aga noh see jäätis on seda hiljem ikka kuhjaga väärt . Järgmise sammuna tuleb jäätisemeister ja hakkab sulle sinu oma retsepti järgi jäätist tegema. Ei jõua juba ära oodata, eksju . Jäätis saab valmis ja sulle antakse üle mango mahlapulk, grrrrrrr!!! Katsu siis lõpuks selle peale head nägu teha!
Nõuded on nõuded (olgugi, et prototüübina), neid tuleb järgida. Mis mõte on muidu üldse seda eeltööd nõuete püstitamiseks teha?
Kurb on vaadata, kui oled suure töö ära teinud ja tulemuseks saab käkk, millele sa iialgi oma nime ei ole valmis alla panema .
Loodan, et teil läheb selle kirjatüki tulemusena palju paremini .
Ja uskuge, koorene vaniljejäätis on ikka palju parem kui mango mahlapulk ja nõudke seda oma jäätisemeistrilt 
.
Mõistlik kirjatükk. Olen omalt poolt märganud samu probleeme. Järelevalve antud valdkonnas on üsna primaarne. Oluline on ka jälgida, et tarkvara arendusmeeskonna võtmetegelased nagu näiteks projektijuht, peaarhitekt ja kvaliteedijuht ei vahetuks või tagada see, et vahetumisel kanduks üle vajalikud teadmised. Vastasel juhul tuleb tellijal endal süsteemi arendusel praktiliselt käest kinni hoida ja paraku alustada nullist. Enamus tellijaid sellega hakkama ei saa ja ei peagi alati saama ning tulemus on kesine kasutusmugavus. Ühe abinõuna võiks ka siin välja tuua kolmanda osapoole, kes
teostab nii tehnilist kui kasutusmugavuse järelevalvet, et probleemide ilmnemisel neid võimalikult kiirelt teadvustada ja lahendama asuda.
Suur roll on ka tarkvarakoodi kvaliteedi tagamisel ja võtmeroll korrektsel ning põhjalikul teistimisel ja testimisvigade parandamisel, mille pealt ei tohi kokku hoida!
Parem kallim tarkvara ja vähem funktsionaalsust, kui palju funktsionaalust ja vähe kasutustõhusust. See mõjutab konkreetselt töö tulemuslikkust ja sageli mitte vähe.
Meeles tuleb pidada, et tarkvaarenduses nagu mujalgi on osapooltele oluline töö tulemina saadud kasu. Seega tarkvarafirma eesmärk on olemasolevate ressursside raames minimeerida arenduskulud ja maksimeerida omanikutulud ning tellija eesmärk on maksimeerida arendaja arenduskulud ja minimeerida arendaja tulud.
Sellest tulenevalt soovib üks pool teha võimaluste piires võimalikult vähe ja teine pool saada võimaluste piires võimalikult palju. Mille tulemusena omakorda püütakse ühelt poolt kokku hoida projektijuhtimiselt, koodi kvaliteedilt, testimiselt ja kasutusmugavuselt ning teiselt poolt püütakse nõuda võimalikult palju funktsionaalsust ja mittefunktsionaalsete nõuete täitmist. Õige tee on osapoolte võimaluste ja soovide vahel, kokkuleppeline. Ühel poolel peab olema kasumit ja teisel poolel efektiivset tulemit.
