פרויקט יכול לעמוד בלוחות הזמנים, להישאר בתוך מסגרת התקציב, להיות מנוהל על ידי מנהל פרויקט מנוסה, ועדיין להיכשל.
מי שמנהל פרויקטים לאורך זמן כבר פגש את התופעה הזאת יותר מפעם אחת. לפעמים היא מתחילה בשקט. החלטות משמעותיות נדחות שוב ושוב. דרישות משתנות נכנסות בלי בחינה מסודרת של השפעתן. בעלי עניין מושכים לכיוונים שונים. מנהל הפרויקט מוצא את עצמו משקיע יותר זמן בתיאומים ופחות זמן בהובלה. לכאורה הכול מתקדם. יש Dashboard. יש סטטוסים. יש תוכניות עבודה. אבל מתחת לפני השטח המערכת מתחילה להישחק.
ברגעים האלה עולה שאלה מקצועית חשובה: האם ניהול פרויקט טוב לבדו מספיק כדי להבטיח הצלחה?
בעבר היה קל יותר לענות "כן". ארגונים פעלו בסביבה יציבה יותר. מספר בעלי העניין היה מצומצם יחסית. מערכות טכנולוגיות היו פשוטות יותר. מנהל פרויקט מנוסה היה מסוגל פעמים רבות לגשר על פערים ארגוניים באמצעות ניסיון, קשרים אישיים ויכולות ניהול גבוהות.
המציאות של היום שונה לחלוטין.
פרויקטים טכנולוגיים פועלים בסביבה של AI, מודלי עבודה היברידיים, ספקים מרובים, רגולציה משתנה, צוותים מבוזרים, מערכות ענן, תלות גבוהה בין ממשקים וטרנספורמציות דיגיטליות שחוצות יחידות עסקיות שלמות. ככל שהמורכבות גדלה, כך היכולת להסתמך רק על ניהול פרויקט איכותי פוחתת.
מנהל פרויקט טוב עדיין נשאר גורם קריטי להצלחת הפרויקט. אבל בעולם שבו המורכבות הארגונית והטכנולוגית גדלה באופן עקבי, הצלחת הפרויקט תלויה יותר ויותר גם במסגרת הניהולית שעוטפת אותו.
המסגרת הזאת נקראת משילות פרויקט (Project Governance).
אבל השינוי אינו רק ברמת המורכבות. הוא גם ברמת האופן שבו ארגונים מגדירים הצלחה. במשך שנים עולם ניהול הפרויקטים נשען במידה רבה על "משולש הברזל" של תכולה, לוחות זמנים ותקציב. פרויקט שנמסר בזמן, עמד בתקציב וסיפק את התכולה שהוגדרה, נחשב בדרך כלל לפרויקט מוצלח. בשנים האחרונות התפיסה הזאת התרחבה.
PMI חידד את הנקודה בדוח Maximizing Project Success:
"delivered value that was worth the effort and expense"
(PMI, Maximizing Project Success, 2024)
הצלחת פרויקט אינה נמדדת רק לפי עמידה בתכולה, לוחות זמנים ותקציב, אלא גם ביכולת לייצר ערך שמצדיק את ההשקעה הארגונית. לכן פרויקט יכול לעמוד בכל מדדי הביצוע המסורתיים, ועדיין להיחשב ככישלון אם התוצאה אינה מייצרת את הערך העסקי שלשמו הארגון יצא לדרך.
כאן בדיוק מתחילה חשיבותה של המשילות. לא כעוד שכבת פיקוח ולא כעוד ועדה, אלא כתשתית ניהולית שמאפשרת לארגון לקבל החלטות טובות יותר, להתמודד עם מורכבות ולוודא שהפרויקט אינו רק מתקדם, אלא גם מתקדם בכיוון הנכון.
מהי בכלל משילות פרויקט
אחת הטעויות הנפוצות ביותר בארגונים היא הבלבול בין ניהול פרויקט לבין משילות פרויקט. שני המונחים עוסקים בהצלחת הפרויקט, ושניהם משפיעים על התוצאה, אבל הם פועלים ברמות שונות לחלוטין. ניהול פרויקט עוסק בשאלה כיצד לבצע את העבודה: תכנון, ביצוע, בקרה, תקציב, תכולה, סיכונים, תקשורת, אינטגרציה ובעלי עניין. משילות עוסקת בשאלה אחרת: מי מחליט, בשם מי, על סמך מה, באילו גבולות, וכיצד מוודאים שהפרויקט נשאר מחובר למטרות הארגון.
PMBOK® Guide מהדורה שביעית מציג את תפיסת System for Value Delivery, המדגישה כי פרויקטים אינם מתקיימים כמערכות עצמאיות. הם חלק ממנגנון רחב יותר שמחבר בין אסטרטגיה, פורטפוליו, תוכניות, פרויקטים ותוצאות עסקיות. זוהי נקודת שינוי משמעותית: השאלה אינה רק האם הפרויקט מתקדם, אלא האם הארגון בנוי כך שהפרויקט יוכל להצליח ולייצר ערך.
גם הספרות המחקרית מחזקת את ההבחנה הזאת. הסקירה השיטתית של Musawir ועמיתיו, שפורסמה ב-International Journal of Project Management ובחנה את גוף הידע המחקרי בתחום משילות הפרויקטים, מתארת משילות כמנגנון שמסדיר את סביבת קבלת ההחלטות ואת המסגרת המוסדית שבתוכה הפרויקט פועל. במילים פשוטות, ניהול פרויקט מתמקד בביצוע העבודה. משילות מתמקדת בבניית התנאים שמאפשרים לעבודה להצליח.
כאשר משילות בנויה היטב, מנהל הפרויקט יכול להוביל. כאשר היא חלשה, גם מנהל פרויקט מצוין עלול למצוא את עצמו מתאם בין גופים, רודף אחר החלטות ומכבה שריפות. חמישה מרכיבים חוזרים כמעט בכל מסגרות המשילות המקצועיות: תפקידים ואחריות ברורים, סמכויות החלטה, אחריותיות תוצאתית, פיקוח ובקרה, ויישור אסטרטגי. כאשר אחד מהם חסר, נוצר פער. כאשר כמה מהם חסרים, מתחילה להיווצר שחיקה מערכתית.
למה משילות הפכה קריטית יותר מאי פעם
מי שנמצא בעולם ניהול הפרויקטים מספיק שנים רואה היטב את השינוי. פרויקטים אינם רק גדולים יותר מבעבר. הם מחוברים יותר, דינמיים יותר ומושפעים ממספר גדול בהרבה של גורמים. בעבר, ארגון היה יכול לנהל פרויקט טכנולוגי משמעותי בתוך גבולות ברורים יחסית. צוותים ישבו באותו אתר, מספר הספקים היה מוגבל, מערכות טכנולוגיות היו עצמאיות יותר וסביבת העבודה הייתה יציבה יותר.
העולם של היום שונה לחלוטין. פרויקטים מודרניים פועלים בתוך סביבות עבודה מרובות ספקים, שבהן ספק אחד מנהל תשתיות, ספק אחר אחראי על פיתוח, גורם נוסף מטפל באינטגרציה, וצוותים נוספים אחראים על אבטחת מידע, נתונים, רגולציה, בדיקות ותפעול. במקביל פועלים צוותים מבוזרים, תשתיות ענן, מערכות ותיקות (Legacy Systems), מנגנוני ממשל נתונים (Data Governance), ומערכות AI שמשפיעות יותר ויותר על תהליכי העבודה.
גם מודלי העבודה השתנו. ארגונים אינם פועלים עוד רק בגישה חזויה או רק בגישה אג'ילית. במקרים רבים אותו פרויקט משלב Predictive, Agile ו-Hybrid, ולעיתים כל יחידה בארגון עובדת בקצב אחר ובשפה אחרת. המשמעות היא שהתלות ההדדית בין גורמים ארגוניים גדלה באופן משמעותי. וככל שהתלות גדלה, כך גדלים גם הסיכונים: פערי אחריות, עיכובי החלטות, חוסר יישור בין בעלי עניין, והעברת סיכונים בין יחידות במקום טיפול אמיתי בהם.
גם עולם ה-AI מחדד את הצורך במשילות. מסגרת NIST AI Risk Management Framework, שפורסמה על ידי המכון הלאומי לתקנים וטכנולוגיה בארצות הברית (NIST), מגדירה את GOVERN כפונקציית ליבה המתמקדת ביצירת מסגרת ניהולית של אחריות, פיקוח, מדיניות ומנגנוני בקרה לאורך מחזור החיים של מערכות AI. השאלה כבר אינה רק כיצד בונים מודל, אלא מי אחראי על המידע, מי מפקח על המערכת, מי מאשר את השימוש בתובנות, ואיך מבטיחים שהחלטות הנתמכות על ידי AI יישארו שקופות, מבוקרות ומחוברות לאחריות אנושית. זאת בדיוק משילות.
ככל שהמורכבות גדלה, כך משילות הופכת פחות לאפשרות ויותר לתנאי בסיס. היא אינה מבטלת מורכבות, אלא מאפשרת לארגון להתמודד איתה באופן מסודר, שקוף ומבוקר.
כשהמורכבות גדולה מהמשילות, הלקח של Denver International Airport
אחד ממקרי הבוחן הידועים ביותר בעולם ניהול הפרויקטים מדגים היטב מדוע ניהול פרויקט איכותי לבדו אינו מספיק. בתחילת שנות התשעים יצאה עיריית דנוור לפרויקט שאפתני במיוחד: הקמת שדה תעופה חדש שיחליף את Stapleton International Airport. אחד המרכיבים המרכזיים בפרויקט היה מערכת כבודה אוטומטית מתקדמת שתוכננה לטפל בכ-60,000 מזוודות בשעה באמצעות מסועים, עגלות אוטומטיות, בקרים ממוחשבים וממשקים טכנולוגיים מורכבים.
החזון היה מרשים. הטכנולוגיה הייתה חדשנית. רמת המורכבות הייתה עצומה. בפועל, הפרויקט הפך לאחד ממקרי הכשל הידועים בעולם ניהול הפרויקטים. שדה התעופה נפתח באיחור של 16 חודשים. העלויות חרגו משמעותית. מערכת הכבודה חוותה כשלים חוזרים. האינטגרציה בין המערכות לא עבדה באופן תקין, והפתרון שתוכנן להיות סמל לחדשנות הפך לאורך השנים לאחד ממקרי הלימוד המוכרים בתחום פרויקטי התשתית והטכנולוגיה.
ניתוחים מקצועיים ואקדמיים שבחנו את הפרויקט לאורך השנים הצביעו על שילוב גורמים שתרמו לכשל: תכנון לקוי, שינויי תכולה משמעותיים בשלבים מאוחרים, ריבוי ממשקים, מורכבות גבוהה, תיאום מאתגר בין גורמים שונים, ופיקוח שלא הצליח לזהות בזמן פערים שהלכו והצטברו. בסקירה אקדמית שבחנה את הלקחים מפרויקט Denver International Airport עלתה גם התייחסות מפורשת לחשיבותו של פיקוח אפקטיבי, לצד הקביעה כי:
"the failure of the federal government to provide adequate oversight"
(Dempsey, Goetz & Szyliowicz, 1998, as cited in Prather, 1998)
מנקודת מבט ניהולית עכשווית, זהו גם שיעור חשוב במשילות. כאשר מנגנוני פיקוח אינם מספקים, כאשר אחריות אינה ברורה מספיק, וכאשר המורכבות גדלה מהר יותר מהיכולת הארגונית לנהל אותה, גם פרויקטים שאפתניים עם חזון מרשים עלולים להיכשל.
מי שמוביל היום תוכנית טרנספורמציה, פרויקט מרובה ספקים או סביבת אינטגרציה מורכבת צריך לראות את המקרה הזה לא כסיפור היסטורי, אלא כתזכורת מקצועית. ככל שרמת התלות ההדדית גדלה, כך היכולת "להסתדר תוך כדי תנועה" קטנה. מנגנוני משילות צריכים להיבנות מראש, לפני שהמורכבות הופכת למשבר.
הסימנים לכך שהתשתית הניהולית אינה חזקה מספיק
משילות חלשה כמעט אף פעם אינה מתחילה במשבר גדול. היא מתחילה בשחיקה שקטה, שלעיתים נראית כמו רעש תפעולי יומיומי. אחד הסימנים הראשונים מופיע בקבלת ההחלטות. כאשר החלטות קריטיות נדחות שוב ושוב, הארגון מתחיל לשלם מחיר מצטבר. בתחילה אלו ימים בודדים. אחר כך שבועות. בהמשך הפרויקט מתחיל לבנות פתרונות עוקפים כדי להתקדם, ובמקרים רבים הפתרונות הזמניים הופכים לחלק קבוע מהמערכת.
ברמה הארגונית נוצר מצב שמכונה לעיתים Decision Latency, עיכוב מתמשך בקבלת החלטות שמתחיל להאט את יכולת הארגון להגיב בזמן. הבעיה אינה רק הזמן שחולף. הבעיה היא ההשפעה המצטברת: צוותים וספקים מתחילים לפעול לפי הנחות שונות, סיכונים ממשיכים להצטבר, והפרויקט מאבד את היכולת להגיב בזמן.
סימן נוסף הוא חוסר בהירות סביב סמכויות. מי מחליט, מי מאשר ומי אחראי. כאשר שלושת המרכיבים הללו אינם ברורים, נוצרת שחיקה ניהולית. מנהל הפרויקט מתחיל להשקיע יותר זמן בתיאומים ופחות זמן בהובלה. צוותים ממתינים לאישורים. סוגיות נופלות בין בעלי תפקידים. אחריות הופכת ל"אחריות משותפת", שלעיתים קרובות משמעותה בפועל שאין אחריות ברורה כלל.
גם ריבוי מנגנוני בקרה יכול להעיד על בעיית משילות. באופן פרדוקסלי, ארגונים מסוימים מנסים לפתור בעיות של שליטה באמצעות הוספת עוד ועדות, עוד אישורים ועוד שכבות ניהול. בפועל קורה לעיתים ההפך. המערכת הופכת איטית יותר, קבלת ההחלטות נפגעת, הצוותים מאבדים עצמאות ומנהל הפרויקט הופך בהדרגה למרכז תיאומים במקום למוביל ביצוע.
אחד הסימנים המשמעותיים ביותר מופיע כאשר תכולת הפרויקט מתחילה להשתנות ללא מנגנון בקרה ברור. מנהלי פרויקטים מכירים היטב את הרגע הזה: "רק עוד דרישה קטנה", "רק שינוי קטן", "רק פיצ'ר נוסף". בהיעדר מנגנון משילות ברור, שינויים קטנים מצטברים לשינוי גדול. הפרויקט מתחיל לסטות. בתחילה כמעט לא מרגישים. אחר כך מתחילים לראות את ההשפעה בלוחות הזמנים. בהמשך גם בתקציב. ובסופו של דבר גם באמון של בעלי העניין.
כשהטכנולוגיה לא הייתה הבעיה, הלקח של Healthcare.gov
בשנת 2013 עלתה לאוויר בארצות הברית פלטפורמת Healthcare.gov כחלק מיישום רפורמת הבריאות האמריקאית Affordable Care Act. מבחינה טכנולוגית היה מדובר בפרויקט מורכב מאוד. עשרות מערכות שונות נדרשו לעבוד יחד. יותר מחמישים ספקים וקבלנים חיצוניים היו מעורבים בפרויקט. מספר רב של גופים ממשלתיים נדרשו לתאם ביניהם תהליכים, ממשקים ונתונים.
ביום העלייה לאוויר התגלו כשלים משמעותיים בתפקוד המערכת. משתמשים רבים לא הצליחו להירשם, ביצועי המערכת היו ירודים, ממשקים קריטיים לא פעלו באופן תקין, והפרויקט הפך בתוך ימים בודדים למשבר ציבורי ולאומי.
Government Accountability Office (GAO), גוף הביקורת והפיקוח של הקונגרס האמריקאי, פרסם לאחר מכן דוחות שבחנו את שורשי הכשל. אחד הממצאים המרכזיים לא עסק רק בטכנולוגיה, אלא במשילות. בדוח שפורסם לאחר העלייה הכושלת לאוויר נכתב:
"CMS undertook the development of HealthCare.gov and its related systems without effective planning or oversight practices."
(William T. Woods, Government Accountability Office, 2014)
לפי ממצאי הבדיקה, מנגנוני הפיקוח והבקרה לא הצליחו לתת מענה מספק לרמת המורכבות והסיכון של הפרויקט. האחריות בין הגורמים הייתה מפוצלת. התיאום בין ספקים ובין גורמים ארגוניים לא הצליח לייצר אינטגרציה מספקת. בעיות קריטיות זוהו מאוחר מדי. מנגנוני הסלמה לא הצליחו לייצר תגובה מספקת בזמן.
הטכנולוגיה הייתה המקום שבו הבעיה התגלתה. המשילות הייתה חלק משמעותי מהסיבה שבגללה בעיות שהלכו והצטברו לא זוהו בזמן, לא הוסלמו ולא טופלו מוקדם מספיק. המקרה הזה ממחיש עיקרון חשוב במיוחד בעולם הפרויקטים המודרני: ככל שמספר הממשקים גדל, כך גדלה חשיבותה של המשילות. לא כדי לייצר עוד בקרה, אלא כדי לייצר יכולת ניהול.
משילות אינה בירוקרטיה. היא מנגנון ליצירת ערך
אחת התפיסות השגויות הנפוצות ביותר היא שמשילות מייצרת בירוקרטיה. עוד טפסים, עוד ועדות, עוד עיכובים. אבל בפועל, משילות אפקטיבית עושה בדיוק את ההפך. היא מפחיתה חיכוך, מקצרת זמני החלטה, מגדילה שקיפות, מחזקת יישור ארגוני ומאפשרת לארגון להתמודד עם מורכבות בלי לאבד שליטה.
כאן חשוב לדייק: הבעיה אינה עצם קיומה של מסגרת משילות, אלא אי-התאמה שלה להקשר. משילות כבדה מדי עלולה לפגוע ביכולת הארגון לקבל החלטות בזמן, להעמיס על הצוותים ולייצר תחושת "ניהול יתר". משילות חלשה מדי משאירה את הארגון בלי כיוון, בלי סמכויות ברורות ובלי מנגנון שמאפשר לפתור קונפליקטים. לכן המטרה אינה להוסיף עוד תהליכים, אלא לבנות את רמת המשילות המתאימה שתייצר שקיפות, אחריות ויכולת ניהול. אפשר לקרוא לזה Minimum Viable Bureaucracy: לא כמה שיותר תהליך, אלא בדיוק רמת התהליך הנדרשת כדי לאפשר ניהול אפקטיבי.
PMI חיזק את התפיסה הזאת דרך Value Delivery System, שמסיט את נקודת המבט מהשאלה "האם ביצענו את התהליך נכון" לשאלה רחבה יותר: "האם יצרנו ערך". זהו שינוי עמוק בעולם ניהול הפרויקטים. פרויקט אינו נמדד רק לפי השלמת תוצרים, אלא לפי התרומה שלו לתוצאות, לתועלות ולמטרות העסקיות של הארגון.
במובן הזה, משילות אינה שכבת פיקוח חיצונית על מנהל הפרויקט. היא מערכת שמאפשרת לו לפעול בתוך מסגרת ברורה. היא לא אמורה להאט אותו. היא אמורה למנוע ממנו להיתקע מול החלטות שאין לו סמכות לקבל, מול בעלי עניין שלא מתקיים ביניהם יישור ציפיות, או מול שינויים שאין לגביהם גורם ברור שאחראי לבחון, לאשר ולנהל אותם. משילות טובה אינה שואלת רק אם הפרויקט "בירוק". היא שואלת האם הסטטוס משקף מציאות, האם הסיכונים מטופלים, האם ההחלטות מתקבלות בזמן, האם התכולה עדיין משרתת את המטרה, האם הערך העסקי עדיין מצדיק את המשאבים שהארגון משקיע.
המרכיבים של משילות אפקטיבית
משילות אפקטיבית אינה נבנית ממסמך אחד. היא נבנית ממערכת. המרכיב הראשון הוא מסגרת החלטות ברורה. ארגון צריך לדעת מי מחליט, באילו נושאים, באיזה פורום, על סמך איזה מידע ובאיזה פרק זמן. בפרויקטים מורכבים, העיכוב בהחלטה עלול להיות מסוכן לא פחות מהחלטה שגויה. החלטה מאוחרת יוצרת עבודה חוזרת, שחיקה, פתרונות עוקפים ולעיתים גם אובדן אמון.
המרכיב השני הוא מנגנון הסלמה ברור. לא כל בעיה צריכה להגיע להנהלה, אבל בעיה קריטית שאינה עולה בזמן עלולה להפוך למשבר. מודל הסלמה טוב מגדיר מתי מעלים סוגיה, למי היא מועברת, תוך כמה זמן נדרשת תגובה, ומה האחריות של הגורם המטפל. בלי זה, הסלמה הופכת לאירוע פוליטי במקום לכלי ניהולי.
המרכיב השלישי הוא חסות ניהולית פעילה (Executive Sponsorship). חסות ניהולית אינה חתימה על מסמך התנעה ואינה נוכחות סמלית בוועדת היגוי. חסות ניהולית אפקטיבית מסייעת בקבלת החלטות, מסירה חסמים, מחברת את הפרויקט לאסטרטגיה ומוודאת שהארגון נותן לפרויקט את התנאים הנדרשים להצלחה.
המרכיב הרביעי הוא PMO בשל. PMO אינו רק גוף שאוסף דוחות. במיטבו, הוא מנגנון שמחבר בין מתודולוגיה, שקיפות, סטנדרטיזציה, תעדוף, ניהול פורטפוליו ולמידה ארגונית. PMO כזה אינו שואל רק "מה סטטוס הפרויקט", אלא "האם הפרויקטים הנכונים מקבלים את התנאים הנכונים כדי לייצר ערך".
המרכיב החמישי הוא מדידה שמובילה לפעולה. PMBOK מדגיש זאת היטב:
"The value of measurements is not in the collection and dissemination of the data, but rather in the conversations about how to use the data to take appropriate action."
(PMBOK® Guide – Seventh Edition, Section 2.7, p. 94)
Dashboard אינו משילות. KPI אינו משילות. גם דוח סטטוס אינו משילות. היכולת לקיים שיחה ניהולית אמיתית על בסיס הנתונים ולקבל החלטות בזמן, זו משילות.
משילות בעידן AI והניהול ההיברידי
AI אינו מקטין את החשיבות של משילות. הוא מגדיל אותה. מערכות AI יודעות לנתח מידע, לזהות מגמות, לייצר תחזיות ולהציע תובנות, אבל הן אינן מחליפות אחריות ניהולית. הן אינן מחליפות שיקול דעת. הן אינן מחליפות אחריות ניהולית ותוצאתית (Accountability).
בעולם כזה, משילות נדרשת להגדיר מי אחראי על איכות המידע, מי מאשר שימוש בתובנות מבוססות AI, כיצד מוודאים שקיפות, כיצד מונעים הטיות, ואיך משלבים פיקוח אנושי (Human Oversight) בתהליכי קבלת החלטות. ככל שהמערכות חכמות יותר, כך עולה החשיבות של מסגרת ניהולית שמוודאת שהן משרתות את מטרות הארגון ולא רק מייצרות עוד נתונים.
גם בניהול היברידי, המשילות אינה אמורה להיות קשיחה יותר. היא אמורה להיות מותאמת יותר. פרויקט Agile אינו פטור ממשילות. פרויקט חזוי אינו צריך להיחנק ממנה. פרויקט היברידי צריך מסגרת שיודעת להתאים את עצמה לאופי העבודה, לרמת אי הוודאות, לרמת הסיכון ולצורכי בעלי העניין. זהו בדיוק המקום שבו התאמה (Tailoring) הופכת מעיקרון ניהולי תיאורטי ליכולת ארגונית מעשית.
כשהמשילות מאפשרת להתמודד עם מורכבות, הלקח של Crossrail
פרויקט Crossrail בבריטניה, אחד מפרויקטי התשתית הגדולים באירופה, מדגים צד נוסף של הסיפור. לא רק מה קורה כשמשילות חסרה, אלא גם כיצד מסגרות משילות יכולות לסייע בהתמודדות עם מורכבות חריגה.
Crossrail שילב עשרות קבלנים, מערכות הנדסיות מורכבות, ממשקים עירוניים, רגולציה, תפעול עתידי, בעלי עניין ציבוריים ופרטיים, ותלות גבוהה בין תכנון, ביצוע, אינטגרציה ובדיקות. בפרויקט כזה, הבעיה אינה רק לבצע את העבודה. הבעיה היא לנהל מערכת שלמה שבה כל החלטה משפיעה על שחקנים רבים.
National Audit Office (NAO), גוף הביקורת הציבורית העצמאי של בריטניה, הצביע בדוחותיו על חשיבותם של מבני אחריות ברורים, מנגנוני פיקוח, פורומי החלטה ומעורבות ניהולית מותאמת בפרויקטי תשתית מורכבים. רמת המורכבות בפרויקט הייתה חריגה גם ביחס לפרויקטי תשתית גדולים. Mark Wild, מנכ"ל Crossrail, התייחס לכך בהמשך הדרך כאשר אמר:
"Crossrail was too complicated. It could have been made much simpler."
(Mark Wild, Crossrail CEO, London Assembly)
אחד הלקחים המרכזיים שעלו לאורך חיי התוכנית הוא שמשילות אינה יכולה להישאר קבועה לאורך כל מחזור החיים. ככל שהפרויקט מתקדם, משתנים הסיכונים, רמת אי הוודאות, מורכבות האינטגרציה ואופי קבלת ההחלטות. שלב תכנון, שלב ביצוע, אינטגרציה ועלייה לאוויר אינם דורשים אותה רמת פיקוח, אותם פורומים ואותם מנגנוני החלטה.
המשילות לא ביטלה את המורכבות. היא אפשרה להתמודד איתה. וזאת בדיוק הנקודה. משילות טובה אינה מבטיחה פרויקט קל. היא בונה מערכת שמסוגלת לראות, להחליט, לתקן ולהמשיך לנוע גם כאשר המציאות משתנה.
מה PMO ומנהלי פרויקטים יכולים לעשות כבר מחר בבוקר
הצעד הראשון הוא לבחון את מנגנוני קבלת ההחלטות בפרויקט. לא ברמה עקרונית, אלא ברמה מעשית. קחו עשר החלטות קריטיות בפרויקט: שינוי תכולה, חריגת תקציב, דחיית Go-Live, שינוי סדרי עדיפויות, מעבר בין שלבים, אישור ספק, שינוי ארכיטקטורה, קבלת סיכון משמעותי, שינוי תכולת מוצר ראשוני מינימלי (MVP) או שינוי תאריך מסירה. עכשיו שאלו שאלה פשוטה: האם ברור לחלוטין מי מוסמך לקבל כל אחת מההחלטות הללו. אם התשובה אינה חד-משמעית, כנראה שיש פער משילות שדורש טיפול.
הצעד השני הוא לבצע Governance Health Check. לא עוד סטטוס פרויקט רגיל, אלא בדיקה של התשתית הניהולית עצמה. האם מנגנוני ההסלמה עובדים. האם ועדת ההיגוי מקבלת החלטות או רק שומעת עדכונים. האם החסות הניהולית פעילה. האם ה-PMO מספק ערך או רק מבקש דוחות. האם המדדים משקפים את המציאות או רק מייצרים תחושת שליטה.
הצעד השלישי הוא לצמצם בירוקרטיה שאינה מוסיפה ערך. משילות טובה אינה נמדדת במספר האישורים, אלא באיכות ההחלטות. אם תהליך אישור אינו משפר החלטה, אינו מפחית סיכון ואינו מייצר שקיפות, צריך לבחון מחדש מדוע הוא קיים.
הצעד הרביעי הוא לחזק את הקשר בין אסטרטגיה לביצוע. כל פרויקט צריך לענות באופן ברור על השאלה: איזה ערך הוא אמור ליצור, למי, ובאיזה אופן נזהה שהערך הזה אכן נוצר. בלי החיבור הזה, הארגון עלול לסיים פרויקטים "בהצלחה" ועדיין לא לקבל את התוצאה שלשמה השקיע בהם.
סיכום
פרויקטים מורכבים אינם נכשלים רק בגלל טכנולוגיה, תקציב או לוחות זמנים. פעמים רבות הם נכשלים משום שהתשתית הניהולית שסביבם לא הייתה חזקה מספיק כדי להתמודד עם המורכבות. החלטות לא התקבלו בזמן. אחריות לא הייתה ברורה. בעלי עניין פעלו בכיוונים שונים. מנגנוני הסלמה לא עבדו. המדדים הראו תמונה חלקית מדי.
משילות פרויקט אינה שכבת פיקוח חיצונית. היא התשתית שמאפשרת לפרויקט לפעול בתוך ארגון מורכב. היא מחברת בין אסטרטגיה לביצוע, בין הנהלה לצוות, בין מידע להחלטה, ובין תכנון לערך.
מנהל פרויקט טוב מנהל את העבודה. משילות טובה מוודאת שהארגון כולו מסוגל לאפשר לעבודה הזאת להצליח.
ככל שהמורכבות גדלה, כך משילות אינה הופכת לחשובה יותר. היא הופכת להכרחית.
רוצים ללמוד עוד?
אם אתם שואפים לנהל פרויקטים בצורה מקצועית, לזהות סיכונים מראש ולבצע מענה מתאים למול הסיכונים, לעמוד ביעדים ולשלוט בלוחות זמנים – זה הזמן להצטרף לקורס ניהול הפרויקטים והכנה למבחן ה־PMP שלנו. - לקהל הנרשמים, או לקורס ניהול פרויקטים - PMO -לארגונים המזמינים אותו, הקורסים משלבים ידע עיוני עם כלים מעשיים, כולל סימולציות, תרגולים ומודלים ניהוליים מתקדמים. תלמדו כיצד ליישם את שיטת ה־Critical Path בפועל, איך להתמודד עם עיכובים ואיך להוביל צוות להצלחה. בין אם אתם בתחילת הדרך או כבר מנהלי פרויקטים מנוסים – הקורס ייתן לכם יתרון ברור בשטח.
* המאמר נכתב בלשון זכר מטעמי נוחות בלבד אך מיועד לנשים וגברים כאחד.
מאמר זה נכתב ע"י:
דן ברזילי MEng ,BSc ,PMP
מנכ"ל ומנהל פרויקטים.
וע"י:
הראל הייצין, Bsc, PMP
מנהל פרויקטים
