Scope Creep - הזליגה הקטנה שמסכנת פרויקטים גדולים

כש"רק עוד פיצ'ר קטן" הופך לסיוט ניהולי
כל מנהל פרויקטים מכיר: הלקוח או מנהל פנימי אומר, "זה רק שדה קטן במסך, לא אמור לקחת יותר מיום עבודה". בפועל, יום קטן מתגלגל לשבועות עבודה, לוח הזמנים נמתח, התקציב ננעל, והצוות מוצא עצמו מכבה שריפות במקום להתקדם.
זו לא תקלה חריגה, זו תופעה מוכרת, לפי PMI Pulse of the Profession 2018, כ- 52% מהפרויקטים בעולם חוו Scope Creep, זליגה לא מבוקרת של תכולה.

הנתונים העדכניים יותר (PMI Pulse 2023) מצביעים על שיפור: בארגונים שהשקיעו ב-Power Skills (כישורי ניהול בין-אישיים, תקשורת, חשיבה אסטרטגית והובלת צוותים), רק 28% מהפרויקטים חוו Scope Creep לעומת כ-40% בארגונים אחרים. כלומר, ההבדל אינו רק טכנולוגי, אלא גם ניהולי ותרבותי.

מהו Scope Creep (ומה הוא לא)
^®PMBOK מהדורה שישית מגדיר Scope Creep:
"ההרחבה הבלתי מבוקרת של מוצר או תכולת פרויקט, ללא התאמות לזמן, לעלות ולמשאבים, נקראת התגנבות תכולה." (^®PMBOK מהדורה שישית, עמוד 169)

מהדורה שביעית של ה-^®PMBOK מעדכנת:
"זהו מצב שתכולה או דרישות נוספות מתקבלות מבלי להתאים ולעדכן את לוח הזמנים, צורכי תקציב או משאבים." (^®PMBOK מהדורה שביעית, עמוד 107)

במבט ראשון נראה ששתי ההגדרות אומרות כמעט אותו דבר, אבל למעשה הן משלימות זו את זו ומשרטטות את התמונה המלאה:

• ההגדרה במהדורה השישית (PMBOK^® 6) מתמקדת בתוספות לא מאושרות. כלומר, דרישות שנכנסות לפרויקט מבלי לקבל אישור פורמלי או מבלי לבחון את ההשפעות על זמן, עלות ומשאבים. זהו ה-Scope Creep הקלאסי, המזוהה במיוחד עם פרויקטים מנוהלים בשיטה החזויה (Predictive/Waterfall), שבה כל שינוי אמור לעבור דרך תהליך בקרת שינויים ברור.
• ההגדרה במהדורה השביעית (PMBOK^® 7) מרחיבה את המבט, גם אם הדרישה כן התקבלה על ידי בעלי העניין, אבל לא בוצעו ההתאמות הנדרשות בלוחות זמנים, בתקציב או במשאבים, עדיין מדובר ב-Scope Creep. כאן יש דגש שמתאים גם לסביבות אג'יליות או היברידיות, שבהן שינויים הם חלק מהתהליך, אבל הם חייבים להיות מגובים בהקצאה נכונה של משאבים.

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

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

• דרישות ראשוניות לא ברורות
  הגורם הזה הוא ה"חשוד המיידי". כשפרויקט מתחיל עם מסמך דרישות לא שלם או לא מדויק, החורים מתגלים תוך כדי תנועה, והצוות נאלץ להוסיף פונקציונליות כדי לסגור פערים.
  הנתונים מדגישים: לפי PMI Pulse of the Profession 2014, 37% מהפרויקטים שנכשלו יוחסו ישירות לדרישות לא ברורות. מחקר של IIBA (International Institute of Business Analysis, 2006) מצא כי בין 60% ל-80% מהכישלונות בפרויקטים נבעו מניהול לקוי של דרישות, וכי 56% מהליקויים שהתגלו נבעו מדרישות לא שלמות, מה שהוביל לכך ש-82% מהעבודה החוזרת (Rework) בפרויקטים בוצעה כדי לתקן כשלים כאלה.
  במונחים של ^®PMBOK (מהדורה שישית, סעיף 5.2 – איסוף דרישות), זהו כשל כבר בשלב איסוף הדרישות, במקום תשתית ברורה שמגדירה מה באמת דרוש, נוצר חלל שממלאים אותו, לרוב בדרך של Scope Creep.
