Även om gamla principer för affärsverksamhet är användbara finns det undantag från regeln. Ibland är det till exempel inte en bra idé att "lova för lite och leverera för mycket". Och även om det är ett bra råd att "berömma högt och klandra tyst" finns det situationer där detta inte gäller.
Sedan finns det en annan visdom som är så djupt rotad i affärstänkandet att den för många chefer och ledare är okränkbar och oomtvistlig: "Kunden har alltid rätt." Utom när de inte är det. Och få yrkesverksamma vet detta bättre - men önskar att de inte gjorde det - än projektledare som har gått till Kampen mot det fruktade "scope creep"..
Scope creep är en begäran om ändring från en kund - som vanligtvis är i form av ett kommando - som ligger utanför den överenskomna omfattningen och som, om den genomförs, skulle ha en väsentligt negativ inverkan på projektets kostnad eller tidtabell (och vanligtvis båda). I vissa fall kan sådana önskemål ha en minimal eller tolerabel inverkan på projektet i fråga, men skulle ha en negativ inverkan på ett annat projekt i portföljen.
Eftersom scope creep är fienden måste projektledarna på ett skickligt sätt förhindra det på ett sätt som inte bara håller projektet på rätt spår utan samtidigt förhindrar att kunderna blir missnöjda - eller ännu värre, rasande. Det är en svår jonglering, men tack och lov (och för all del) är det inte omöjligt. Så här ser spelplanen ut:
Steg 1: Förstå avsikten
Innan du skriker ut några fraser som inte är säkra på jobbet eller försöker se om bärbara datorer kan flyga om de kastas ut genom fönstret (tips: det kan de inte), ska du ta några djupa andetag och försöka lära dig vad kunden vill ha. Det kan vara ömsesidigt upplysande.
En kund kan till exempel lättvindigt säga att de vill att en mjukvara som håller på att utvecklas ska uppfylla en komplex säkerhetsstandard som inte finns med i avtalet. Det är bättre att vara klok (och att hålla ett säkert blodtryck) att ha ett samtal om denna "begäran" som kategoriskt sett är utanför räckvidden, och helst få bort den från bordet så snabbt som den kom.
För att fortsätta exemplet kan kunden efter ett samtal komma överens om att det är onödigt att följa säkerhetsstandarden, eller att det kan vara kontraproduktivt om det skapar problem med användbarhet eller kompatibilitet i framtiden.
Steg 2: Förklara konsekvenserna
I idealfallet kan samtalet som beskrivs ovan få stopp på potentiell scope creep till allas belåtenhet. Men eftersom projektledning kan handla mindre om idealism och mer om skadekontroll fungerar det inte alltid. Om vi ska vara brutalt ärliga fungerar det faktiskt inte så ofta (men försök ändå).
Nästa steg är att på ett tydligt och professionellt sätt förklara för kunderna att Newtons tredje lag lever och frodas i projektledningsvärlden: för varje handling finns det en motsatt och lika stor reaktion. Översatt i samband med scope creep innebär detta att kunder som insisterar på att deras önskemål ska förverkligas måste förstå att "något måste ges". Och detta kommer att vara öka budgeten, förlänga tidsplanen (och alla leveranser och tidsfrister som påverkas), minska eller eliminera vissa projektmål, och så vidare.
Det är inte lätt att få kunderna att acceptera dessa konsekvenser. Men å andra sidan är det inte lätt att vara projektledare. Använda fakta och bevis (t.ex. olika versioner av möjliga tidsplaner, framhävande av relevanta delar av det ursprungliga avtalet osv.) är avgörande här, liksom att visa att man vill lindra smärtan. En projektledare som vet att kunden är särskilt kostnadskänslig kan till exempel föreslå lösningar som minimerar påverkan på budgeten. Även om kunden (motvilligt) accepterar budgetökningen kommer de att uppskatta att projektledaren försökte dämpa effekterna.
Steg 3: Dokumentera allt
Projektledare som ras föredrar att göra saker snarare än att dokumentera saker, vilket inte är något dåligt. Men när det gäller att fånga upp och begränsa scope creep är dokumentation avgörande.
Om projektledarna är för upptagna för att lägga in alla data och detaljer - inklusive noggranna anteckningar om alla kundkonversationer och möten - är det bäst att delegera (inte dumpa) detta till en kvalificerad teammedlem.
Steg 4: Kartlägg, övervaka och hantera
När förändringsbegäran har godkänts officiellt måste den kartläggas, övervakas och hanteras med hjälp av programvara för projekthantering att:
- Den är molnbaserad och kopplar samman alla medlemmar i förändringskontrollgruppen, oavsett var de befinner sig eller när de arbetar.
- Lagrar och organiserar alla anteckningar, filer och andra dokument som ger ytterligare information (t.ex. riktlinjer, specifikationer osv.).
- Spårar förändringsbegäran i realtid (t.ex. procentuell andel slutförda, faktisk och återstående ansträngning osv.).
Och lika viktigt är att kunderna hålls informerade med hjälp av instrumentpaneler, widgets, diagram, diagram och så vidare, utan att de blir förvirrade eller förvirrade av överflödig information. Det sista projektledarna vill är att uppnå de nya målen för omfattningen, men få kritik för att de missat eller missförstått något.
Silver Lining
Vi har varit ganska hårda mot scope creep - och det finns ingen ursäkt för detta. Oavsett hur det yttrar sig är scope creep skadligt och måste förhindras. Det kallas trots allt inte för något trevligt eller positivt som "scope flex" eller "scope scale" eller "scope surge". Det kallas scope creep. Saker som är läskiga är... ja, läskiga. De brukar inte vara bra gåvor eller husdjur.
Det finns dock en positiv aspekt för projektledare som använder ovanstående steg för att omvandla scope creep till scope change: det kan leda till värdefulla insikter som gynnar det aktuella projektet och eventuellt andra projekt i portföljen. Och det är inget läskigt med det!
Läs mer
Clarizens molnbaserade programvara för portfölj- och projekthantering hjälper projektledare att undvika och förebygga scope creep, så att de kan nå mållinjen i tid, inom budget och omfattning - och med en informerad och imponerad kund i slutändan.
Om du vill veta mer kan du starta en fullfjädrad 30-dagars gratis provperiod av Planview AdaptiveWork, eller boka in din live guidad demonstration.
