בשיחה עם מהנדס חברה קבלנית גדולה, הוא אמר: "אנחנו לא משתמשים בלו"ז כתוכנית עבודה".
"מה? למה?" עניתי מופתעת, "הרי יש לכם המון פרויקטים ולכל פרויקט יש לוח זמנים! אז איך מצב כזה יכול להיות – שלוח הזמנים הוא לא תוכנית עבודה?!"
"איך אפשר לגרום ללו"ז (לוח זמנים) להיות תכנית עבודה?" הוא שאל. "אם תתני לנו את התשובה לזה, תעזרי מאד!"
רגע לפני שניגש לשאלה הזו, תחילה אנחנו צריכים לשאול את עצמנו שאלה אחרת:
אם לוח זמנים אינו תוכנית עבודה – בשביל מה בכלל צריך לוח זמנים? ובמלים אחרות – מה ה'בעד' וה'נגד' לבניית לוח זמנים?
מהו לוח זמנים?
לוח זמנים טוב מגדיר את כל הפעילויות הנדרשות לביצוע ולכל פעילות את משך זמן המוערך הנדרש לביצוע אותה הפעילות. בנוסף, מוגדרת בו גם לוגיקת הרשת – אילו פעילויות מקדימות לכל פעילות ואילו עוקבות לאותה הפעילות. לוח זמנים ממש טוב יכיל גם הגדרת משאבים נדרשים לכל פעילות ולפעמים גם מה העלות שנשקיע בכל פעילות.
למה לא לבנות לוח זמנים?
בניית לוח זמנים טוב צורכת הרבה זמן – זמן עבודה, זמן חשיבה, זמן תכנון, זמן בו שואלים שאלות (מה אפשר לעשות אחרי? מה צריך לסיים לפני…?) וזמן רב שבו נדרש למצוא את התשובות ולהגדיר אותן בגאנט (לוח הזמנים). וזמן, כידוע, הוא משאב יקר.
בניית לוח זמנים לא צורכת רק זמן – כדי לבנות את לוח הזמנים בפרויקט צריך תוכנות לניהול פרויקטים או ניהול לוחות זמנים. לפרויקטי "מפל" נדרשת תוכנה כמו Project, Primavera, Tilos או ASTA ולפרויקטי Agile נדרשת תוכנה כמו Monday, ClickUp, Trello ואולי תעדיפו תוכנה אחרת?
לתוכנה תהיה עלות, וגם תדרש מיומנות להפעלת התוכנה – שאותה נרכוש דרך קורס (כלומר, נשקיע זמן וכסף) או שנקח מומחה ונעבוד אתו – כלומר, נוסיף הוצאה כספית.
לוח זמנים חושף את מצב הפרויקט. פשוטו כמשמעו. לוח הזמנים יכול לומר שהפרויקט נמצא באיחור או מקדים את זמנו, לוח הזמנים יכול להעיד שהפרויקט מאד מורכב וקשה לביצוע עם הרבה סיכונים נחבאים בתוכו (ולספר מה הם…), לוח הזמנים מספר לכל מי שרואה אותו מה דרך העבודה המתוכננת ומה הקשיים. במלים אחרות, כשיש לוח זמנים – קצת קשה "לשמור סודות" בפרויקט.
הפסקה הקודמת מאד נכונה – למי שיודע לקרוא לו"ז. אבל, ללוח הזמנים יש "שפה" משלו. השפה מורכבת מטבלאות ותצורה גרפית – שצריך ללמוד. למי שלא למד לקרוא את ה"לוזית" זה נראה מאד מסובך, בייחוד בלוחות זמנים עם מאות פעילויות.
אם יש כל-כך הרבה נגד בניית לוח זמנים – למה כן לבנות לוח זמנים?
בתהליך בניית לוח זמנים טוב אנחנו נדרשים להגדיר את הפעילויות לביצוע. עצם ההגדרה של הפעילויות יוצרת סדר – סדר בתהליכי העבודה הנדרשים בפרויקט, סדר בהבנת הפרויקט והלוגיקה שלו – ומה חשוב יותר בפרויקט ומה פחות חשוב.
עצם בניית לוח הזמנים גורמת לנו לחשוב על הפרויקט. אם הגדרנו שאנחנו רוצים "לבנות משהו" – כשאנחנו באים לכתוב את לוח הזמנים אנחנו צריכים לחשוב על ה'איך'. איך אנחנו רוצים לבנות את אותו ה- משהו. שינוי השאלה מ'מה אנחנו רוצים לבנות' ל'איך' גורמת לנו לחשיבה נוספת ומאד עמוקה על הפרויקט שלנו.
לוח הזמנים משקף את הפרויקט: הלו"ז משקף את מבנה הפרויקט – אולי הפרויקט שלנו מורכב ממספר פרויקטים? – והוא משקף את התהליכים הנדרשים בפרויקט – אולי אנחנו צריכים לפעול במספר תחומים בעת ובעונה אחת? למשל, נצטרך לבנות מספר תוכנות ולחברן לאחת, או להתחיל בנייה בו זמנים על מספר נציבים של הגשר.
הלו"ז יאפשר לנו לאתר חסמים בפרויקט – למשל, המתנה לקבלת אישורים מיוחדים מגורמים שונים שעד שלא נקבל אותם – לא נוכל להמשיך לעבוד, או ביצוע פעילויות על-ידי מומחה יחיד או מכונה מיוחדת לא יכולות להתבצע במקביל, אלא רק בטור. ישנם נושאים שכשנראה אותם נאמר – "ידענו את זה, זה היה ברור!". עם זאת, ישנם לא מעט נושאים, שמאד מפתיעים אותנו, כשאנחנו מגלים אותם בלוח הזמנים ואת החשיבות והקושי שהם יוצרים.
כשיש לוח זמנים מעודכן – ניתן לדעת בכל רגע מה קורה בפרויקט – אילו פעילויות צריך לבצע היום, אילו פעילויות היו צריכות להתחיל, אילו היו צריכות להסתיים ו… מה התאריך שבו אנחנו צפויים לסיים את הפרויקט!
לוח זמנים אשר נשלח לכל הגורמים המעורבים בפרויקט יוצר בסיס לדיבור בין משתתפי הפרויקט. הוא מאפשר "ליישר קו" ולוודא שכולם מסונכרנים – גם בסדר הפעילויות שיש לבצע וגם מתי מתבצעת כל פעילות.
אם הפרויקט מסתיים אבל לא מצליחים להסכים על מספר אחד (בכסף) המסכם אותו לשביעות רצון כל המשתתפים, אזי ללוח הזמנים נוסף תפקיד מפתח, שנים לאחר שהפרויקט מסתיים – בתביעות. ללוח הזמנים הבסיסי, ולעדכוני לוחות הזמנים מהראשון ועד האחרון יהיה תפקיד מפתח בתביעה על בסיס לוחות זמנים.
ואם נסכם את השאלה בטבלה, היא תראה כך:
אם נחליט, שהיתרונות של בניית לוח זמנים עולים על החסרונות של בניית לוח זמנים, נעבור לשאלה הראשונה כדי להפוך לוח זמנים לתוכנית עבודה:
מה הדבר הראשון שצריך, כדי שלו"ז יהיה תוכנית עבודה?
התשובה מדהימה בפשטותה: הלו"ז צריך להיות אמיתי.
למה אני מתכוונת?
הלו"ז צריך להיות לוח זמנים שאנחנו מאמינים בו. לוח זמנים שאנחנו מתכוונים לקיים. משכי הפעילויות צריכים להיות משכי זמן סבירים לביצוע. סדר הפעילויות צריך להיות זה שאנו מתכננים לבצע את הפרויקט על-פיו. אם כתוב משהו בלוח הזמנים שאנחנו לא מאמינים בו – הוא לא יהפוך לתוכנית עבודה.
כשהלו"ז אמיתי, מה הוא צריך להיות עכשיו?
לוח זמנים תקין.
למה? כי המציאות אינה סובלת את מה שהתוכנה מקבלת כמובן מאליו.
במלים אחרות – בתוכנה אנחנו יכולים לכתוב וליצור מה שאנחנו רוצים. נקודת המוצא של התוכנה: אתם, בני האדם, יודעים מה אתם רוצים – ואם זה מה שכתבתם – כנראה לזה התכוונתם.
לעומת התוכנה – המציאות אינה ותרנית. אם משהו לא יכול לקרות – הוא לא יקרה.
כל התקלות בלוח הזמנים – הן מצבים אשר יכולים ליצור בעיה במציאות או לא יכולים להתקיים במציאות.
איך נוכל לדעת האם הלו"ז שלנו תקין, או שיש בו תקלות?
בעזרת מיפוי כל התקלות הקיימות בלוח זמנים ב- HCP-Go.
HCP-Go מאתר את כל התקלות בגאנט (לוח הזמנים).
יש תקלות שאפשר לבצע פעילויות ידניות ולמצוא. למשל, האם יש פעילויות בלוחות הזמנים שאין להן פעילויות עוקבות? אבל יש דברים שאפשר לאתר רק כשמחפשים נתיבים, למשל, פעילות עוקבת המקדימה את הפעילויות המקדימות שלה…
ה- HCP-Go לא רק מאתר אם קיימות תקלות, הוא גם ממפה אותן – ומתקבלת רשימת פעילויות שיש לתקן ומה יש לתקן. כך אפשר לטייב את לוח הזמנים ולהגיע לתוכנית עבודה שתואמת מציאות!
הסיבות לקיום התקלות יכולות להיות:
א. טעויות אנוש. ברור לגמרי שהן יקרו, בייחוד בלוחות זמנים עם מאות פעילויות. אותן גם בדרך כלל קל לתקן.
ב. סוג הטעויות השני הוא טעויות אשר נובעות מקושי כלשהוא. למשל, לא קישרנו פעילות, כי כשקישרנו – הפרויקט התאחר. אז מחקנו את הקשר ואמרנו שנחזור אליו אחר-כך ולא חזרנו. טעות.
על כל טעות שנמצאת יש לשאול – למה? למה כתבתם כך? למה חשבתם כך? התשובות המתקבלות לשאלות אלו מרתקות, וחושפות המון בעיות ומאפשרות להתמודד עם הבעיות מוקדם, כשהבעיות נמצאות רק על הנייר ועדיין לא מתרחשות במציאות. זה הזמן לטפל בהן ולמנוע את הקושי. לפעמים מנסים להתעלם מהתקלות הללו בפרויקט. אולי הן יעלמו לבד? ספוילר – זה אף פעם לא יקרה…
זוהי דוגמא לתוצאה שהתקבלה מניתוח HCP-Go על לוח זמנים מפרויקט אמיתי:
זו המטרה, אותה כדאי לקבל בסיום בדיקת HCP-Go:
עכשיו כאשר לוח הזמנים אמיתי ותקין – במה צריך להתמקד?
התשובה לשאלה הזו מתחלקת ל- 3 חלקים:
א. נתיבים קריטיים: הנתיב הקריטי – לפי CPM, הנתיב הקריטי – לפי HCP
ב. נתיבים קריטיים נסתרים.
ג. חתך פעילויות לביצוע השבוע / החודש
נתיבים קריטיים: הנתיב הקריטי – לפי CPM, הנתיב הקריטי – לפי HCP
הסבר קצר על שתי השיטות:
ה- CPM, בוחן כל פעילות – ובודק בעזרת חישוב קדמי וחישוב אחורי – כמה היא יכולה לזוז על ציר הזמן.
אלו שאין להן אפשרות לזוז מקבלות מרווח כולל =0 והן יוצרות את הנתיב הקריטי לפי CPM.
HCP ממפה את לוח הזמנים של הפרויקט לפי נתיבים ומוצא את הנתיבים בפרויקט – רצפי הפעילויות הקיימים.
המידע, המתקבל מניתוח הרצפים מרתק, והוא זה שמאפשר להפוך לו"ז-ית לעברית.
נדגים במיני-דוגמא הקודמת.
CPM יחשב את המרווח הכולל של כל פעילות – Total Slack ונקבל 5 מרווחים כוללים ל- 5 פעילויות.
HCP בעצם יאתר בדוגמא הקטנטנה הזו – 4 נתיבים.
איך ההבדל בין ה- CPM ל- HCP בא לידי ביטוי בלוח הזמנים?
נסתכל על דוגמא סכמתית של פרויקט.
- הפרויקט מתחיל ב- 01 בינואר ומסתיים ב- 22 בדצמבר. (שורה 1 ושורה 2)
- כל נתיב המתואר פה מורכב מהרבה פעילויות – יכול להיות מורכב מעשרות פעילויות. אני מזכירה – זהו תאור סכמתי.
- הנתיב הקריטי לפי CPM (שורה 3) מתחיל ב- 3 למרץ. למה הוא מתחיל במרץ ולא בינואר? אילוץ או השהיה. למשל, אי אפשר להתחיל לפני שמקבלים אישור מיוחד (כדוגמת היתר בניה), או, אי אפשר להתחיל לפני שמגיע מומחה לעבודה – המתפנה לעבודה זו רק במרץ, או כל אילוץ אחר – המציאות חזקה יותר מכל דמיון… מאותו הרגע שאילוץ זה משתחרר בתאריך 3/3, נדרשים 10 חודשי עבודה – והם אלו שמגדירים את סיום הפרויקט, מאחר והם מביאים לתאריך המאוחר ביותר בפרויקט.
- לכן, לפי CPM, לכל הפעילויות הנמצאות על הנתיב הזה אין אפשרות תזוזה בתאריכים והן עם מרווח כולל (Total Slack או Total Float) השווה לאפס TS=0. זהו הנתיב הקריטי לפי CPM בכל התוכנות הקיימות:
- בשיטת HCP נעשה מיפוי הנתיבים בפרויקט. במיפוי מתגלה כי יש נתיב שונה מהנתיב הקריטי לפי CPM, המתחיל ב- 1 לינואר ונמשך 11 חודשי עבודה (שורה 4).
- מאחר והוא הארוך ביותר ברשת כולה, מרווח ה-HCP שלו יהיה 0.
- נשים לב, הנתיב הזה יסתיים מוקדם יותר מהסיום המאוחר ביותר בפרויקט ולכן לפי CPM יהיה לו מרווח כולל בן 1.15 חודשים.
- עוד בשיטת HCP נמצא כי יש נתיב אחר, גם הוא שונה מהנתיב הקריטי לפי CPM וגם הוא ארוך יותר מהנתיב הקריטי לפי CPM – משכו של הנתיב 10.5 חודשים (שורה 5). נתיב זה אינו מתחיל בתאריך המוקדם ביותר בפרויקט, אלא כחודש לאחר תחילת הפרויקט ב- 29 לינואר, והסיום שלו מוקדם יותר מתאריך סיום הפרויקט.
- לכן, המרווח הכולל שלו (לפי CPM) יהיה 0.65 חודשים והמרווח שלו לפי HCP יהיה 10 ימים (=0.5 חודש).
באיזה נתיב מהשלושה צריכים מנהלי הפרויקט להתמקד? התשובה: בשלושתם
ניהול הפרויקט יהיה ניהול חלקי בלבד אם הוא יתמקד בנתיב אחד מהשלושה. מנהלי הפרויקט צריכים לדעת על שלוש הנתיבים ועל כל הפעילויות המרכיבות אותם ולנהל אותם באותה תשומת לב ניהולית!! בנקודה בה לא תהיה תשומת לב ניהולית – יהיו דחיות בפרויקט, אשר בתורן, יגרמו לדחיית הפרויקט כולו.
עצם הידיעה על שלושתם – זהו המפתח הראשון להצלחת הפרויקט.
לסיים פרויקטים בזמן – זה רק חלום או שאפשר להגשים במציאות?
שיחה בת 30 דקות, ללא עלות, עם טל לבנון.
קליק, פרטים ונחזור אליך. מבטיחים.
נתיבים קריטיים נסתרים
הנתיב הקריטי לפי HCP הוא הנתיב הארוך ביותר בפרויקט.
נתיב קריטי נסתר הינו נתיב הקצר מהנתיב הארוך ביותר. ההפרש בינם מגדיר את מרווח ה- HCP.
כלומר, כל הפעילויות המרכיבות את הנתיבים הקריטיים לפי HCP יקבלו את הערך 0 בעמודת "מרווח HCP".
כל הפעילויות המרכיבות את הנתיבים הקריטיים הנסתרים יקבלו בעמודת "מרווח HCP" את מרווח ה- HCP של הנתיב אותו הן מרכיבות.
בדוגמא הקודמת ראינו את הנתיב הקריטי הנסתר (שורה 5) עם 10 ימי מרווח, מאחר והוא קצר ב- 10 ימי מהנתיב הארוך ביותר ברשת, וכל הפעילויות המרכיבות אותו יקבלו את הערך 10 בעמודת "מרווח HCP".
חתך פעילויות לביצוע השבוע/החודש.
איתור הפעילויות לביצוע נעשה בעזרת מסנן של Project.
המסנן: טווח תאריכים
נמצא אותו בתפריט תצוגה -> מסנן -> טווח תאריכים…!
כשנלחץ עליו יפתח מסך ובו נכתוב את התאריך המוקדם ממנו נרצה להתחיל את החתך ולאחר מכן נלחץ על "אישור":
כשנלחץ עליו יפתח מסך ובו נכתוב את התאריך המוקדם ממנו נרצה להתחיל את החתך ולאחר מכן נלחץ על "אישור":
על המסך נקבל רק את הפעילויות שיש לבצע בין התאריך הראשון שבחרנו (למשל, תחילת השבוע או תחילת החודש), לתאריך השני שכתבנו (למשל, תאריך סוף השבוע או תאריך סוף החודש).
מה עוד צריך לדעת?
מבט כללי (1): מפת הסבירות לסיום הפרויקט בהצלחה.
הערכת מידת הצלחת הפרויקט – סבירות לעמידה בלוחות זמנים, בביצוע התכולה ובתקציב. הכל ממיפוי לוח הזמנים לפי נתיבים. איך קורה הקסם? פירוט אפשר לקרוא כאן, בסעיף 1.2.
בשורה התחתונה: מאד קל לקרוא את המפה ולומר מה קורה עם כל אחד מהפרויקטים. בכל רמה – אם אתם מנהלים זוטרים יותר או בכירים יותר, או אם אתם מחליטים על השקעה. השאלות הבאות שאתם צריכים לשאול, הן למה זה קורה? ומה אפשר לעשות ומה צריך לעשות עכשיו בפרויקט?
התגובה שאנחנו חוזרים ומקבלים ממנהלי פרויקטים היא: "ככה חשבתי על הפרויקט שלי – אבל לא יכולתי להוכיח את זה!"
מבט כללי (2): מיפוי נתיבי הפרויקט - היסטוגרמת הנתיבים.
במיפוי הנתיבים לפי HCP, מתקבלת היסטוגרמה. ציר ה- X הינו המרווח של כל נתיב ביחס לנתיב הארוך ביותר וציר ה- Y הינו מספר הנתיבים שנמצאו עם המרווח הזה.
למשפט הבא נדרשו הרבה שנים, הרבה פרויקטים והרבה הרצות HCP:
ההיסטוגרמה של פרויקטים שהם ישימים – הם לא קלים, הם לא פשוטים אבל אפשר לקיים אותם ולסיים אותם בזמן שתוכנן – נראית כמו עקומת התפלגות נורמלית – הנקראת גם עקומת גאוס או עקומת פעמון – או התחלה שלה.
זו דוגמא לפרויקט כזה – ישים, שניתן לבצע אותו ולסיים אותו כמתוכנן:
ההיסטוגרמה של לוח זמנים של פרויקטים עם הרבה תקלות, תראה כמו א-ק-ג. ואם אנחנו, כבני אדם לא יכולים ללא דופק – ה"דופק" הזה – רע מאד לפרויקטים!
כדי לקרוא עוד על היסטוגרמות ודוגמא נוספת – כדאי ללחוץ כאן, בסעיף 3.1.
מבט כללי (3): אבני דרך
באבני הדרך חשוב להשוות בין תאריך היעד החוזי לתאריך המתקבל בבקרה, וכדאי מאד גם לבדוק מה השינוי מבקרה קודמת – כדי לדעת האם יש מגמת שינוי.
אם תעשו טבלה ברוח הטבלה הזו – פרגנו בקרדיט. 😊
נסכם – מה צריך לעשות ואיך כדי שהלו"ז יהיה תוכנית עבודה?
איך מריצים HCP-Go?
1. מורידים את ה- HCP-Go בגרסה החינמית ל- Project שלך כאן.
2. פותחים את ה- Project, בסרגל "פעילות" יהיו שני ה- Icons של ה- HCP-Go:
3. לוחצים על Go ו- Run Analysis.
4. להדרכה נוספת, ראו את הסרטון בקישור כאן.
ועכשיו, כל לוח זמנים יהיה תכנית עבודה!
