מהן תלויות בין משימות ואיך מנהלים אותן נכון

קו סניקה באורך 11 ק"מ, שני מעברי כביש ותחנת שאיבה אחת. הגאנט הראה 63% ביצוע, הקבלן דיווח על עמידה ביעדים, וההנהלה ישבה רגועה. שלושה שבועות לאחר מכן התברר שאף מטר של צינור לא הונח בקטע המרכזי, כי אישור התאום מול מקורות לא נסגר. בלוח הזמנים המקורי לא היה שום קשר לוגי בין האישור לבין הנחת הצינור. שתי הפעילויות פשוט רצו במקביל, זו לצד זו, בלי חוט אחד שמחבר ביניהן. המאמר מסביר את ארבעת סוגי התלויות המקובלים בניהול לוחות זמנים, איך בוחרים בין FS, SS, FF ו-SF במצבים אמיתיים בשטח, ואיך קשרים לוגיים שגויים מייצרים נתיב קריטי שגוי ותחזיות עיכוב לא אמינות.

זה לא כישלון של הקבלן. זה כישלון של הלוגיקה.

זמן קריאה: 5 דקות

מהן תלויות בין משימות ולמה הן קריטיות ללוח זמנים אמין?

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

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

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

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

איך תלויות בין משימות שונות מ"סדר עבודה" כללי או רשימת To-Do?

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

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

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

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

ארבעת סוגי הקשרים על שולחן אחד

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

התיעוד הרשמי של Microsoft Learn לבניית WBS מגדיר את ארבעת הסוגים ואת מכניקת ההיסט שמאפשרת השהיה או הקדמה. שילוב נכון של השניים הוא כל התורה.

מהו Finish to Start (FS) ומתי הוא הקשר הנכון ביותר?

Finish to Start הוא קשר סיום להתחלה, הפעילות העוקבת מתחילה רק לאחר שהקודמת הסתיימה במלואה. זו ברירת המחדל בכל כלי תכנון, מ-MS Project ועד Primavera, וברוב המקרים בפרויקט הנדסי היא גם נכונה.

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

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

כלל מעשי, FS הוא הקשר שאתה בוחר כשהתשובה לשאלה "מה יקרה אם נתחיל מוקדם" היא עבודה חוזרת.

סימנים ש-Finish to Start משמש כברירת מחדל שגויה

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

הפתרון אינו להחליף את הקשר ל-SS עם השהיה שרירותית. הפתרון הוא לפרק את הפעילות הגדולה למקטעים. במקום פעילות אחת של "יציקת רצפות תעשייתיות 9,000 מ"ר" שאחריה "צביעת סימון", מפרקים לשלושה מקטעים של 3,000 מ"ר, וכל מקטע מקבל FS משלו. הגאנט מציג עבודה מקבילה אמיתית, והבקרה ממשיכה להיות מדידה לפי מסירה של מקטע.

כלל מעשי, כשמתחשק לך לרכך קשר FS, פרק את הפעילות. אל תרכך את הלוגיקה.

מהו Start to Start (SS) ומתי משתמשים בו בפרויקטים רב-תחומיים?

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

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

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

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

מהו Finish to Finish (FF) ומתי הוא מייצר בקרה טובה יותר מ-FS?

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

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

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

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

מהו Start to Finish (SF) ולמה הוא נדיר אבל לפעמים שימושי?

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

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

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

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

מתי SF גורם לבלבול ואיך נמנעים ממנו

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

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

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

מה זה Lead ומה זה Lag בתלויות בין משימות (ואיך לא ליפול בזה)?

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

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

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

כלל מעשי, Lag חייב להיות מנומק בנתון הנדסי. Lead חייב להיות מנומק בהחלטת סיכון מתועדת.

כלל אצבע לשימוש בטוח ב-Lead/Lag

אסור להסתיר עבודה בתוך השהיה. "זמן אישור מוסדות תכנון" של 30 יום שנרשם כ-Lag על קשר FS הוא הכשל הנפוץ ביותר שנתקלים בו בבדיקות לוגיקה. אין לו שם, אין לו אחראי, אין לו אחוז ביצוע, ואי אפשר לדווח עליו בישיבה חודשית.

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

