Idealvärld eller pragmatism. En efterkommentar.

Del 3 dröjde lite - den fysiska verkligheten trängde sig på :-)
För de som inte läst del 1 & 2 rekommenderas att göra det innan man läser det följande.

Till syvende og sidst är vi som användbarhetsexperter beroende av de förutsättningar vi ges av beställare och projektledare.
Visst kan vi påverka en del, men ibland begränsas vi av verkligheten.

Exempel: "Vi har en första release om 8 veckor. Användbarhet är viktigt för oss, kan du hjälpa till".
Applikationen är då i princip färdig, den ska bara testas och rättas. Alternativt man har verkligen tänkt sig att en fullständig tjänst ska specas, designas, byggas, testas och implementeras på den tiden.

Orsakerna till dessa två scenarios skiljer sig något.

I det första fallet har någon kommit in sent i projektet och upptäckt att användargränssnittet ser för jävligt ut. Eller så har någon gått på en kort kurs och fått idéer. Det är också vanligt förekommande att man upplever sig ha specat hela applikationen/tjänsten/webben och bara vill ha feedback på detaljer när det i verkligheten är så att underlaget mer är att betrakta som en idé.

I det andra fallet har man fått för sig att IT-relaterade konsulter ska hållas kort, annars springer kostnaderna i väg. Så man lägger en stenhård projektplan och försöker kontrollera utförarna i minsta detalj.

I bägge fallen handlar det om god vilja och goda intentioner som slår fel.

Som projektledare eller beställare måste man försöka förstå att standardsystem INTE, som leverantörerna försöker påskina, innebär att det är "plug'n'play". För det är det inte. Jag har hittills inte sett ett standardsystem som inte behöver konfigureras noga, som inte kräver omfattande insatser. I vissa fall finns ett oändligt antal alternativa valmöjligheter som var och en påverkar hur resten av systemet kommer bete sig. I andra fall finns inga valmöjligheter alls utan verksamhet och organisation måste anpassa sig till hur systemet fungerar.

Och det gäller att planera projektet därefter. Annars kommer -

a) projektet dra över tidsmässigt
b) projektet kosta minst dubbelt så mycket som budgeterat
c) resultatet trots a & b inte motsvara förväntningarna

Och i utgångsläget handlar det förstås om att verkligen förstå det standardsystem man köper. Och den hjälpen kommer man i ärlighetens namn inte få från leverantören. För de säger bara att deras system kan allt. Och det kan det. Om man programmerar om alltihopa. Men det är det ingen som talar om.