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

אורנה קמין, מנכ"לית OK יועצים לניהול

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

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

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

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

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

R.A.C.I = Responsible Accountable Consulted Informed
במודל זה יוצרים מטריצה, שבה השורות הן הפעילויות והמשימות, והעמודות הן בעלי התפקידים. השורות מתארות את עשרות או מאות הפעילויות במחזור החיים, ואילו העמודות מתארות כל בעלי התפקידים. על בעלי התפקידים נמנים כמובן חברי צוות הפרויקט ושאר בעלי העניין במעגלים הקרובים והרחוקים. בתוך התאים של המטריצה רושמים את האותיות RACI בהתאם למשימה ולבעלי העניין העוסקים בביצועה.

להלן דוגמה:

Resource

Eng. Mgr

Biz. Mgr

Proj. Mgr.

Prd
Mgr.

SW Mgr

HW
Mgr

Quality
Mgr

Test
 Mgr
NPI
Mgr
Sys.
Eng.

Finance
Mgr.

Deliverable/
Work Package

Nam1

Nam2

Nam3

Nam4

Nam5

Nam6

Nam7

Nam8

Nam9

Nam10

Nam11

Marketing Req. Definition

I

A

R

I

C

I

Project Management Plan

A

R

I

C

C

C

C

C

C

Technical Requirements Spec.

A

C

C

C

C

C

I

R

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

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

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

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

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

להרשמה השאירו פרטים

    ארכיון ניוזלטרים >>