כלל מעשי, אם להשהיה יש בעל תפקיד שאחראי עליה, היא פעילות. לא Lag.

איך בוחרים סוג תלות נכון בין שתי משימות?

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

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

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

כלל מעשי, תשאל את מי שמבצע, לא את מי שמצייר.

מה ההבדל בין תלות לוגית, תלות משאבים ותלות חיצונית?

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

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

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

איך תלויות משפיעות על הנתיב הקריטי ועל תאריך הסיום?

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

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

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

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

כמה תלויות זה יותר מדי?

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

בפרויקט מבנה משרדים בן 22,000 מ"ר עם 1,400 פעילויות, ירידה ממספר קשרים של 4,900 ל-2,700 שיפרה את יכולת הניתוח דרמטית ולא שינתה את תאריך הסיום ביום אחד.

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

איך ממפים קשרי גומלין בצורה שמנהלים וקבלנים מבינים?

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

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

כלל מעשי, הצג לוגיקה לפי קהל. אותו מודל, שלוש תצוגות.

מינימום תיעוד נדרש לכל תלות רגישה

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

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

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

כלל מעשי, תלות בלי מסמך מעבר היא כוונה טובה, לא תלות.

איך מנהלים תלויות בין קבלני משנה בלי לגלגל עיכובים?

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

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

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

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

מהן הטעויות הנפוצות בהגדרת Dependencies (ואיך מתקנים)?

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

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

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

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

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

לפני קיבוע Baseline יש חמש בדיקות שלוקחות שעה ומונעות חצי שנה של דיונים. לכל פעילות יש לפחות קדם אחד ועוקב אחד, למעט אבן הדרך הפותחת והמסיימת. אין אילוצי תאריך קשיחים מסוג Must Start On או Must Finish On, ולכל היותר אילוצים רכים מסוג Start No Earlier Than עם הסבר. אין Lag על קשרי FF ללא נימוק הנדסי. אחוז הפעילויות על הנתיב הקריטי אינו חורג מ-20% בקירוב. והבדיקה החשובה מכולן, הדפסת הנתיב הקריטי והצגתו למנהל הביצוע.

אם הוא אומר "זה לא סדר העבודה שלנו", הבעיה במודל, לא בשטח.

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

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

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

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

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

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

מה משתנה כשהלוגיקה נכונה אבל התשובה לא נוחה?

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

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

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

כלל מעשי, לוח זמנים משנים כשהמציאות משתנה, לא כשהתוצאה לא מוצאת חן.

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

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

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

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

שאלות נפוצות

ניהול תלויות בין משימות הוא בסופו של דבר עבודה של תיאום בין ההיגיון ההנדסי לבין הכלי החישובי שמייצג אותו. הבחירה בין FS, SS, FF ו-SF נגזרת ממה שקורה בשטח, לא מנוחות התכנון, וכל השהיה שלא מנומקת בנתון פיזי צריכה להפוך לפעילות עם בעל תפקיד ותאריך. יחס קשרים מדוד, בדיקת שפיות לפני קיבוע Baseline, והצגת הנתיב הקריטי למי שמבצע אותו בפועל, הם שלוש פעולות שמבדילות בין לוח זמנים שמנהל את הפרויקט לבין לוח זמנים שרק מתאר אותו בדיעבד.

אודות הכותב

אוריאל פליס, PMP, מייסד ומנכ"ל שער ניהול פרויקטים ומכרזים. מהנדס תעשיה וניהול, בוגר Polytechnic University בניו-יורק, מוסמך PMP מטעם ארגון PMI העולמי, בעל למעלה מ-25 שנות ניסיון בניהול פרויקטים, בניהול מכרזים ובארגון ושיטות. אוריאל הקים את שער בשנת 2010 ומוביל את פעילותה מאז, לאחר תפקידי ניהול בכירים בחברות הנדסה, פארמה, ביטוח והיי-טק. בשנים 2014-2016 כיהן כסגן נשיא וחבר הנהלת PMI-ישראל, והשתתף בצוות מומחים בינלאומי שכתב את תקן ה-WBS של PMI.