• בלבול בין Product Scope ל-Project Scope
  אחת המלכודות הנפוצות ביותר היא חוסר הבחנה בין Product Scope ל-Project Scope. ה־Product Scope מתאר את התכונות והפונקציונליות של המוצר (למשל, אפליקציה עם מודול תשלומים ודוחות), ואילו ה־Project Scope מתאר את העבודה הנדרשת כדי לפתח ולהטמיע את אותן תכונות (אפיון, פיתוח, בדיקות, הדרכה, פריסה).
  כאשר הגבול הזה מיטשטש, קל מאוד להכניס דרישות חדשות "על הדרך", מתוך ההנחה שאם כבר מפתחים מוצר X, אפשר להוסיף לו גם יכולת Y. בפועל, כל "פיצ’ר קטן" כזה מכפיל משאבים, מאריך לוחות זמנים ומערער את האיזון.
  כפי שמציין Harold Kerzner בספרו Project Management: A Systems Approach to Planning, Scheduling, and Controlling (12th Edition, 2017), אחד מהגורמים המרכזיים ל-Scope Creep הוא חוסר בהירות בין הגדרת התוצר לבין עבודת הפרויקט עצמה. הוא מדגיש שהטשטוש הזה נפוץ במיוחד בפרויקטים טכנולוגיים, שבהם הסביבה העסקית משתנה במהירות, וכל דרישה נוספת נתפסת כהרחבה טבעית של המוצר, גם אם לא נכללה בתכולת הפרויקט המקורית.
  זהו אחד הביטויים הברורים ביותר ל-Scope Creep סמוי, דרישות שנכנסות בלי להיראות כמו שינוי אמיתי.
• לחצים מצד בעלי עניין
  Scope Creep נולד לא פעם מלחצים חיצוניים - של לקוחות, הנהלות או בעלי עניין פוליטיים, שמבקשים "רק עוד משהו קטן". ברגע שאין מנגנוני בקרה ברורים, הלחץ הזה מתורגם אוטומטית לשינוי בפועל.
  בארגונים רבים שולטת תרבות של "כן לכל בקשה". הפחד מלאכזב את הלקוח או את ההנהלה גורם למנהלי פרויקטים להסכים גם כשברור שהמחיר יהיה חריגה במשולש האילוצים. לעיתים התוספת נכנסת מתוך נוחות מדומה ("נעשה את זה אחר כך, זה לא ישפיע הרבה"), אבל בפועל היא מתגלגלת לשרשרת עיכובים. הבעיה מחמירה כשאין למנהל הפרויקט סמכות אמיתית לדחות בקשות, או כשאין תהליך Change Control פורמלי שמגן עליו.
  המורכבות גדלה במיוחד בפרויקטים ציבוריים או ממשלתיים, משום שהם מערבים מספר רב של בעלי עניין – ממשרדי ממשלה ורגולטורים ועד ארגוני עובדים והציבור הרחב. ריבוי השחקנים הזה מביא עמו סדרי עדיפויות מגוונים ולעיתים משתנים, ותהליכי תכנון ממושכים חושפים את הפרויקט לשינויים בסביבה. לכן, הלחץ “להוסיף עוד רכיב קטן” הופך שם לתופעה שכיחה במיוחד (PMI Pulse 2019; McKinsey, 2020).
  מחקר של McKinsey (2020), The pivotal factors for effective external engagement מצא כי 58% מהמנהלים הבכירים בעולם מדרגים את ניהול בעלי העניין כאחת משלוש העדיפויות האסטרטגיות המרכזיות של הארגון. המשמעות כפולה: מצד אחד, ההכרה בחשיבות הנושא היא צעד חיובי, שממקם את ניהול בעלי העניין בליבת האסטרטגיה הארגונית. מצד שני, עצם המשקל האסטרטגי שניתן לבעלי עניין מחזק את כוחם להשפיע על הפרויקט, ולכן אם לא מתקיימים מנגנוני בקרה וניהול ציפיות, הלחץ הזה מתורגם בקלות ל-Scope Creep. כאן נכנסת לתמונה החשיבות של Power Skills, מנהל פרויקט שיכול להציב גבול מבלי לשרוף גשרים
