Planera Motivering Kontrollera

Projektansvarsmatris: Essens, konstruktionsregler, exempel

När vi har bestämt oss för huvudrollerna i bör vi gå vidare till utvecklingen av ett mycket användbart dokument, kallat ansvarsmatrisen. Det är viktigt för oss, kära läsare, att inse att under utvecklingen av en matristabell fixar PM ett komplex av inte bara gruppmedlemmarnas ansvar utan även deras befogenheter. Jag föreslår att du tittar närmare på detta ämne.

I PMBOK-manualen (femte upplagan) har ansvarsmatrisen även andra beteckningar: ”matrisdiagram”, ”RACI-matris”. I inhemsk praxis låter detta verktyg ofta som en ansvarsfördelningsmatris. MO i PMI-manualen hänvisar till en tabell som visar de resurser som tilldelats varje arbetspaket. Den visar relationerna mellan teammedlemmar och arbetsmoment.

RACI-metoden används traditionellt för att fylla MO. Detta är ett förkortat namn som bildas av de första bokstäverna i orden: "Ansvarig" (Ansvarig), "Ansvarig" (Ansvarig), "Konsult" (Konsult innan du gör), "Observer" (Informera efter att ha gjort).

Ett exempel på en RACI-matris från PMBOK Guide

Beroende på projektets omfattning tillåter PMBOK att använda ML på olika nivåer med olika grader av bearbetning av arbetsgruppens medlemmars ansvar. Om vi ​​betraktar MO på hög nivå, är grupper och underavdelningar av teamet, å ena sidan, och stora komponenter av ISR, å andra sidan, involverade i att bygga matrisen. Tvärtom, lågnivå MO "sjunker" till detaljeringen av ansvarsfördelningen för specifika teammedlemmar ner till operationsnivån.

Den ryska designpraxisen kännetecknas ofta av utvidgningen av ansvarsmöjligheter upp till införandet av befogenheter även i MO. Detta introducerar en obalans i matrisen. En illustration av detta tillvägagångssätt kan ses nedan.

Ett exempel på ansvarsmatrisen för ett investeringsprojekt i Ryssland

Deluppgifter och ansvar

Det föregående exemplet visar tydligt situationen där fokus på ansvar suddas ut. Hur undviker man en sådan situation? Kom ihåg, kollegor, underavsnittet som ägnas åt ledningsuppgifter. I den analyserade vi en viktig kategori av ledning - "ansvar". Sedan slog vi fast att resursens ansvar innebär dess rätt att acceptera och skyldighet att slutföra uppgiften, utan att hänvisa till några hinder. Låt mig påminna er om exemplet med en Krasnoyarsk-jägare som åtog sig uppgiften att leverera ekorrskinn slagna i ögat inom deadline, men under förutsättning att deras antal inte skulle vara mer än 45 istället för 100. Det var hans regel: att ta bara vad han kunde göra realistiskt.

Chefen är ansvarig resurs för en unik projektuppgift. Vid tidpunkten för planeringen av projektet är dess chef skyldig att säkerställa nedbrytningen av resultatet i deluppgifter, vars sekventiella utförande automatiskt leder till lösningen av nyckeluppgiften. Det är ändamålsenligt att genomföra en sådan nedbrytning kollektivt och involvera medlemmar i projektledningsgruppen i arbetet genom brainstorming. Dess resultat bör vara en plan av milstolpar.

Vanligtvis motsvarar sammansättningen av formuleringen av elementen i tabellen den funktionella läran om förvaltning:

  • utveckling av tekniska specifikationer;
  • distribuera ett prototypsystem;
  • provdrift osv.

Det är mycket mer effektivt om du tillämpar uppgiftshanteringsmetoder. Här är ett exempel på en sådan nedbrytning.

Nedbrytningsschema för projektuppgiften för implementering av produkt Y

Detta exempel är vägledande. Chefen är naturligtvis ansvarig för uppgiften på toppnivå. Och det är uppenbart att projektledning upprättar en ansvarsfördelning för nedbrutna deluppgifter mellan teammedlemmarna. Således mognar logiken i att sammanställa en sådan tabell som ansvarsmatrisen naturligt. Dess konstruktion börjar med formuleringen av uppgifter.

Personligen är jag imponerad av det lakoniska förhållningssättet till tillämpningen av matrismodellen, eftersom förpliktelse, som en synonym för ämnet för vår studie, också är ett mänskligt tillstånd: antingen existerar det eller inte. Och viktigast av allt, en sådan stat kan inte fördelas på flera personer. För administrationsändamål kan den bara ha en enda operatör. Annars går ansvaret i viss mån förlorat. Vårt nedbrytningsexempel dikterar följande matrisform.

Förenklad ansvarsmatrisvariant

Ansvar och auktoritet: hur undviker man misstag?

Jag tror att särskilt nybörjare måste lära sig att fylla i en förenklad matris och säkerställa dess prestanda och kontroll, och sedan gå vidare till mer komplexa konfigurationer, samtidigt som man undviker vanliga misstag som ibland händer. Oavsett antalet ansvarsalternativ (bokstäver som används i tabellen för att fylla i den) bör vissa ifyllningsregler följas. Att bygga ett MO-projekt kräver följande viktiga regler:

  1. Arbeta på MO med hela teamet, försök att slutföra det på en enda session.
  2. Fyll först i alla celler med ansvar, uteslut situationen när det finns linjer utan "O"-symbolen.
  3. Följ RACI-metoden, undvik att utöka omfattningen av befogenheter från kategorin "Entreprenör", "Avtal", som i själva verket inte bär ansvar för innehållet.
  4. Eliminera situationen med tomma kolumner i MO.
  5. Komponera flera alternativ för MO, med början från toppnivån och observera principen om koncisitet.

Om du inte tar hänsyn till de speciella reglerna som beskrivs ovan är det lätt att göra misstag, som då försämrar kontrollförmågan, minskar effektiviteten i projektledningen. För att undvika en sådan situation är det bättre att omedelbart kontrollera dig själv för möjligheten att göra ett misstag när du arbetar med MO. Att bygga en MO kan åtföljas av typiska misstag:

  1. Tillåt en situation där två tecken skrivs in i en cell.
  2. Överbelasta MO med symboler, vilket försämrar dess användbarhet.
  3. Efter godkännandet av MO, "lägg det på hyllan" och glöm, vilket eliminerar innebörden av att använda MO som ett verktyg för direkt kontroll av mellanresultat och efterfrågan från ansvariga resurser för projektets uppgifter.

I den här artikeln, kära kollegor, har vi tillsammans med er betraktat frågan om begreppet, essensen och innehållet i ansvarsmatrisen som en väsentlig del av projektplanering och genomförande. Traditionell metodik och exempel på ML-konstruktion presenteras. Författarens ståndpunkt om fördelarna med ett mer kategoriskt synsätt på ansvar och dess fördelning anges. Reglerna för utveckling av MO och relaterade fel har förtydligats.

Jag är övertygad om att en projektledare som styrs av regeln "Less is more" när det gäller att fördela ansvar är mer framgångsrik. Detta beror också på att konstruktionen av MO är implementerad i det unika läget. Därför rekommenderar jag varje PM att börja med enklare formulär, vilket gradvis komplicerar tillämpningen.