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

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

זמן קריאה: 4 דקות

עיקרי הדברים

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

מהו מודל מפל מים בניהול פרויקטים?

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

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

איפה מפל מים פוגש לו"ז בפועל?

ניהול לוח זמנים בגישת מפל מים

בשטח, שיטת מפל מים מתורגמת לכלי עבודה נוקשים. אנחנו מבצעים פירוק תכולה [Work Breakdown Structure], בונים גאנט, מזהים נתיב קריטי [Critical Path Method] וקובעים תאריכי בסיס [Baseline]. השמירה על ה-Baseline היא הלב הפועם של ניהול הפרויקט ההנדסי. ללא בסיס קשיח, אין יכולת לאתר סטיות בזמן אמת ולהרים דגלים אדומים לפני שהמערכת קורסת. מתודולוגיית מפל מים מהווה את הבסיס עבור ניהול לוחות זמנים קפדני בפרויקטי בנייה ותשתיות רחבי היקף.

מהו Agile בניהול פרויקטים?

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

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

מה המשמעות של "מפל מים" לניהול לוח הזמנים?

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

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

איך נראה לו"ז Waterfall בפועל מול מציאות הנדסית?

המבנה המעשי של לוח זמנים בגישת מפל מים מורכב מעץ מוצר ותכולה [WBS], חבילות עבודה מפורטות [Work Packages], וקשרי קדימות ואיחור [Lag/Lead]. מנגנוני הבקרה המקצועיים כוללים השוואת ביצוע מול תוכנית בסיס [Baseline Comparison], ניתוח מרווחים [Float/Slack], ומעקב אחר אבני דרך חוזיות בכלי תכנון כמו Primavera או MS Project.

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

איך בונים לו"ז אג'ייל בלי לאבד שליטה?

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

העבודה מתבצעת על בסיס ניהול צבר משימות [Backlog], קצב התקדמות הצוות [Velocity], והגדרת תוצר מוגמר [Definition of Done]. הכלל המעשי הוא שבאג'ייל, הזמן הוא המשתנה הקבוע והתכולה היא המשתנה הגמיש. מי שמפר את הכלל הזה ומנסה לקבע תכולה בתוך ספרינט, מאבד את הגמישות ואת השליטה גם יחד.

3 שכבות תכנון מומלצות לבניית לו"ז אג'ייל

בניית לו"ז אג'ייל דורשת מבנה של שלוש שכבות. שכבה ראשונה היא מפת דרכים אסטרטגית [Roadmap] להסתכלות רבעונית או שנתית, המגדירה יעדים עסקיים ומסגרות שחרור כלליות. שכבה שנייה היא תכנון גרסה או שחרור [Release Planning], שמטרתו לאגד מספר ספרינטים כדי לייצר מקבץ תוצרים בעל ערך מסחרי או הנדסי. שכבה שלישית היא תכנון הספרינט [Sprint Planning], שבו מתבצע פירוק משימות טקטי לטווח הקצר והתחייבות הצוות לביצוען.

מה מחליף את ה-Baseline באג'ייל?

באג'ייל עוברים מהשוואה מול תוכנית בסיס סטטית למעקב מבוסס קצב זרימה [Throughput] ומדדי זמן מחזור [Cycle Time]. הכלים הגרפיים למעקב הם תרשימי שריפת עבודה [Burndown Charts] ותרשימי התקדמות [Burnup Charts]. כך שומרים על שקיפות מול ההנהלה ומקבלי החלטות מבלי להסתמך על בסיס קלאסי. הכלל הוא שהיעד אינו תאריך יחיד, אלא קצב הספקה יציב.

האם באג'ייל יש גאנט או שזה "אנטי-גאנט"?

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

איך מנהלים תכולה, זמנים ועלויות בין שתי הגישות?

משולש הברזל בניהול פרויקטים מול משולש הפוך

ב-Waterfall, "משולש הברזל" של ניהול פרויקטים קובע שהתכולה [Scope] מקובעת ומוגדרת מראש. הזמן והעלות נגזרים ממנה ונוטים להשתנות בעת חריגות. ב-Agile מדובר ב"משולש ההפוך", הזמן והמשאבים, הכולל עלות וגודל צוות, מקובעים. התכולה גמישה ומתעדכנת באופן דינמי בכל סבב עבודה. להרחבה על עקרונות איזון משאבים אלו ניתן לעיין בסקירת מתודולוגיות ניהול פרויקטים של PMI ישראל. ההשלכות נוגעות לניסוח חוזים, התקשרויות מול ספקים ומחויבות ללוחות זמנים מחייבים. במפל מים החוזה סגור, באג'ייל הוא פתוח ומבוסס זמן חומר.

