OK יועצים לניהול

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

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

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

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

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

להלן דוגמה:

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

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

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

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

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

למשל: מחזור תהליך פיתוח מוצר, מחולק לקוביות כדלהלן, כאשר החיצים הם התוצרים שעוברים משלב לשלב:

ציור 1 – מחזור חיי פיתוח מוצר

נראה פשוט? לא ממש

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

כיצד בכל זאת, נטמיע תהליך שיטתי ?

אחד האמצעים לתאר תהליך פיתוח מוצר מקצה לקצה הוא תהליך כולל הנקרא "ניהול מחזור חיי פיתוח מוצר" – Product Life Cycle Management (PLCM), הכולל את הרכיבים הבאים:

1. שלבי הפיתוח – "הקוביות"
2. תוצרים – תפוקות ו/או תשומות של שלבי הפיתוח – "החיצים"
3. בעלי עניין – זיהוי בעלי העניין בכל תהליך בפרויקט – מי אחראי ליצירת התוצרים, מי מאשר, מי אמור להיות מושפע ומי אמור להיות מיודע.

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

תיעוד כולל של תהליך ניהול פיתוח מוצר מורכב מהאלמנטים הבאים: 

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

​      לכל שלב, מתוארים הפרטים הבאים:

• שם ותיאור התהליך;
• הפונקציה האחראית לפתח את התוצר;
• תוצר התהליך;
• פונקציה האחראית לאשר את התוצר. בדרך כלל תהיה זו הפונקציה שתשתמש בתוצר.

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

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

למי התהליך מתאים ?

התהליך מתאים לחברות אשר להן לפחות אחד מהמאפיינים הבאים:

1. חברות המפתחות מוצרים, אשר בפיתוחם מעורבים גורמים רבים – שיווק, ניהול מוצר, מכירות, כספים, תפעול, פיתוח, תמיכה, שירות, איכות, ניהול פרויקטים,ייצור, רכש ועוד.
2. חברות בינלאומיות הפועלות במספר אתרים בעולם.

בחברות אלה, תהליך ניהול המוצר הופך להיות השפה המשותפת, באמצעותה מנהלים ומתאמים התחייבויות פנימיות ומספקים תוצרים ותוצרי ביניים.

דוגמאות לחברות המשתמשות בניהול מחזור חיים כולל: מוטורולה, מלנוקס, נייס, קומברס ואחרות.

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

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

מדוע חשוב להגדיר הצלחה של פרויקטים?

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

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

מה זה בעצם פרויקט מוצלח?

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

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

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

OK, מה למדוד?

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

מדידת לו"ז, תכולה ותקציב

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

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

תכנון הלו"ז –מושפע מצורכי הלקוחות, או הארגון מבחינת Time-to-Market; קשה יותר להצליח בפרויקט עם לו"ז צפוף.

הצלחה בשלושת המדדים הקלסיים היא קריטית. בדרך כלל, חריגה במדד אחד, גוררת גם חריגה בשאר המדדים, כתוצאה ממאמץ לחזור למסלול. מאמץ זה דינו – הזזת לו"ז, או חריגה בתקציב, או שינוי תכולה, או שילוב של גורמים אלה.

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

מדידת שביעות רצון הלקוחות

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

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

מדידה נוספת עקיפה של שביעות רצון הלקוח, היא מדידת הנכונות להמלצה. שואלים את הלקוח עד כמה יהיה מוכן להמליץ על הארגון ללקוחות נוספים בסקלה שבין 0 ל-10. ציון 9-10 נחשב ללקוח מרוצה, 7-8 נחשב ללקוח פסיבי, אדיש; כל ציון אחר נחשב כלקוח לא מרוצה.

מדידת ביצועי תוצר הפרויקט

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

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

מדידת החזר על השקעה – Return On Investment – ROI

מדידת עמידת הפרויקט בתהליכי העבודה שהוגדרו לו

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

בקרה רציפה, ולא רק בסוף הפרויקט

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

תאום ציפיות

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

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

"המקור היחיד לידע הוא הניסיון." – אלברט איינשטיין

 איך אנו מממשים מטרות בארגון (ולפעמים גם בחיים האישיים)? – באמצעות פרויקטים!

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

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

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

