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

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

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

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

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

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

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


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

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