På IT-sidan var man ursinnig för att systemet inte var stabilt efter de 30 dagarna och för att det inte uppfyllde de fastställda kriterierna för överlämning till verksamheten.
På verksamhetssidan var man ännu argare, för att man hade mer att göra istället för mindre (som planerat), och blev tvungen att ta in extra personal, som man inte hann utbilda. Det blev ingen formell överlämning – teamet bara avvecklades.
Men inom själva teamet var man nöjd. Projektet höll tidtabellen, drog över budget bara lite och levererade ett system som funkade (även om det inte var helt stabilt än).
Nyckelfrågan är: När är ett projekt avslutat? Och svaret bör vara: när man har svart på vitt på att det uppfyller alla i förväg ställda krav. För då är det verksamheten som avgör när det är klart, inte projektteamet själva.
Ofta går det till så här:
• Teamet ställer inte upp tydliga, mätbara affärsresultat som mål, utan definierar mål i termer av system eller på projektets villkor.
• Verksamheten förstår inte det glapp som uppstår mellan vad projektet levererar och vad verksamheten behöver
• Projektet levererar det det ska, men nu ser verksamheten glappet och börjar tycka att projektet egentligen inte har levererat. Projektet åläggs att överbrygga glappet, men har sällan det som krävs för att göra det
• Teamet avvecklas, och verksamheten känner sig lurad. Ännu ett misslyckat projekt.
Att man kommer överens med verksamheten om ”överlämningskriterierna” på ett tidigt stadium är praxis sedan länge. Men ofta blir det fel kriterier, eftersom projektet planeras för att leverera på sina egna villkor, inte verksamhetens fördelar.
Byter man kriterier kommer överlämningsdiskussionen istället att handla om vilka på listan som projekt respektive verksamhet ska ta fullt ansvar för. För nu finns det inget glapp mellan vad projektet levererar och vad verksamheten vinner.
Så när projektet leverar som överenskommet har organisationen en plan för hur man ska går vidare och driva hem alla vinster och fördelar man ville ha. Projektet har lyckats.
För projektsidan är frestelsen att se till att man själv har ansvar för så få punkter som möjligt. Men kom ihåg att målet aldrig bara är att bli klar; målet är att möjliggöra fördelar och vinster för verksamheten. Det och bara det får styra hur ansvaret fördelas.
Alltså: Bestäm så tidigt som möjligt var projektet slutar och verksamheten börjar – en tydlig överlämningspunkt. Den måste vara mätbar och odiskutabel, och måste göra det möjligt för verksamheten att ta över och driva hem återstående vinster.
På verksamhetssidan var man ännu argare, för att man hade mer att göra istället för mindre (som planerat), och blev tvungen att ta in extra personal, som man inte hann utbilda. Det blev ingen formell överlämning – teamet bara avvecklades.
Men inom själva teamet var man nöjd. Projektet höll tidtabellen, drog över budget bara lite och levererade ett system som funkade (även om det inte var helt stabilt än).
Nyckelfrågan är: När är ett projekt avslutat? Och svaret bör vara: när man har svart på vitt på att det uppfyller alla i förväg ställda krav. För då är det verksamheten som avgör när det är klart, inte projektteamet själva.
Ofta går det till så här:
• Teamet ställer inte upp tydliga, mätbara affärsresultat som mål, utan definierar mål i termer av system eller på projektets villkor.
• Verksamheten förstår inte det glapp som uppstår mellan vad projektet levererar och vad verksamheten behöver
• Projektet levererar det det ska, men nu ser verksamheten glappet och börjar tycka att projektet egentligen inte har levererat. Projektet åläggs att överbrygga glappet, men har sällan det som krävs för att göra det
• Teamet avvecklas, och verksamheten känner sig lurad. Ännu ett misslyckat projekt.
Att man kommer överens med verksamheten om ”överlämningskriterierna” på ett tidigt stadium är praxis sedan länge. Men ofta blir det fel kriterier, eftersom projektet planeras för att leverera på sina egna villkor, inte verksamhetens fördelar.
Byter man kriterier kommer överlämningsdiskussionen istället att handla om vilka på listan som projekt respektive verksamhet ska ta fullt ansvar för. För nu finns det inget glapp mellan vad projektet levererar och vad verksamheten vinner.
Så när projektet leverar som överenskommet har organisationen en plan för hur man ska går vidare och driva hem alla vinster och fördelar man ville ha. Projektet har lyckats.
För projektsidan är frestelsen att se till att man själv har ansvar för så få punkter som möjligt. Men kom ihåg att målet aldrig bara är att bli klar; målet är att möjliggöra fördelar och vinster för verksamheten. Det och bara det får styra hur ansvaret fördelas.
Alltså: Bestäm så tidigt som möjligt var projektet slutar och verksamheten börjar – en tydlig överlämningspunkt. Den måste vara mätbar och odiskutabel, och måste göra det möjligt för verksamheten att ta över och driva hem återstående vinster.
Gratis nyhetsbrev
