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

לעיתים מודדים איזה חלק מן הזמן שב-buffer נוצל, לעומת החלק מן ה-duration של השרשרת הקריטית או ה-work של הפרויקט שנוצלו עד כה. ההנחה העומדת בבסיס שיטת בקרה זאת היא שזהו מדד משמעותי, המראה לנו אם הפרויקט מתקדם בקצב הנדרש. כלל האצבע של תורת האילוצים אומר שכאשר נוצלו כבר שני שלישים של ה-buffer, עברנו את "הקו האדום" ויש לבצע פעולות תיקון בלוחות הזמנים (corrective action).

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

1. מדד זה מניח שמשך ותכולת הפרויקט נקבעו מראש, והמטרה היא לעמוד בהם. במציאות, במקרים רבים תכולת הפרויקט משתנה במידה רבה לאורכו, כך שהזמן שהוקצה כ- buffer מאבד את הרלוונטיות שלו.
   למשל: נניח שבמקור הוערך הפרויקט ב-3 חודשי עבודה,שלהם נוסף buffer של 3 שבועות. לאחר חודש של עבודה, הוחלט להוסיף לפרויקט משימה, שביצועה יגרום להארכת הפרויקט בחודש נוסף. במקרה זה ה-buffer הופך להיות לא רלוונטי.
   במציאות בדרך כלל לא נראה שינוי אחד דרמטי כזה, אלא סדרה של שינויים מסוגים שונים, שהאפקט המצטבר שלהם דומה.
   כך או כך,עם כל שינוי כזה (שקורה לא מעט פעמים במהלך הפרויקט), הרלוונטיות של מדד זה נמחקת.
2. למרות שלפי התכנון קצב השלמת העבודה הוא קבוע, המציאות בדרך כלל שונה במידה רבה. יש הטוענים שגם כאן פועל כלל ה-80/20, כך ש-80% מן הפרויקט מבוצעים ב-20% ממשכו הסופי של הפרויקט (לא זה שתוכנן, אלא זה שבפועל) ולהשלמת 20 האחוזים הנותרים נדרשים 80% מן הזמן.
   לדעתי, בדרך כלל המצב לא כל כך גרוע, אבל בכל זאת לעיתים קרובות, ובעיקר ככל שניהול לוחות הזמנים רחוק מן האופטימום, השלבים האחרונים של הפרויקט נמשכים יותר מן המתוכנן. הסיבה העיקרית לכך היא שהשלמת הפרויקט דורשת את סגירת כל הנקודות שנשארו פתוחות במהלכו.
   לכן, לחלק הניכר של ה-buffer נזדקק בסוף הפרויקט. גם אם במהלך 90% ממשך הפרויקט נצרוך רק 60% מן ה-buffer, אנחנו עלולים להיות מופתעים לגלות בהמשך שה-buffer נגמר לפני סיום העבודה. במקרה זה יהיה לנו מדד שנותן לנו ביטחון מוטעה לאורך הפרויקט, ומדליק נורה אדומה רק כשמאוחר מדי למנוע את האיחור.

^(*) קיימות בעיות דומות בשימוש ב-burn-down charts. על כך במיתוס הבא.


נכתב ע"י רונית סנה
IntelliManage

שאלות ותגובות למיתוס זה ניתן להעלות כאן