האם עלינו לחכות שמנהלי הפרויקטים יחכימו דרך הרגליים? האם יש דרך ללמוד מניסיון של אחרים? אחרים במשמעות הכי רחבה, גם מחוץ לארגון שלנו? מחוץ למדינה שלנו? ….. הבשורה המשמחת היא שיש דרך ללמוד מניסיון של אחרים, והיא להשתמש במודלים הידועים כ-Best Practicesבעולם. לנושא ניהול פרויקטים ישנם מספר מודלים: למשל  PMBOK¹, CMMI² ואחרים. יתרון השימוש במודלים הוא בכך שהמודל מדריך מה צריך לעשות במובן של פרקטיקות מעשיות. פרקטיקות אלה הן תוצאה של אלפי שנות ניסיון מצטבר בארגונים ברחבי העולם, במהלך 20-30 השנים האחרונות. מודלים אלה אף מתעדכנים לעיתים קרובות כדי להתאים את הפרקטיקות למציאות המשתנה.

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

תחומי התהליך המרכזיים בתחום ניהול הפרויקטים, בהם מתמקד מודל ה-CMMI:

• תכנון פרויקטים    Project Planning
• בקרת פרויקטים    Project Monitoring and Control
• ניהול הסכמי ספקים   Supplier Agreement Management
• ניהול סיכונים   Risk Management 
• ניהול דרישות       Requirements Management
• ניהול פרויקטים כמותי    Quantitative Project Management
• ניהול משולב (של פרויקט   Integrated Project Management (

תחומי התהליך – תכנון וניהול סיכונים פורטו בניוזלטר הקודם. ניוזלטר זה מתמקד בנושאים הבאים:

• בקרת פרויקטים – תכננתם היטב את הפרויקט שלכם; יצאתם לדרך בשעה טובה. כיצד אתם מוודאים שאתם אכן במסלול ומתקדמים בהתאם לתוכנית? אולי יותר נכון לשאול – כיצד אתם מוודאים כל הזמן שתובילו את הפרויקט לסיומו המוצלח, לשביעות רצון הלקוחות ושאר בעלי העניין?פרקטיקות מפורטות לבקרת פרויקטים במאמר – איזה ציון בין 1 ל-10 אתם, מנהלי הפרויקטים, נותנים לעצמכם בנושא בקרה ושליטה על ניהול הפרויקט למול תכנון הפרויקט?
• ניהול הסכמי ספקים – קבעתם הסכם עם ספק לביצוע חלק מהעבודה בפרויקט, ועם סיום עבודתו גיליתם פערים גדולים בין מה שרציתם וקיבלתם? נדרשתם לעשות שינויים בתכולת העבודה שנסגרה מול הספק ומצאתם את עצמכם "שבויים" בידי הספק? או להיפך: עשיתם הסכם עם ספק שגרם לספק להיות מאד לא מרוצה מהעבודה איתכם בגלל תקשורת לקויה, או בגלל שהפסיד כסף? גיליתם מאוחר מידי שהתוצרים שאתם עומדים לקבל אינם באיכות שתכננתם, או שעומד להיות פיגור גדול במסירת תוצרים מהספק שעלול לגרום לפיגור בפרויקט כולו?תשובות לשאלות אלה ואחרות במאמר –  איך נבטיח שתהליך ניהול רכש מוצרים ושירותים יהיה חוליה חזקה ולא חלשה ?
• ניהול דרישות – מי יודע מהו הנושא המככב בכל תחקיר על פרויקט שנכשל?……מי שניחש שהנושא קשור לניהול ופיתוח דרישות – צדק! זהו כמובן לא הנושא היחיד, אך בהחלט נושא שחוזר בתדירות גבוהה. מסתבר שלהבין את דרישות הלקוחות, ולנהל אותן במהלך מחזור הפיתוח זהו נושא סבוך וקשה; כיצד להתמודד עם האתגר, קראו במאמר – האם אתם מנהלים את דרישות הפרויקט שלכם, או שהדרישות מנהלות אתכם?

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

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

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

"אם אתה רוצה שאלוהים יצחק – ספר לו על התוכניות שלך" וודי אלן

סיכום: בקרת הפרויקט היא הרבה מעבר למעקב אחר ניהול לו"ז, תכולה ותקציב

פעילויות 1-7 שלעיל מטרתן לזהות סטיות בהתקדמות הפרויקט למול התכנון שלו; פעילויות 8-10 מטרתן לנתח את הנתונים שנאספו, ובמידה שהפרויקט סוטה מהמסלול המתוכנן – להחזירו למסלול.

האיור שלהלן, מסכם את עשרת הפרקטיקות, בשפת מודל ה-CMMI:

ביום 25.2.2013 התבשרנו על שיגור מוצלח של טיל החץ-3 לחלל. קטונתי מלהכיר את פרטי הפרויקט. עיני צדה משפט שאמר יאיר רמתי, ראש מנהלת חומה במשרד הביטחון (מפא"ת): "זה היה ניסוי טיסה חופשי. לראות אותו ממריא, נוסק, נכנס לחלל, מבצע שם פליק פלאק ותרגילים, שוהה שם כמה דקות, עושה כל מה שנדרש לעשות. התהליכים היו מרשימים והאמריקנים נשארו פעורי פה. זה די חריג שבניסוי ראשון כל הדברים הצליחו". (פורסם ב-YNET באותו יום).

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

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

• הטלפון הנייד משמיע צלצול בשנייה שהישיבה אמורה להתחיל ומעברו השני של הקו אומר המשתתף הפוטנציאלי: "אני אאחר בכמה דקות, תתחילו בלעדיי";
• משתתף אחר, מגיע בזמן לחדר, תופס כיסא, פורש את חפציו על השולחן ו…נעלם (הולך להכין קפה, לענות לטלפון, וכדומה) – העיקר שהוא "הגיע" בזמן;
• מספר משתתפים נכנסים באיחור, ומנהל הישיבה עוצר את הישיבה השוטפת ומעדכן אותם בנעשה עד לרגע כניסתם;
• חלק מהמשתתפים מדברים בו-זמנית, קוטעים זה או זה, ומעלים את קולם כדי שדברם ישמע; משתתפים אחרים יושבים בשקט וברוב ייאושם אפילו לא מנסים להשתלב בשיחה;
• משתתפים מסוימים גולשים בנייד, מסמסים או עושים עבודה נוספת במקביל לישיבה;
• מנהל בכיר שולף מהישיבה מישהו כדי לענות על שאלה שאינה סובלת דיחוי;
• חלק מהנוכחים מגיעים בזמן, אך הישיבה לא מתחילה כי מחכים לשאר המשתתפים;
• אף אחד לא מגיע בזמן כי  ידוע שזמן התחלת הישיבה הוא המלצה בלבד;
• מנהלים שאומרים באנחה מידי פעם: "היום לא עבדתי; רק הייתי בישיבות", או שמחמיצים פנים כאשר עליהם להשתתף בישיבה, ולעצור את העבודה החשובה שהם עושים באותו הרגע.

…ועוד כהנה וכהנה מקרים שהופכים את הישיבה לבלתי יעילה, ואת מנהל הישיבה למתוסכל וכועס; לעיתים תידרש ישיבה נוספת כדי להשלים את מטרות הישיבה.

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

ניהול רזה הוא גישה ניהולית שמטרתה להפחית בזבוזים. המאמר שלהלן רלוונטי לסוגים שונים ומגוונים של ישיבות.

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

להלן 10 כללי אצבע לניהול יעיל של ישיבות:

1) פרסמו מראש סדר יום לישיבה

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

2) התחילו בזמן

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

3) קבעו מספר חוקים לאופן ניהול הישיבה