מתי עדיף לבחור בגישת Waterfall?

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

מתי מתודולוגיית Agile עדיפה ומייצרת ערך מהיר?

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

בוחרים את המתודולוגיה הנכונה לפרויקט שלכם?

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

האם Agile מתאים לפרויקטי בנייה ותשתיות?

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

מהו מודל היברידי ואיך הוא מיושם בפרויקטים מורכבים?

מודל היברידי בפרויקטים מורכבים

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

חלוקת שכבות עבודה במודל היברידי

במודל היברידי מחלקים את העבודה לשתי שכבות עיקריות. שכבת ההנהלה והפיקוח [Governance] כוללת לו"ז מאסטר, אבני דרך חוזיות, בקרה תקציבית וניהול שינויים בשיטת Waterfall. שכבת הביצוע והאינטגרציה [Execution] עובדת בצוותים אחודים, מעגלי בדיקות קצרים, וניהול סוגיות שוטפות במתכונת Agile. ההפרדה מאפשרת להנהלה הבכירה לקבל דוחות ברורים ויציבים, בזמן שהצוות המקצועי פותר בעיות בקצב מהיר.

איך מנהלים סיכונים ב-Agile לעומת Waterfall?

ב-Waterfall, ניהול הסיכונים מבוסס על זיהוי, מיפוי וניתוח כמותי ואיכותי מראש בשלבי התכנון. בונים מטריצת סיכונים ותוכניות מענה מובנות. ב-Agile, הפחתת הסיכונים מובנית מעצם האספקה המוקדמת והאיטרטיבית. המטרה היא גילוי מהיר של כשלים [Fail Fast], וסילוק אי-ודאות באמצעות ניסויי היתכנות [Spikes]. לקבלת תוצאות מדויקות, נדרשת מתודולוגיה מובנית וליווי מקצועי עבור שירותי ניהול סיכונים בפרויקטים מורכבים, ללא תלות בגישת העבודה שנבחרה. כלל מעשי, במפל מים מנהלים סיכונים באקסל ובמטריצות, באג'ייל מנהלים אותם על ידי ביצוע מהיר ובדיקת הנחות היפותזה בשטח.

איך מודדים התקדמות וביצועים בשתי המתודולוגיות?

מדדי ההצלחה ב-Waterfall כוללים עמידה ב-Baseline, שיטת ניהול ערך מוזככך [Earned Value Management], ומדדי יעילות זמנים ועלויות [SPI, CPI]. המטרה היא עמידה במועדי אבני הדרך החוזיות. ב-Agile, מודדים הספק צוות [Velocity], זמן אספקת ערך [Lead Time], ושיעור פריטים שהושלמו לפי הגדרת Done. ההבדל בא לידי ביטוי גם בדיווח להנהלה. ב-Waterfall מדווחים על סטיות מתוכנית, ב-Agile מדווחים על כמות ערך שסופק בפועל. כלל מעשי, אל תדרוש ממנהל פרויקט אג'ילי לדווח על SPI, ואל תדרוש ממנהל פרויקט מפל מים לדווח על Velocity. זו שפה שונה לחלוטין.

למה יישום Agile נכשל בארגונים הנדסיים ותשתיתיים?

כשלים נפוצים קורים בעת ניסיון "להעתיק ולהדביק" מתודולוגיות אג'יליות מעולם התוכנה לעולמות הבנייה והתשתיות. התופעה המוכרת היא "אג'ייל מזויף" [Agile in name only]. מאמצים פגישות יומיות [Daily] ללא מתן אוטונומיה לצוותים, או מתפרקים ממשמעת תכנונית בטענה של "גמישות". התוצאה היא כאוס מוחלט ואיבוד שליטה תקציבית. בעיות נוספות כוללות חוסר התאמה מול חוזים מסורתיים, עיכובי אישורים מול גופי תשתית לאומיים, והיעדר תיאום בין צוותי התכנון לשטח הביצועי. הפתרון הוא יצירת משמעת תזמונית היברידית, ליווי PMO מקצועי והגדרת גבולות אחריות ברורים. כלל מעשי, אם עושים אג'ייל, צריך לעשות אותו עד הסוף, כולל מתן סמכויות לצוות. אם לא, עדיף להישאר במפל מים מסודר.

