I vårt webbseminarium "The 7 Deadly Sins of Project Management" fick vi nyligen höra av Justin Rowe, Practice Director på vår konsultpartner Lewis Fowler. I presentationen diskuterade Justin projektledningens synder och hur man kan känna igen dem och korrigera dem. Detta resulterade i ett stort deltagande av deltagarna i frågor, varav många var mycket informativa och relevanta. Här är svaren på de viktigaste frågorna som kom in.
- Ser du att PPM-grupper betonar vikten av att utnyttja befintliga domänmönster och strukturer för användning och återanvändning inom företaget?
[Justin] Jag anser att detta är något som alltid bör uppmuntras både ur ett projekt- och portföljhanteringsperspektiv. Under hela projektets livscykel måste en kultur av kontinuerligt lärande och upptäckt betonas, eftersom gruppmedlemmar med olika lång erfarenhet kan tillämpa sina kunskaper på projekten när de genomförs. Det är viktigt att tillämpa lärdomar i denna situation igen för att fånga upp förändringar och fluktuationer i verksamheten, särskilt på affärsenhetsnivå. Eftersom projektkrav kontinuerligt fångas upp och prioriteras, är det värdefull information som bör ingå i projektets beslutsprocess att integrera domänkunskap och strukturen för vad som ska bli projektets slutprodukt eller lösning.
När det gäller förvaltningen av projektportföljen beror detta också på i vilken riktning portföljen går med avseende på organisationens strategi och de intressenter som projekten är avsedda för. Domänkompetens måste samlas in, kommuniceras och användas på strategisk nivå i organisationen, genom att tillämpa en balanserad strategi för portföljstyrning samtidigt som projekt- och portföljteamen får möjlighet att prestera på ett mycket effektivt och ändamålsenligt sätt. Som jag nämnde under webbseminariet kan man genom att låta PPM-teamet förankra sig i sin kundbas och i intressentområden öka sin domänkompetens för att se till att de fokuserar på att driva de förväntade projektresultaten samtidigt som de hanterar projektets alla områden (omfattning, tidsplan, budget, risk etc.). På så sätt får PPM-teamet ytterligare insikt och situationsmedvetenhet om projektets status, samtidigt som mer data samlas in kvantitativt i det använda PPM-verktyget.
- Var hamnar ett programledningskontor i hierarkin för portfölj-/projektledningskontor? Min organisation vill standardisera PMO:er på avdelningarna, fastställa riktlinjer, styrning osv.
Min erfarenhet är att inrättandet av ett programförvaltningskontor beror på ett antal omständigheter, men alltid på själva situationen. För det första har utnämningen att skapa ett formellt Program Management Office att göra med flera, mer strategiska faktorer som inkluderar storleken och komplexiteten hos projekten i portföljen, den styrningsstruktur som krävs för att möjliggöra det och hur det anpassar sig ekonomiskt till organisationen. Ökad komplexitet i antalet projekt och hur det påverkar företagets budgetplanering och genomförande kan användas som ett underlag för att avgöra om ett program bör inrättas med ett programförvaltningskontor. När projekten genomförs hanteras individuella budgetar inom varje projekt där det totala beloppet kan vara på hundratusentals dollar, till exempel, medan beloppet för ett program med flera projekt som är strategiskt kopplade och anpassade till utvecklingen av en större produkt kan vara på hundratusentals miljoner dollar. Om det finns ett ökat krav på struktur och styrning inom projektportföljen, kan detta också användas som en input till potentialen för ett Program Management Office. Det finns många andra situationer som måste inträffa för att man ska kunna fastställa det verkliga "behovet respektive önskemålet" när det gäller ett programförvaltningskontor. Men här är några frågor att tänka på...
- Finns det flera projekt som inte nödvändigtvis har samma omfattning, men som stöder utvecklingen av en övergripande produkt eller lösning?
- Finns det flera projekt med budgetar som är finansiellt kopplade till varandra och som leder till utvecklingen av samma produkt eller lösning?
- Finns det ett krav på att hantera flera projekt som är nära sammanlänkade med relaterade fördelar som är anpassade till ett mål på strategisk nivå?
- Finns det ett krav på strategisk styrning av flera projekt där resurser, beroenden och andra projektrelaterade variabler är nära samordnade?
Genom att besvara några av dessa frågor kan man ge en första vägledning om det eventuella behovet av att inrätta program och ett programförvaltningskontor. PMI:s Standard For Program Management, Third Edition är också en bra referenspunkt som kan ge en inblick i din fråga.
- Ser du att PMO:er använder Kanban-planeringsverktyg för att hantera utvecklingsarbete (t.ex. iterationer och Scrums)?
När det gäller utvecklingsprojekt, och om man antar att denna fråga är inriktad på programvaruutveckling, är Kanban ett utmärkt sätt att visualisera framsteg och se var problemen kan uppstå. Genom den kontinuerliga smidighet som finns i denna metodik kan Kanban också användas för PMO:er, oavsett om de stöder en IT-funktion eller inte, eller om de inte är relaterade till IT alls. Fokus med Kanban är att förstå och visualisera arbetsflödet, hur snabbt uppgifterna utförs och förmågan att identifiera problem som omedelbart kan lösas för att stödja kontinuerligt lärande. Dessutom kan teamet tillämpa gränser för pågående arbete där kapaciteten för de uppgifter som någon kan utföra begränsas för att säkerställa att kontinuerlig leverans av programvara möjliggörs.
När det gäller schemaläggning kan man genom att tillämpa lärdomar från kapacitetsbegränsningar i tidigare projekt eller iterationer i det aktuella projektet stödja förmågan att hålla schemaläggningen agil, utan att hindra projektets framskridande. Genom att tillämpa Scrum-metoder som sprintar (fasta tidsperioder, 2 veckor till exempel) med Kanban kan man också använda sig av Kanban för att definiera mätvärden som rör prestanda och hastighet, men även cykeltider inom specifika uppgifter som har definierade ingångar till utgångar. Flexibilitet och användning av båda metoderna bör definieras, beroende på utvecklingsmiljön och den situation som bäst passar utvecklingsgruppens förmåga att effektivt utföra arbetet.
