מדוע התרשים של המבנה הארגוני לא ממש עוזר לנו, אנשי העמל, שמריצים את הפרויקט מנקודת ההתחלה לנקודת הסיום?

מבנים ארגוניים מסורתיים מתארים את האחריות של בעלי התפקידים בצורה פטריארכאלית, כפירמידה של ריבועים המסודרים בתוך משולש דמיוני.  מטרתם היא להגדיר בגדול את הפונקציה והשם של המנהל האחראי על תפקוד אותה פונקציה. מידע זה חשוב ביותר, אך לניהול הפרויקט בשטח הוא רחוק מלהספיק. מה חסר? חסרה הגדרה מפורטת של אוסף המשימות והפעילויות שכלולות בתכולת התפקיד. כמו כן, המבנים הפטריאכליים לא מתארים את זרימת המידע האמיתית בפרויקטים, כיוון שהם אינם מתארים את כל הקשרים שאינם קשרים אנכיים בין חברים בארגון. גם תיאורים של ארגונים כרשת, עם קווי שתי וערב, קווים אלכסוניים, קשתות וכדומה – מראים קשרים איכותיים. לאנשי הצוות בפרויקט – מידע זה אינו מספיק. אנשי הצוות בפרויקט מייצרים תפוקות במהלך הפרויקט, ועליהם לדעת בכל נקודה בציר הזמן מיהם בעלי העניין השותפים בתהליך.  בכל נקודת זמן בפרויקט, ובמהלך פיתוח כל תפוקה שהיא, נדרשים אנשי הצוות לזהות את הסוגים השונים של בעלי העניין הרלוונטיים לכל משימה או תפוקה. אי זיהוי נכון או אי שיתוף בזמן של בעל עניין טומן בחובו סיכון רב של חבלה בהצלחת הפרויקט.

לכל מטלה או תפוקה, ישנם סוגים שונים של בעלי עניין:

• אחראי – Responsible – בעלי עניין שאחריותם לבצע את המטלה, לייצר את התפוקה, ולדאוג לקבלת משוב על איכות עבודתם משאר בעלי העניין הרלוונטיים;
• נושא באחריות – Accountable – בעל עניין שהוא מקבל את ההחלטות, ובין היתר, אחראי לכך שהתפוקה תהיה איכותית; האדם שנמצא בחזית ואליו פונים בשאלות או אפילו תלונות לגבי איכות התפוקה וזמני האספקה שלה. אותו מנהל דואג למשאבים הנדרשים לביצוע המטלה, ובסמכותו להאציל את ביצועה לאנשים אחרים, אחראי-ביצוע. בסיום המשימה, המנהל הנושא באחריות מאשר (בחתימה או בדרך אחרת) שאכן המשימה בוצעה לשביעות רצונו. לכל משימה חייב להיות אדם אחד שהוא נושא באחריות.
• יועץ – Consulted – אדם מומחה בתחום המשימה עימו מתייעצים לגבי ביצועה ו/או מזמינים אותו לסקירה של התוצר
• דורש דיווח – Informed – בעל עניין שמודיעים לו על מצב המשימה. בדרך כלל, בסיומה.

הגדרה מדויקת של תפקידי כל בעלי העניין, בכל שלב במהלך הפרויקט, ואפילו ברמת תשומה בודדת מקלה מאד על תהליך קבלת החלטות בפרויקט ומאיצה את קצב ההתקדמות.

מודל R.A.C.I נבנה כדי להתמודד עם אתגר זה.

להלן דוגמה:

איך בונים את טבלת ה- R.A.C.I?

ראשית, רושמים את רשימת הפעילויות שיש לעשות בפרויקט (שורות). לאחר מכן, רושמים את בעלי התפקידים בעמודות. לאחר שהטבלה מוכנה – כותבים בתאים את הקודים המציינים את תרומת בעלי העניין –  R.A.C.I.  עוברים על התאים הריקים כדי לוודא שאכן לאותם בעלי עניין אין כל תרומה או צורך לידיעה במשימה הספציפית. מאידך, אם שמנו יותר מידי משתתפים לביצוע משימה מסוימת, נוודא שאכן כולם חיוניים. משתתפים רבים מידי יגרמו לסרבול ואפילו להפרעה. מספר קטן מידי של משתתפים, יכול להעיד על בעיות בתקשורת. לסיום – סוקרים את התוצאה ומוודאים שיש לפחות Accountable (A) אחד לכל משימה.

לסיכום, מה היה לנו עד כה ?

תהליך ה-R.A.C.I  מתווסף ליצירת לו"ז הפרויקט, בכך שהוא מזהה מראש את כל השותפים בכל משימה ומשימה ((WBS ואת מידת התרומה של כל בעל עניין להצלחת אותן משימות. כך  תורם התהליך לשיפור התקשורת והאיכות בפרויקט.