איך לבחור את המתודולוגיה המתאימה לפרויקט שלכם?

איך לבחור את המתודולוגיה המתאימה לפרויקט

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

פרמטר השוואתי Waterfall (מפל מים) Agile (זריז) מודל היברידי
הגדרת תכולה [Scope] מקובעת ומוגדרת מראש בחוזה גמישה ומתעדכנת בכל ספרינט מקובעת ברמת המאקרו, גמישה ברמת הביצוע
ניהול לוח הזמנים נתיב קריטי [CPM] ו-Baseline נוקשה Timeboxing ומפות דרכים [Roadmap] לו"ז מאסטר קשיח עם ספרינטים בתוכו
מדדי ביצוע מרכזיים EVM, SPI, CPI Velocity, Lead Time, Burndown שילוב של מדדי עמידה חוזית וקצב צוות
התאמה לפרויקט תשתיות גבוהה מאוד, מתחייבת חוזית נמוכה בשלב הביצוע, גבוהה בשלב התכנון אופטימלית לפרויקטים מורכבים כמו רכבת קלה
שלב הפרויקט מתודולוגיה מומלצת היגיון הניהול
תכנון מוקדם והיתכנות Agile אי-ודאות גבוהה, נדרשת גמישות בבדיקת אלטרנטיבות
רכש והתקשרות חוזית Waterfall הקפאת תכולה ומחיר לצורך יציבות תקציבית
ביצוע הנדסי בשטח (בטון, חפירה) Waterfall עלות שינוי הרסנית, תלויות חיצוניות רגולטוריות
אינטגרציית מערכות ותוכנה Agile מחזורי בדיקות קצרים מאפשרים זיהוי כשלים מהיר
מסירה והפעלה Hybrid אבני דרך חוזיות נוקשות עם תיקוני שטח מהירים
מאפיין סיכון Waterfall Agile
זיהוי הסיכון מטריצה מפורטת בשלב התכנון זיהוי שוטף בכל ספרינט
אסטרטגיית מענה תוכנית מענה מובנית ועתודות מתוכננות Fail Fast וביצוע ניסויי היתכנות [Spikes]
השפעת כשל מאוחר קטלנית, גוררת אפקט דומינו תקציבי מצומצמת למחזור עבודה אחד בלבד

שאלות נפוצות

האם ניתן לעבור מ-Agile ל-Waterfall באמצע פרויקט?

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

מהו ההבדל התקציבי בין שתי הגישות?

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

כיצד מנהלים ספקים חיצוניים בגישת Agile?

ניהול ספקים ב-Agile מצריך התקשרות חוזית מסוג זמן-חומר [T&M] או התקשרות מבוססת תוצאות, במקום חוזה תמורה פאונלית סגור. ספקים חייבים להשתלב במחזורי העבודה הקצרים ולקבל גמישות בשינוי דרישות, תוך שמירה על עקרונות התקשורת והשקיפות של המתודולוגיה.

האם פרויקט תוכנה בתוך פרויקט תשתיות חייב לעבוד ב-Agile?

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

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

צריכים ליווי בהתאמת מודל העבודה לפרויקט שלכם?

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

אוריאל פליס

אודות הכותב

אוריאל פליס, PMP – מייסד ומנכ"ל שער ניהול פרויקטים ומכרזים. מהנדס תעשיה וניהול, בוגר Polytechnic University בניו-יורק, מוסמך PMP מטעם ארגון PMI העולמי, בעל למעלה מ-25 שנות ניסיון בניהול פרויקטים, בניהול מכרזים ובארגון ושיטות. אוריאל הקים את שער בשנת 2010 ומוביל את פעילותה מאז, לאחר תפקידי ניהול בכירים בחברות הנדסה, פארמה, ביטוח והיי-טק. בשנים 2014-2016 כיהן כסגן נשיא וחבר הנהלת PMI-ישראל, והשתתף בצוות מומחים בינלאומי שכתב את תקן ה-WBS של PMI.