• כשלים בתהליכי בקרה
  Scope Creep אינו תמיד "בחירה", לפעמים זו פשוט מערכת חלשה. כשניהול דרישות, בקרת תכולה וניהול שינויים (Change Request) אינם מחוברים, בקשות קטנות מחליקות פנימה.
  למשל: מהנדס מקבל בקשה מהלקוח לשנות פרמטר בתכנון. מתוך רצון טוב, הוא מבצע את השינוי, אבל לא מעדכן את מנהל הפרויקט ולא רושם Change Request. ההשפעות מתגלות מאוחר יותר: משימה אחת משתנה, אחרת מתעכבת, והאפקט המצטבר הופך ל-Ripple Effect – מצב שבו שינוי נקודתי גורר שרשרת השפעות בלתי צפויות על חלקים אחרים בפרויקט.
  כפי שמציינים Larson & Larson (2009), Top five causes of scope creep … and what to do about them, PMI^® Global Congress 2009 - North America, חוסר מעורבות של נותן החסות לאורך חיי הפרויקט יוצר "ואקום החלטות", שבו הצוות עצמו ממלא את החסר ומקבל החלטות לא מתועדות. במילים אחרות, שינוי קטן שלא נבדק כראוי יוצר 'אפקט דומינו' שיכול להפיל פרויקט שלם.
• פרויקטים ארוכים וחשיפה לשינויים חיצוניים
  ככל שפרויקט נמשך יותר זמן, כך הוא נחשף ליותר "הפתעות": רגולציה חדשה, שינוי טכנולוגי, או מתחרה שהשיק פיצ'ר חדש. פרויקטים ארוכים מטבעם חשופים יותר לסביבה משתנה, ולכן רגישים יותר ל-Scope Creep.
  בנוסף, ככל שמשך הזמן גדל, גם הנטייה הפסיכולוגית של הצוות ל"הוסיף עוד קצת" גוברת. זהו ה-internal scope creep, מצב שבו לא הלקוח דוחף, אלא אנשי הצוות עצמם מתקשים לעצור את השיפורים. תופעה זו מתחברת ישירות ל-Gold Plating: הוספת פונקציות מעבר לדרישות, מתוך רצון להרשים את הלקוח, אך במחיר של חריגות בלו"ז ובתקציב.
  כפי שמדגיש Abramovici (2000) במאמרו Controlling Scope Creep ב-PM Network של PMI:
  "Internal scope creep is more insidious, and harder to control. Engineers will by their nature tend to improve their product… anything you do beyond meeting the minimum requirements… comes off your bottom line."

מחיר הזליגה וההשלכות הכבדות
Scope Creep אינו רק מטרד ניהולי, הוא מתורגם לנתונים קשים, לעיתים הרסניים:

• חריגות תקציב –  מחקר של IEEE Computer Society (2020), Software Development: State of the Art Report מצא כי 62% מהפרויקטים חוו חריגות תקציב, כאשר אחת הסיבות המרכזיות היא תוספות לא מתוכננות לתכולה. כל "פיצ’ר קטן" מתגלגל לעלות נוספת, כמו כוח אדם, שעות עבודה, רכישת ציוד שמצטברת לחריגה משמעותית. בארגונים גדולים המשמעות היא אובדן מיליוני דולרים; בארגונים קטנים, איום על עצם היכולת להמשיך את הפרויקט.
• חריגות לו"ז – לפי PMI Pulse of the Profession (2018), Success in Disruptive Times, פרויקטים עם Scope Creep גבוה מתעכבים ב-25%-50% בממוצע לעומת התכנון. ההשלכה איננה רק דחיית מועד ההשקה, אלא גם החמצת חלונות שוק קריטיים: מוצר טכנולוגי שמאחר בחצי שנה עשוי לאבד את יתרון החדשנות שלו מול מתחרים.
• ביטולי פרויקטים – דוח Standish Group, CHAOS Report 2015, מצא כי כ-31% מפרויקטי תוכנה מבוטלים לפני סיומם בגלל חוסר שליטה בדרישות ושינויים בלתי פוסקים. ברגע שהיקף העבודה מתנפח מעבר ליכולת הארגון לממן או לבצע, ההנהלה נאלצת "לסגור את הברז", ולעצור את הפרויקט. זהו הפסד כפול: גם המשאבים שהושקעו עד כה יורדים לטמיון, וגם האמון בהנהלת הפרויקט נפגע.
• פגיעה באיכות ובאמון – כאשר הצוות מתפזר על דרישות נוספות, איכות הביצוע של המשימות המקוריות נפגעת. זה מוביל ליותר ליקויים במוצר, ליותר Rework ולשחיקה במורל הצוות. בנוסף, לקוחות ובעלי עניין מאבדים אמון: מבחינתם הובטח מוצר בזמן מסוים, אך בפועל הם מקבלים גרסה חלקית או מאוחרת, ולעיתים מרגישים שמנהל הפרויקט "לא שולט בעסק", ותחושה הזו פוגעת במוניטין הארגון לא פחות מאשר בתקציב.