לדוגמה: לסגור טלפונים ומחשבים ניידים; רק אחד מדבר בו זמנית, וכדומה.

4) היצמדו לסדר היום שקבעתם

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

5) רשמו בצד נושאים שלא קשורים לישיבה

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

6) קבעו אחראים  לביצוע משימות, כולל תאריך נדרש לסגירה

7) סיימו בזמן

סכמו בקצרה את הישיבה, תאמו ציפיות ומטלות למפגש הבא, והודו למשתתפים על תרומתם לפגישה.

8) פרסמו סיכום, קרוב ככל האפשר לסיום הפגישה

סיכום הדיון צריך להיות גם קצר ותמציתי. פעולות, אחראים לו"ז כדוגמת to do list; כללו בסיכום התייחסות למטרת הישיבה, והאם היא השיגה את מטרתה.

9) הגדירו מוביל לישיבה

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

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

10)  בדקו תקופתית את יעילות תהליך הישיבות

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

ניהול רזה של ישיבות – האומנם?

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

אם עניתם על חלק מהשאלות בשלילה, הפשילו שרוולים וטפלו בתהליך ניהול הישיבות.

האם חידשתי לכם משהו? מה ניסיונכם בנושא זה? אשמח לתגובות באחת הרשתות החברתיות שלהלן. תודה מראש.

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

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

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

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

מיפוי בעלי העניין

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

