אני שמחה לארח בבלוג חברה וקולגה, שירי טלר חסון, Head of Global Delivery Operations at Gett, שכתבה פוסט מרתק ומדויק המסכם את חמשת העקרונות לניהול פרויקט מוצלח. שימו לב שבסוף הפוסט יש גם כלי אקסלי שמאפשר להטמיע את העקרונות באופן מיידי. תודה שירי 🙂

בפוסט הזה אני אתמצת את חמשת העקרונות לניהול פרויקט מוצלח. אחד האתגרים בניהול פרויקטים הוא כיצד לייצר alignment בין כל השותפים לפרויקט, איך מחלקים את האחריות בין השותפים לפרויקט מבלי להיות אגרסיבים מדי ואיך מנגישים ומייצרים שקיפות לגבי התקמות הפרויקט. הפוסט הזה הוא מדריך מתומצת איך לעשות את זה, ולהפוך אתכם לMASTERS בניהול פרויקטים. בהמשך אצרף לינק לקובץ גוגל דוקס, שתוכלו להעתיק לעצמכם, שמרכז את כל חמשת השלבים ומנגיש אותם עבורכם, ובכך לשדרג את הדרך בה אתם מנהלים פרויקטים בארגון שלכם.
חלק א: תכנון הפרויקט, הגדירו את הדברים הבאים:
- ה-Objective: כאן כותבים את מטרת העל, למשל: improve / reduce / increase / save money / sales/ deliveries / satisfaction
- ה- Deliverables: מה המוצר הסופי שאתם אמורים לייצר? למשל: יכולת חדשה מסוימת, הטמעה של מערכת, יצירת playbook, הטמעה של מוצר וכו’
- ה- Key results: כאן כותבים בדיוק מה המדד שרוצים לשפר, למשל: להקטין את נטישת הלקוחות מX% ל-Y%, להגדיל את המכירות ב30%, לחסוך עלויות בסך 500K ש”ח.
בחלק זה תוכלו להתייחס גם ל- Problem Statement: מה הבעיה שאתם מנסים לפתור, ל- Business case: מה ההצדקה העסקית לפרויקט, ומה הסיכונים שצריך לקחת בחשבון במסגרת הפרויקט.
עכשיו שברור לכם מה הבעיה שאתם מנסים לפתור, מהי המטרה והתוצר הסופי של הפרויקט, ואיך אתם מודדים את הצלחת הפרויקט, בואו נעבור לרשימת כל השותפים לפרויקט ונגדיר את החלק של כל אחד מהם.
חלק ב: הגדירו את חלוקת התפקידים והאחריות באמצעות מודל RACI
ניהול פרויקטים הוא עבודה מטריציונית בהגדרה. כלומר, על מנת שהפרויקט יצא לפועל, אתם זקוקים לשיתוף הפעולה של אנשים נוספים בארגון. לרוב, האנשים האלה שקועים ביום-יום שלהם, ולא תמיד יש להם פניות עבורכם ועבור הפרויקט שאתם מובילים, ואז עשויים להתעורר מאוחר יותר ולהתרעם למה לא עורבו מלכתחילה. לחילופין, לפעמים הפרויקט שלכם יכול להיתקע במידה ואין שיתוף פעולה של אנשים מסוימים. רוצים למנוע מצב כזה? השתמשו במודל RACI, המסייע בחלוקת עבודה בין כל שותפי הפרויקט, באופן הבא:
ה-R הוא הResponsible: מי עושה את המשימה? מי האחראי לביצוע בתכלס?
ה-A הוא הAccountable: מי האחראי – מי ישא בתוצאות אם משהו ישתבש? למי יש את הסמכות לקבל החלטות?
ה-C הוא ה Consulted: מי יכול להרחיב עוד לגבי המשימה? למי יש ידע לשתף או לתרום להצלחה של המשימה?
ה-I הוא ה Informed: יש מישהו שתלוי במשימה הזו? מישהו שצריך להמשיך להתעדכן על ההתקדמות של המשימה?
בנו מטריצה שכוללת את משימות הפרויקט ואת שמות העובדים, והתאימו את אותיות הRACI בהתאמה. דוגמא למטריצה בקובץ המצורף בתגובה הראשונה.
מה החשיבות של מודל RACI, ומה החידוש פה בעצם? אחת הבעיות בעברית היא שהמילים responsible ו-accountable הם “להיות אחראי”, אבל באנגלית, וזה החידוש, ה-accountable הוא נותן דין וחשבון – ולמעשה יש לו את הסמכות להחליט (go / no go) וה-responsible הוא המבצע בפועל של המשימה. לפעמים מדובר באותו אדם, אבל הרבה פעמים מדובר באנשים שונים. ההברהרה מי הוא הR ומי ה-A, עושה הרבה פעמים סדר ותאפשר לכם לרוץ מהר יותר בצמתי קבלת ההחלטות.
שני דברים שכדאי לשים לב אליהם- אם על משימה אחת יש יותר מדי אנשים שהם A – המשמעות היא שיש עודף מנהלים, וזה יכול לעכב אתכם. יש משימה בלי R שהוקצה אליה? אף אחד לא יעשה את העבודה.
מתי כדאי להשתמש במטריצה? בפרויקטים שבהם מעורבים אנשים ממחלקות שונות, בפרויקטים גדולים עם הרבה משתתפים, או בפרויקטים שלא הכי ברור מה התפקיד של כל אחד ממשתתפי הפרויקט.
לקריאה נוספת על מודל הRACI, לחצו כאן.
חלק ג: בנו לוח זמנים לפרויקט
לאחר שהגדרתם את כל המשימות והתאמתם את הR/A/C/I לכל משימה, עברו לשלב הבא של יצירת לוח זמנים לפרויקט. הגדירו עבור כל משימה את לוח הזמנים שלה. דאגו שלוח הזמנים יהיה בעל ויזאביליות גבוהה ככל הניתן על מנת לייצר ראיה הוליסטית של כל חלקי הפרויקט. דוגמא ללוח זמנים בקובץ האקסל.
חלק ד: קבעו את ה-Governance
ה-governance אלו בעצם הנהלים או החוקים במסגרתם יעבור הפרויקט. ה-governance יסייע לכם ביצירת שקיפות, בעדכונים שוטפים, של קצב התקדמות הפרויקט מול כל השותפים הרלוונטים. אז מה זה בעצם אומר?
קבעו אלו פגישות אמורות להתקיים כדי להוציא את הפרויקט לפועל. מהי תדירות כל פגישה ומהם הפרטים שיעלו בפגישה. הגדירו מי מוביל את הפגישה (מי מתאם את הפגישה וקובע את האג’נדה), מי הם המשתתפים, ובעיקר מה הם הoutputs וה-inputs שאמורים לצאת מהפגישה.
למשל, פגישה חודשית, בהובלת סמנכ”ל המכירות, משתתפים בה המנכ”ל, סמנכ”ל השירות והמכירות, ראש צוות ואיש פרודקט. פרטי הפגישה: מעבר על סטטוס הפרויקט, חסמים ועוד. דוגמא נוספת: פגישה שבועית של ראש הצוות ואיש הפרודקט. פרטי הפגישה: בניית הפייפליין, אפיון שלבי המכירה והטמעתם במוצר.
ה-Inputs, אילו נתונים, מסקנות, שאלות נדון בפגישה, למשל: מה הסטטוס, האם עומדים בלוח הזמנים, האם יש איזשהם חסמים לגבי הפרויקט, האם יש משהו נוסף לקחת בחשבון
ה- Outputs, מהי התוצאה של הפגישה? למשל: עדכון כל ה stakeholders בסטטוס, פיתרון של בעיות שעולות וכו’
חלק ה: נהלו מעקב אחרי כל החסמים וה-dependencies.
ייצרו שקיפות לגבי כל החסמים, והעלו אותם בפגישות, קבעו פגישות המשך עם מקבלי ההחלטות על מנת לפתור את החסמים שעולים.
טיפ חשוב: התחלתם פרויקט חדש? קיימו ישיבת Kickoff לפרויקט. הזמינו את כל האנשים הרלוונטים. לפעמים עדיף שמישהו בכיר יזמן את הישיבה כדי לוודא הגעה של כולם. בישיבה הציגו את הפרויקט, מטרותיו (וכל מה שמתואר בסעיף א’), לאחר מכן עברו על רשימת המשימות וה-R/A/C/I שהקצתם לכל משימה, נצלו את הישיבה כדי לדון בכך, לעיתים תגלו שהגדרתם לא מדויק ושנכון לשנות את האנשים המוקצים למשימות או לRACI. הציגו את לוח הזמנים ואת ה-govencance. וודאו שכולם מסונכרנים ומפנים זמן בלוז לישיבות שהגדרתם ב-governance. לאחר הישיבה שלחו לכולם את קובץ הפרויקט ואת הזימונים לישיבות. צאו לדרך 🙂
לקבלת קובץ מאסטר חינם לניהול הפרויקטים שלכם לפי המתואר לעיל, לחצו כאן
עוסקים בתחום האופרציה? אתם אחראים על שיפור תהליכים, הטמעת מערכות, בניית אסטרטגיות, ניהול פרויקטים חוצי חברה? מוזמנים להצטרף לקבוצה: Operation Leaders
פריימוורקס מוצלחים שיצא לי לעבוד איתם – RACI, OKRs והרבה אלמנטים שלמדתי בהכשרה של ITIL.. אחד הדברים שתמיד מפתיעים אותי זה גמה קשה להטמיע כלים כאלה באופן מלא בארגון, ותמיד יוצא שמאמצים חלק ואז לא נהנים מהערך הכולל – אבל זה כבר לדיון אחר ?