במילים אחרות, Scope Creep הוא לא רק עוד חריגה. הוא מכפיל סיכונים: פוגע בכסף, בזמן, באיכות ובקשרים עם בעלי העניין. זהו שילוב קטלני שמערער את ה-ROI (Return on Investment) של הפרויקט ומאיים על עצם המשך קיומו.

מנגנונים למניעה ולבלימה
Scope Creep אינו גזירת גורל. קיימים מנגנונים מוכחים שמסייעים לזהות, לבלום ולנהל אותו:

• Scope Baseline מוגדר
  קו הבסיס של התכולה כולל שלושה רכיבים: הצהרת תכולה (Scope Statement), מבנה פירוק עבודה (WBS) ומילון מבנה תכולת העבודה (WBS Dictionary). לפי PMBOK^® 6th Edition, סעיף 5.4.3, אלה מהווים את נקודת ההתייחסות לכל שינוי עתידי.
  כאשר הם מוגדרים היטב, אין מקום ל"פרשנויות יצירתיות". לדוגמה, אם במהלך הפרויקט עולה בקשה להוסיף פונקציה חדשה, מנהל הפרויקט יכול להפנות לקו הבסיס ולהראות מה נכלל בתכולה ומה לא; משם להעביר לתהליך Change Control מסודר או לדחות, מבלי לפגוע ביחסים עם הלקוח.
• ועדת בקרת שינויים (Change Control Board – CCB)
  ה-CCB היא ועדה רב-תחומית שמקבלת, מעריכה ומחליטה אילו שינויים נכנסים. לפי ^®PMBOK במהדורה השישית (סעיף 4.6), התהליך כולל תיעוד בקשה, ניתוח השפעות (Impact Analysis) והחלטה מנומקת.
  דוגמה היסטורית מפורסמת היא פרויקט Mars Climate Orbiter של נאס"א (1999). הלוויין אבד כאשר נכנס למסלול נמוך מדי סביב מאדים ונשרף באטמוספירה. חקירת האירוע העלתה שהסיבה המרכזית הייתה טעות בהמרת יחידות: צוות הניווט של JPL השתמש ביחידות מטריות (Newtons), בעוד שחברת Lockheed Martin סיפקה נתונים ביחידות אימפריאליות (pounds-force). חוסר התיאום והיעדר בקרת שינויים אפקטיבית הובילו לאובדן חללית בשווי 125 מיליון דולר.
  NASA (1999), Mars Climate Orbiter Mishap Investigation Board Report
  
  המקרה ממחיש את חשיבותו של תהליך Change Control מסודר הכולל טפסי CR אחידים, Impact Analysis והשוואה מול ה-Scope Baseline לפני אישור.
• מדדים כמותיים לניטור זליגה
  ניהול פרויקטים מתקדם אינו מסתפק בתחושות בטן. הוא נשען על מדדים כמותיים המאפשרים לזהות בזמן אמת מגמות של Scope Creep ולפעול לפני שהן הופכות למשבר. שלושה מדדים מרכזיים הם:
    ○ Requirement Volatility (תנודתיות בדרישות) - בודק כמה דרישות משתנות ביחס לדרישות המקוריות. לדוגמה, אם הוגדרו 100 דרישות ו־25 השתנו - התנודתיות היא 25%. ערך מעל 20% מצביע על סיכון גבוה לסטייה.
    ○ Change Request Ratio (יחס בקשות שינוי) - היחס בין בקשות שינוי שאושרו לבין כלל הבקשות. איזון בריא נע סביב 30%-50%. פחות מדי מצביע על נוקשות שמונעת שיפורים, יותר מדי מצביע על חוסר סינון.
    ○ %Rework (אחוז עבודה חוזרת) - חלק מהעבודה שבוצעה מחדש עקב דרישות לא ברורות או שינויים. אם מתוך 1,000 שעות בפרויקט, 200 הושקעו בתיקונים, ה-Rework הוא 20%.
  
  מחקר של IEEE (2017), Empirical Studies of Software Engineering מצא כי פרויקטים שהשתמשו במדדים אלה הצליחו לקצר ב-25% את זמן הטיפול בשינויים. פשוט כי הם ידעו לזהות מוקדם היכן מתרחשת הבעיה, וכך הצליחו למקד מאמצי בקרה בדיוק בנקודות הבעייתיות ביותר.