ניתוח בעלי עניין

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

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

אבטרטגיית התקשורת מול בעלי העניין

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

1. רמת עניין גבוהה עם יכולת השפעה חזקה – ניהול צמוד – קבוצה זאת מכילה אנשים להם יש עניין בפרויקט וגם יכולת השפעה גבוהה. למשל: מנהלים בכירים. ננהל עימם תקשורת צמודה ונעדכן אותם על התקדמות והתפתחות פרויקט השינוי באופן סדיר.
2. רמת עניין גבוהה עם יכולת השפעה נמוכה – עדכון שוטף  – קבוצה זאת כוללת אנשים אשר להם רמת עניין גבוהה בפרויקט, אך מידת סמכותם ויכולת ההשפעה שלהם נמוכה. למשל: עובדים הנמצאים בצוותים המתממשקים לצוות הפרויקט –  ניידע אותם על ההתקדמות.
3. רמת עניין נמוכה עם יכולת השפעה חזקה  – שמירה על שביעות רצון גבוהה – קבוצה זאת מכילה מנהלים בכירים אשר לא מעורבים בפרויקט. למשל: מנכ"ל ו/או סמנכ"ל אשר לא מעורבים באופן שוטף בפרויקט. יש להם עניין שהפרויקט יצליח כמו כל פרויקט אחר. הם לא מתעניינים בפעילות השוטפת. במקרה כזה, על מנהל הפרויקט לשמור שהפרויקט יהיה "מיושר" עם מטרות החברה כפי שבעלי העניין רואים אותם.
4. רמת עניין נמוכה עם יכולת השפעה נמוכה  – בקרה – קבוצה זאת מכילה אנשים שהשפעתם נמוכה וגם מידת העניין שלהם נמוכה. למשל: מנהלים של פרויקטים אחרים. נפקח עין על קבוצה זאת ונפעל בהתאם להתפתחויות ולצורך.

תכנון התקשורת בפרויקט

לאחר שזוהו בעלי העניין בפרויקט, ונעשה מיפוי לגבי מידת העניין וההשפעה שלהם, יש לתכנן את מידת השיתוף שלהם במידע של הפרויקט. מידע הפרויקט כולל השתתפות בפגישות ,Kickoff הפצת מסמכים, דוחות ביצועיים, סיכומי ישיבות, התרעות על חריגות וסיכונים. תכנון התקשורת בפרויקט הינו חלק מתכנון הפרויקט (Project Management Plan).

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

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

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

מהן חמש הטעויות הנפוצות בניהול התקשורת בפרויקט?

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

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

טעות מספר שתיים – חוסר תכנון התקשורת בפרויקט

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

טעות מספר שלוש – הפצת מידע לבעלי עניין שלא בהתאם לתוכנית

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

טעות מספר ארבע – ניהול לא מיטבי של ציפיות בעלי העניין בפרויקט במהלך הפרויקט

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

טעות מספר חמש – אי דיווח או דיווח חלקי לגבי התקדמות הפרויקט

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

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

מה דעתכם ? חושבים ששכחתי משהו ? אשמח שתחלקו עם הקוראים האחרים את התובנות והמחשבות שלכם באחת הרשתות החברתיות שקישורן להלן. תודה

המאמר פורסם בגיליון יוני 2014 של Information World

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

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

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

מאמר זה מציע טכניקה שונה לביצוע התהליך, Pre-Mortem, לפני שהחולה/הפרויקט מת, כדי לזהות כשלים לפני שהם קורים. טכניקה זו פורסמה לראשונה על ידי גרי קליין (Gary Klien) ופורסמה בשנת 2007 ב- Harvard Business Review במאמר בשם "Performing a Project Pre-mortem".

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

בנוסף, תהליך הpre-mortem מתגבר על הקשיים הבאים, הקורים בתהליך post-mortem:

• בפוסט מורטם חברי הצוות מנסים להגיע לקונצנזוס, ולא לפגוע, ובכך הולך לאיבוד מידע חשוב. במקום זאת, בתהליך של פרה-מורטם חברי הצוות מחפשים את האילוצים שמונעים זרימה חלקה של ניהול הפרויקט.
• בפוסט מורטם, יש אנשים שחוששים להצביע על אחרים כאחראים לאי-הצלחה. בפרה-מורטם יותר קל להעלות חששות בתחום אחריות של חבר צוות אחר.
• תהליך הפרה-מורטם הוא תהליך עם עלות נמוכה, כיוון שהוא תהליך של מניעה. לעומת פוסט-מורטם שדן באירועים (נזקים) שכבר התרחשו.

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

