לאחר פירוק פרויקט למשימות מובחנות וברות ביצוע במסגרת תוכנית העבודה, הצעד הקריטי הבא הוא להבין כיצד המשימות האלה קשורות זו לזו.
זהו תהליך מיפוי התלויות בין משימות: זיהוי האם משימה אחת תלויה באחרת, ובדיוק כיצד הן משפיעות זו על תזמון זו.
ביצוע נכון של השלב הזה הוא ההבדל בין תוכנית פרויקט זורמת וגמישה לבין לוח זמנים שברירי שקורס עם העיכוב הראשון.
2 החוקים של קשרים בין משימות
מצב שבו בלתי אפשרי, מבחינה פיזית או לוגית, לעבוד על משימה אחת לפני שמשימה אחרת הושלמה.
דוגמה: אי אפשר להרכיב את גג המבנה לפני שהוקמו הקירות נושאי העומס.
דוגמה: אי אפשר לערוך כתב יד של ספר לפני שהוא נכתב בפועל.
מצב שנובע מתהליכים מוגדרים, תקני בטיחות או שיטות עבודה מיטביות של הארגון שמנהל את הפרויקט.
דוגמה: אי אפשר להתחיל בפיתוח מוצר לפני שהלקוח מאשר רשמית את מסמך אפיון הפרויקט.
דוגמה: צוות בקרת איכות אינו יכול להתחיל בבדיקות רשמיות לפני שהושגה אבן דרך של הקפאת קוד, בהתאם למדיניות החברה.
כלל הזהב: אם קשר מוצע אינו עומד באופן ברור באחד משני החוקים האלה, הימנעו מהוספתו ללוח הזמנים. חיבור יתר בין משימות יוצר קשיחות מלאכותית.
מלכודת עומס היתר על משאבים, ואיך להימנע ממנה
טעות נפוצה מאוד היא לקשר בין שתי משימות רק מפני שהן הוקצו לאותו אדם.
דמיינו צבעי אחד שאחראי לצבוע דירה שלמה. מכיוון שמדובר באדם אחד בלבד, הוא יכול לצבוע רק חדר אחד בכל פעם. לכן מפתה מאוד לקשר את משימת צביעת חדר א׳ למשימת צביעת חדר ב׳ ברצף ליניארי.
זו טעות.
קישור משימות על בסיס זמינות של אנשים יוצר כאב ראש משמעותי בשלבי המעקב והבקרה. אם בהמשך תעסיקו צבעי שני כדי להאיץ את הפרויקט, תצטרכו לעבור ידנית על כל תוכנית הפרויקט כדי למחוק את הקשרים המלאכותיים האלה.
הפתרון: השאירו את המשימות עצמאיות ברשת הלוגית שלכם. טפלו באילוץ התזמון בשלב הקצאת המשאבים באמצעות החלקת משאבים. זהו מנגנון תוכנה או תהליך ידני שמדרג משימות באופן אוטומטי לפי זמינות המשאבים, בלי לקבע תלות שגויה בתוך התוכנית.
ארבעת סוגי הקשרים בין משימות
כדי למפות תהליכי עבודה בצורה מדויקת, יש להשתמש בסוג הנכון של קשר לוגי. בניהול פרויקטים קיימים ארבעה סוגים סטנדרטיים של תלויות:
- הגדרה: משימה ב׳ אינה יכולה להתחיל עד שמשימה א׳ מסתיימת.
- דוגמה: אי אפשר להתחיל ביציקת רצפת הבטון (משימה ב׳), לפני שהושלמה חפירת הקרקע (משימה א׳). זהו סוג התלות הנפוץ ביותר בניהול פרויקטים.
- הגדרה: משימה ב׳ אינה יכולה להתחיל עד שמשימה א׳ התחילה. לאחר שהן יצאו לדרך, הן יכולות להתבצע במקביל.
- דוגמה: צוות יכול להתחיל בפיתוח התוכנה (משימה ב׳), ברגע שמתחיל תכנון ארכיטקטורת בסיס הנתונים (משימה א׳), וכך שני הצוותים יכולים לעבוד במקביל.
- הגדרה: משימה ב׳ אינה יכולה להסתיים עד שמשימה א׳ מסתיימת.
- דוגמה: לא ניתן להשלים סופית את התיעוד ומדריך המשתמש (משימה ב׳), לפני שהגרסה הסופית של התוכנה (משימה א׳), הושלמה במלואה.
- הגדרה: משימה ב׳ אינה יכולה להסתיים עד שמשימה א׳ מתחילה. זהו סוג התלות הנדיר ביותר.
- דוגמה: מערכת שרתים ישנה (משימה ב׳), חייבת להישאר פעילה ואינה יכולה להיסגר עד ששרת הענן החדש עולה לאוויר ומתחיל לפעול (משימה א׳).
כוונון עדין באמצעות הקדמות והשהיות
דוגמה: לאחר צביעת חדר (משימה א׳), יש להמתין יומיים עד שהצבע יתייבש, השהיה, לפני שניתן להתקין מדפים (משימה ב׳).
קשר זה מבוטא כך: FS + יומיים.
דוגמה: אם כתיבת דוח בן 10 פרקים נמשכת 10 ימים (משימה א׳), המעצב הגרפי יכול להתחיל בעיצוב הפריסה (משימה ב׳), יומיים לפני שהכתיבה מסתיימת לחלוטין, כל עוד הפרקים הראשונים כבר מוכנים.
קשר זה מבוטא כך: FF – יומיים.
רשימת בדיקה מסכמת למנהלי פרויקטים
לפני סגירת לוח הזמנים של הפרויקט, בדקו את תרשים הרשת מול רשימת הבקרה הבאה:
- לוגיקה קשיחה: האם משימות סדרתיות מקושרות רק כאשר אי אפשר לבצע אותן אחרת, פיזית או לוגית?
- לוגיקה רכה: האם קשרים שאינם קשיחים נשענים על תהליכים ארגוניים מתועדים, תקני בטיחות או מדיניות איכות?
- ללא קשרי משאבים: האם נמנעתם מקישור בין משימות רק משום שהוקצו לאותו אדם? במקרה כזה, השתמשו בהחלקת משאבים.
- סוג קשר נכון: האם בחרתם את הקשר הלוגי המתאים, FS, SS, FF או SF, כך שישקף את אופן ההתחלה או הסיום האמיתי של העבודה?
- דחיסת לוח זמנים: האם זיהיתם הזדמנויות לקצר את משך הפרויקט באמצעות החלפת קשרי סיום להתחלה בקשרים מקבילים מסוג התחלה להתחלה או סיום לסיום?
- המתנות פסיביות: האם זמני המתנה שאינם עבודה, כמו ייבוש, אשפרה או חלונות אישור, הוגדרו כהשהיות ולא ניפחו את משך המשימה עצמה?
- חפיפות בטוחות: כאשר הוגדרו הקדמות, האם המשימה העוקבת באמת יכולה להתחיל מוקדם על בסיס תוצר חלקי, טיוטה או מסירה זמנית מהמשימה הקודמת?
- ללא קצוות פתוחים: האם לכל משימה יש משימה קודמת ומשימה עוקבת, כך שלוח הזמנים יחשב תאריכים אוטומטית במקרה של עיכוב?
- ללא לוגיקה מעגלית: האם הרשת נקייה מלולאות, למשל מצב שבו משימה א׳ תלויה במשימה ב׳ ומשימה ב׳ תלויה במשימה א׳?
כאשר שולטים בלוגיקה שמחברת בין המשימות, לוח הזמנים מפסיק להיות ציר זמן קשיח והופך לכלי ניהולי דינמי, אמין ומדויק יותר להובלת הפרויקט.
