רגע, אז מי בכלל אחראי?
איך מחלקים תפקידים ואחריות לבעלי הענין השונים בניהול פרויקטים?
על מטריצת ה- RACI ואופן השימוש בה.
כשמסתכלים סביבנו על תפקיד מנהל פרויקט, רואים ערב רב של תפקידים וצורות יישום.
לחלק קוראים "מוביל פרויקט", לחלק "ראש פרויקט" ולרוב פשוט "מנהל פרויקטים", בכל מקום ובכל ארגןן ההגדרה משתנה: לפעמים פורמלי לפעמים לא פורמלי, לפעמים במשרה מלאה ולפעמים "בנוסף על תפקידו" (נע"ת), לפעמים תפקיד בכיר ולפעמים זוטר, לפעמים פרויקטי ענק ולפעמים משימות פשוטות.
אבל בכולם יש אותו רעיון, סט של משימות שצריך לבצע כדי להשיג יעד מסוים. ההגדרה למנהל פרויקט כפי שהיא מופיעה ב"גוף הידע בניהול פרויקטים", או בשמו המוכר, ה- PMBOK, מדברת על כך שמנהל הפרויקט הוא "האדם שנבחר ע"י הארגון להוביל את הפרויקט להשגת יעדיו".
ולכן מניסיוני כשמדברים על תפיסת תפקיד, יש מכנה משותף מאד ברור לכולם, וזוהי האחריות! מנהל פרויקט הוא האחראי להשגת יעדי הפרויקט. האחריות על הצלחת הפרויקט או כשלונו מוטלת על כתפיו של מנהל הפרויקט.
איפה זה מתחיל להסתבך? כשעושים את האבחנה בין אחריות לסמכות. אז רואים שבמבנה ארגוני מטריציוני, שבו אנשים שונים בארגון נותנים שירותים למנהל הפרויקט (שרותי תוכנה, בדיקות, ייצור, תפעול ועוד), אחריות אינה מלווה בסמכות, ויוצרת למנהל הפרויקט בעיה קשה כאשר עליו מוטלת האחריות להשיג את תוצאות הפרויקט, אך אין לו סמכות לדרוש ביצוע מאנשים שאינם כפיפים שלו… וזה מאתגר במיוחד.
אם נוסיף על זה את נושא הגיוון בצוות שדובר בפוסט הקודם, נראה שהמצב מורכב אף יותר- לא רק שאני כמנהל פרויקט אחראי על התוצאות מבלי להיות בעל סמכות על צוות הפרויקט, עכשיו נוסיף לזה צוות מגוון בהיבטי גיל, רקע מקצועי, דת, תרבות, לאום- והבלגן חוגג.
לגיוון שכזה יש הרבה יתרונות: קרקע פוריה ליצירתיות, רעיונות חדשים, מחשבה פורצת דרך, פתרון בעיות בצורה אחרת וכד'. מצד שני, גם ככה ככל שיש יותר אנשים יותר קשה להבין מי עושה מה, על אחת כמה וכמה כאשר יש אנשים שונים מה שבאופן טבעי מייצר יותר מקום לפרשנויות, אי הבנה, טעויות וחוסר סנכרון. אז איך מנצחים על כל התזמורת הזו?
חלוקת תפקידים ואחריות
אין פתרון קסם, וזה לא שמנהל הפרויקט פשוט יגיד- והכל יתבצע, כמו במשחק הילדים "הרצל אמר להרים ידיים"…
ממש לא, כולנו בני אדם ולכל אחד יש דיעה ורצון והבנה ופרשנות משלו, וצריך הרבה תקשורת, קשב, יכולות בינאישיות, פגישות ושיחות, כדי לסנכרן את כל העוסקים בפרויקט.
מה שכן, יש כלי פשוט למדיי, שמניסיוני יכול לעזור, ולכלי הזה קוראים RACI.
RACI
מודל RACI משמש להגדרת תחומי אחריות ומעורבות של הגורמים השונים בפרויקט.
לא משנה מה גודל הפרויקט, תמיד צריך להגדיר תפקידים, כולם צריכים לדעת מה הסמכויות שלהם ועל מה הם אחראים בפרויקט. דרך אחת להגדרת הסמכויות היא בעזרת מטריצת RACI. זו מטריצה שמראה עבור כל משימה מה התפקיד של כל שותף בפרויקט. השיטה מפחיתה בלבול ומגדירה ציפיות ולכן משפרת את היעילות בפרויקט. החלטות מתקבלות ביתר קלות, יש אחריות ברורה לכל משימה ועומס העבודה מחולק בצורה שווה.
ה- RACI מצוין ב PMBOK בפרק 9 של ניהול משאבי הפרויקט ונקרא "תרשים מטריצה", שם הוא מתואר כדרך טובה להקצות תפקידים, תחומי אחריות, ורמות סמכות לפעילויות מוגדרות.
אז בואו נסביר מה זה בדיוק:
RACI הם ראשי תיבות של
R – Responsible – אחראי לביצוע המשימה
A – Accountable – הנושא באחראיות להשלמת המשימה
C – Consulted – מי מתיעצים איתו לביצוע המשימה
I – Informed – מי שמיודע על פרטי המשימה
הרעיון הוא ליצר מטריצה שמגדירה עבור כל משימה מה סוג הסמכות שיש לכל עובד.
בואו נסתכל על דוגמא שתמחיש את הנושא:
יגאל מפתח את פיצ'ר X שיתממשק לפיצ'ר Y שמפתחת יעל. יוגב הוא מנהל הפרויקט ואירית היא מנהלת המרקטינג. עבור פיצ'ר X יגאל הוא -Responsible הוא זה שמבצע את העבודה, יעל היא Consulted כי הפיצ'ר שמפותח צריך להתממשק עם הפיצ'ר שהיא מפתחת, יוגב הוא Accountable כי הוא מנהל הפרויקט ואירית היא Informed כי היא רק צריכה לדעת שהפיצ'ר הסתיים. כך זה יראה בטבלה:
יגאל | יעל | יוגב | אירית | |
פיצ'ר X | R | C | A | I |
פיצ'ר Y | C | R | A | I |
מה הופך את RACI ליעיל?
השימוש במטריצה נותן למנהל הפרויקט ולצוות תמונה ברורה של מי אחראי על מה, ומבטיח תקשורת טובה יותר בין האנשים, עם האנשים הנכונים בזמן הנכון ובכך חוסך זמן לכולם.
בנוסף מנהל הפרויקט והארגון מקבלים תמונה של עומס העבודה וניתן לראות בבירור אם יש משאבים שלא מנוצלים או שכאלו שמועמסים בצורה חריגה כי הם מופיעים עם R יותר מדי פעמים.
אז איך מנהלי פרויקטים משתמשים ב RACI?
יש שישה שלבים להגדרת המטריצה:
- הכנת רשימה של משימות הפרויקט
- זיהוי כל המעורבים בפרויקט
- זיהוי כל האחראים לביצוע (R) והאחראים למשימה (A)
- וידוא שיש רק A אחד לכל משימה
- הוספת כל המתיעצים (C) והמעורבים לידיעה (I)
- שיחה עם כל המעורבים בפרויקט ווידוא שכולם יודעים מה תפקידם
כללי "עשה ואל תעשה" לשימוש במטריצת RACI
- רק Accountable אחד! אם יש יותר מאיש זה כמו שיהיה יותר מנהג אחד באוטו….
- ודאו שהכמות הנכונה של אנשים הם Responsible. יותר מדי אנשים לאותה משימה זו דרך בטוחה לבזבוז זמן. אם המשימה קצרה ופשוטה ה A וה R יכולים להיות אותו אדם
- אל תשתמשו ביותר מדי Consultants. יותר מדי יועצים יאטו את המשימה ויגדמו לוויכוחים מיותרים ויותר מדי דעות
- שמרו על אנשים מיודעים, אולי לא צריך להתיעץ עם כולם, פשוט מספיק לידע אותם? שימו לב שיש אנשים בטור הזה, זה יחסוך אי נעימיות בהמשך הדרך.
- הפכו את ההכנה של המטריצה למשימה משותפת. כולם צריכים להרגיש בנוח עם התוצאות.
שימוש נכון במטריצת RACI יפשט את הסנכרון ויפחית תקשורת מיותרת, יפתור בעיות של מי צריך לעשות מה, יתן תמונה ברורה של עומס וכתובת ברורה לכל משימה. אין ספק שגם שביעות הרצון של המעורבים בפרויקט תגדל.
כנראה שה- RACI לא יבטיח שהעבודה תתבצע…, אבל לפחות כל אחד יודע מה חלקו במערכה, וזו כבר התחלה טובה-
בהצלחה!
ולקינוח סרטון קצר שמסביר מה זה RACI