תיאור פגישת Pre-Mortem

מתבצעות הפעולות הבאות:

1. הכנה –חברי הצוות מתכנסים, לאחר שקראו את תכנון הפרויקט, או שתכנון הפרויקט מוצג בפניהם; על מנת למקד את סיעור המוחות, ולמנוע מצב של "מטרות נעות ומשתנות", הצוות מסכם מהם יעדי הפרויקט, שאי השגתם מהווה סיכון:
   •  יעדי לו"ז, תכולה או תקציב הפרויקט  אשר אי השגתם מהווה סיכון לפרויקט
   • יעדי איכות המוצר או רמת הביצועים שלו אשר אי השגתם מהווה סיכון למוצר
   • יעדי ביצועים פיננסיים, מוניטין וכדומה  אשר אי השגתם מהווה סיכון עסקי לארגון המפתח את המוצר
2. "מסע בזמן" – המשתתפים מתבקשים לדמיין שבידם כדור בדולח בו ניתן לראות את העתיד. כרגע הם בישיבת Post-Mortem  בסוף הפרויקט. חברי הצוות מתבקשים לחשוב מה יגידו בישיבת פוסט-מורטם של הפרויקט שלהם. כל אחד מהמשתתפים רושם על מדבקות צהובות את הסיבות שלדעתו "גרמו" לכשלים או הצלחות. המקור לסיבות לכשלים של כל אחד הוא חששות מכל נושא אפשרי בפרויקט, ולא רק הנושאים שבתחום אחריותו. במידת האפשר, מתארים על ציר הזמן של הפרויקט – מתי קרו האירועים.
3. הכנת רשימת סיבות לכישלון או הצלחה – כ"א מהמשתתפים רושם את הסיבות לכישלון, לדעתו. כאן באה לידי ביטוי האינטואיציה של כל אחד מחברי הצוות. כל חבר צוות מדמיין אירועים אחרים.
4. איחוד הרשימות האישיות לרשימה כוללת של כל הסיכונים בפרויקט. מוביל סיעור המוחות מסתובב בין שולחנות המשתתפים, מבקש מכל אחד מהמשתתפים, להצהיר בכל רם על סיבה אחת לכישלון או הצלחה; הסיבות נרשמות על הלוח, או שמדביקים את המדבקות הצהובות. עוברים בתור במספר סיבובים – כל משתתף בתורו מצביע על סיבה אחרת לכישלון. בסוף התהליך, יש רשימה מקיפה של סיבות וחששות לפרויקט. מקבצים את הסיבות לקטגוריות, על ידי הזזת המדבקות וקיבוצן לפי קטגוריות.
5. דיון – בוחרים 2-3 סיבות שזוהו כגורמות לכישלון גדול. מגדירים במשותף מהו החשש בדיוק, ומה ניתן לעשות כדי לשכך את עוצמתו, או למנוע את היווצרותו.
6. תודה – מודים למשתתפים ומתפזרים.

הערה : ניתן לעשות גם Pre-Mortem  לפני כל שלב בפרויקט ובאותה צורה להתמקד בחשיבה על גורמים להצלחה או אי הצלחה בשלב שעומד לפניהם.

לאחר פגישת Pre-Mortem 

מתבצעות הפעולות הבאות:

1. סיכום פגישה – מנחה הדיון מסכם את כל הנושאים שעלו בדיון.
2. הכנת רשימת סיכונים – מנהל הפרויקט עובר על רשימת החששות שעלו ב-Pre-Mortem  ומתרגם אותם לסיכונים. הסיכונים מוכנסים לטבלת מעקב. כל סיכון עובר ניתוח (הסתברות? השפעה?); הרשימה כולה עוברת תהליך של תיעדוף, כדי לטפל באותם הסיכונים שיכולים לגרום לנזק מרבי לפרויקט. נעזרים גם בזמני התרחשות האירועים כפי שזוהו  ב-pre-mortem.
3. ניהול סיכונים – טבלת הסיכונים מנוהלת כחלק מתהליך הבקרה של הפרויקט.
4. חזרתיות – תקופתית חוזרים על תהליך ה-Post Mortem כדי לזהות סיכונים נוספים.

מה בין pre-mortem לניהול סיכונים?

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

תהליך ניהול סיכונים מורכב מהשלבים הבאים:

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

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