• תקשורת שקופה עם בעלי עניין
  כפי שמציין PMI Pulse of the Profession 2025, כ-94% מבעלי המקצוע בתחום ניהול הפרויקטים מדרגים את ניהול בעלי עניין כקריטי במצבים של אילוצי לו"ז, ו-91% מדרגים זאת כקריטי במצבי בעיות תקציב המשמעות ברורה: בלי מנגנון תקשורת חזק, קשה להציב גבולות ולבלום Scope Creep.
  פרקטיקות יעילות כוללות שימוש ב-Stakeholder Communication Matrix, הצגת Impact Analysis ויזואלי, ותחזוקת Change Log פתוח, שמציג לכולם אילו בקשות נכנסו, מה נדחה, ומה הועבר לגרסאות עתידיות.
  
  מחקר של Butt et al. (2016), Project change stakeholder communication: A case study of a public sector organization, International Journal of Project Management, מצא כי כאשר נעשה שימוש במנגנוני תקשורת שקופים ומובנים, חלה ירידה משמעותית בהתנגדויות של בעלי עניין ובזמני התגובה לשינויים. החוקרים הראו שדווקא שיתוף בעלי עניין בכל שלב, גם בהחלטות לא פופולריות, מגביר אמון ותורם להצלחת הפרויקט
• Power Skills כמנגנון הגנה אנושי
  לפי PMI Pulse of the Profession 2023, ארגונים שהשקיעו בפיתוח Power Skills כמו תקשורת אסרטיבית, פתרון בעיות, חשיבה אסטרטגית ומנהיגות שיתופית, הפגינו ביצועים גבוהים יותר:
    ○ רק 28% מהפרויקטים בארגונים אלו חוו  Scope Creep, לעומת 40% בארגונים אחרים.
    ○ 72% מהפרויקטים עמדו ביעדים העסקיים שהוגדרו, לעומת 65% בארגונים ללא דגש על כישורים אלה.
    ○ במקרי כישלון, שיעור התקציב שהתבזבז היה נמוך בכ־1.7% (17% לעומת 25%).
  
  Power Skills קריטיים לניהול פרויקטים. הם מאפשרים למנהל להציב גבולות מבלי לשרוף גשרים, לנהל שיח פתוח עם בעלי עניין ולהסביר בצורה משכנעת את המשמעות האסטרטגית של כל שינוי.

דוגמאות מהשטח – כישלון מול הצלחה

• כישלון - נמל התעופה ברלין ברנדנבורג (BER, גרמניה)
  הפרויקט נועד להיות גאוות גרמניה: שדה תעופה מודרני שיחליף את שדות התעופה טגל ושונפלד. הוא התחיל ב-2006 עם תקציב של כ-2 מיליארד אירו ותאריך פתיחה מתוכנן ל-2011. אלא שבמהלך הדרך נוספו אינספור שינויים: שינויי עיצוב במבנה הטרמינל, דרישות בטיחות חדשות, תוספת קניון ומרכז עסקים, וכן לחצים פוליטיים לעמוד בסטנדרטים מתקדמים. כל אלה נכנסו ללא ניהול שיטתי של בקרת שינויים. התוצאה – התקציב זינק ליותר מ-7 מיליארד אירו, והפרויקט נפתח רק ב-2020, תשע שנים אחרי היעד המקורי.
  Bundesrechnungshof (Federal Court of Auditors), Annual Report 2018, Berlin Airport Oversight.
  הלקח המרכזי: בלי מנגנון Change Control חזק, גם פרויקט לאומי עתיר תקציב נגרר לשנים של דחיות וחריגות מסחררות.
  
  
• כישלון -gov (ארה"ב, 2013)
  ממשלת ארה"ב השיקה את הפורטל המרכזי לרישום ביטוחי הבריאות כחלק מהרפורמה של אובמה. הפרויקט התחיל בתקציב של 93.7 מיליון דולר והוקצה ל-55 קבלנים שונים, ללא גוף אחד שאחראי על התיאום. במקביל השתנו דרישות רגולטוריות שוב ושוב. בהיעדר CCB אפקטיבי, כל שינוי נכנס למערכת ללא בחינה כוללת. בהשקה האתר קרס, יותר מ-34,000 ליקויים נרשמו, והעלות הסופית זינקה ל-2.1 מיליארד דולר. לקח מרכזי מהכישלון הזה הוא הצורך בבקרת שינויים ריכוזית ותיאום בין כל הגורמים.
  U.S. Government Accountability Office (GAO), Healthcare.gov: Ineffective Planning and Oversight Practices Undermined Marketplace Implementation, Report GAO-14-694T, July 2014.
  זהו שיעור יקר בכמה מסוכן לנהל פרויקט רחב היקף בלי גוף אחד שמרכז את בקרת השינויים.
  
  
• הצלחה - פרויקט E-Learning (חברת הדרכות, 2020)
  בפרויקט לפיתוח פלטפורמת למידה מקוונת, הצוות נתקל ב-15 בקשות שינוי מצד מחלקות השיווק והמכירות, החל משינויים בממשק ועד הרחבות פונקציונליות. בזכות CCB פעיל, שנפגש אחת לשבוע עם נציגי כל המחלקות, נערך Impact Analysis לכל בקשה: שלוש בקשות קריטיות אושרו (שנגעו לחוויית המשתמש), שבע נדחו, וחמש הועברו לגרסה עתידית. התוצאה – הפרויקט הושלם בזמן ובתקציב, והארגון אימץ את התהליך כסטנדרט לפרויקטים עתידיים.
  com, Case Study: Implementing Change Control in E-Learning Projects, 2021.
  הדוגמה הזו ממחישה איך CCB פשוט, עם פגישות קבועות וניתוח השפעות, יכול למנוע גלישה ולהבטיח הצלחה גם בפרויקטים קטנים.
  
  
• הצלחה - Heathrow Terminal 5 (בריטניה, 2008)
  ב-2008 נחנך טרמינל 5 בנמל התעופה הית'רו בלונדון, אחד מפרויקטי התשתית הגדולים באירופה (עלות כוללת של כ-4.3 מיליארד ליש"ט). יום ההשקה הפך לסיוט, מערכת טיפול בכבודה קרסה, מאות טיסות בוטלו, ויותר מ-15,000 מזוודות הוחמצו. בתקשורת הבריטית תויג הפרויקט ככישלון חרוץ.
  אלא שהלקח המרכזי לא היה בהכרח קריסת המערכת – אלא ההתאוששות. צוותי ניהול השינויים שהוקמו לאחר המשבר פעלו לפי עקרונות של Re-Baselining:
    ○ מיפוי מחדש של התכולה והקפאת תוספות שאינן קריטיות.
    ○ הקמת Change Control Process קשיח, עם ועדות החלטה יומיות לטיפול בכל שינוי.
    ○ השקעה אינטנסיבית בהדרכת עובדים ותיאום בין מאות ספקים וקבלני משנה.
  
  תוך שישה חודשים המערכת התייצבה, רמת השירות חזרה לנורמליות, והטרמינל הפך לאחד מהיעילים ביותר באירופה. סקירה מאוחרת הצביעה על כך ש-Heathrow T5  הוא דוגמה מובהקת לכך שגם כישלון צורב ניתן להפוך לסיפור הצלחה אסטרטגי, אם מנהלים נכון את השינויים.
  Davies, A. (2007). “Heathrow T5: Managing the Mega-Project.” Project Management Journal, 38(1), 46–56.
  Heathrow T5 מוכיח שגם אחרי קריסה מתוקשרת, ניתן להפוך כישלון צורב לסיפור הצלחה, אם מנהלים שינויים בצורה קפדנית ושקופה.

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

ראינו שכלים כמו  Scope Baseline, בקרת שינויים רשמית, מדדים כמותיים ו-Power Skills מאפשרים למנהל הפרויקט לא לעצור חדשנות, אלא לנהל אותה. כך הארגון מרוויח גמישות מבוקרת: חדשנות מצד אחד, שליטה ואחריות מצד שני.

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

רוצים ללמוד עוד?

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

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

מאמר זה נכתב ע"י:
  דן ברזילי MEng ,BSc ,PMP  
    מנכ"ל ומנהל פרויקטים.

וע"י:
הראל הייצין, Bsc, PMP
     מנהל פרויקטים