הקדמה
ניהול פרויקט הינו תהליך של ייזום, תכנון וביצוע משימה מוגדרת על ידי ארגון, במסגרת תכתיבי איכות, תקציב ולוחות זמנים מוגדרים.
פרויקט הינו מושג כוללני, גנרי –להקים מערכת מיחשוב חדשה ולשפץ דירת מגורים, שניהם פרויקטים, אלא שהאחד אינו דומה למשנהו.
לנהל פרויקט זאת התמחות אך כדי להצליח בו, לא מספיק לרכוש את המיומנות ולהתנסות צריך גם את התכונות הניהוליות והאישיות המתאימות.
מאמר זה יציג כשל אופייני לעולם המושגים של ניהול פרויקטים, כמו גם לעולם הניהול בכלל. האירוע אותנטי.
פרויקט אוטומציה – פיתוח רובוט ללא צורך?
בית אריזה גדול החליט לפתח רובוט אשר ׳ישתלב׳ במערך הייצור.
ה׳תפקיד׳ שיועד לרובוט היה לערום קרטונים של פרי על משטחים בצורה כזו שהקרטונים יהיו מונחים אחד על השני (שתי וערב). הקרטונים הגיעו על 3 מסועים שונים במקביל. נציין שהקרטונים שהיו במשקלים שונים הגיעו בסדר אקראי, אבל היה צורך לערום כל משקל על משטח משלו.
צוות ההיגוי לפרויקט הגדיר את המטרות במדויק, הגיש הערכת תקציב וההנהלה אישרה את הפרויקט. (נציין שהתקציב היה גבוה מאוד).
אחרי כמעט שנתיים, הכניסו את הרובוט לעבודה בקול תרועה וששון. 2 הפועלים שביצעו עד כה את העבודה באופן ידני, נשלחו למחלקות אחרות בבית האריזה.
אחרי יומיים….. תקלה.
הזעיקו את 2 הפועלים המיומנים להמשיך לבצע את העבודה ידנית וכמו כן את המהנדסים, הטכנאים והמתכנתים.
יום-יומיים והבעיה נפתרה.
עוד יום עבודה רגיל ושוב תקלות. ושוב מזעיקים את כל הנוגעים בדבר.
אחרי מספר ניסיונות נוספים, בסופו של דבר, מישהו עשה את החשבון שעבודה שעד היום עשו אותה שני פועלים מתבצעת עכשיו על-ידי 2 פועלים, 2 מתכנתים, אלקטרונאי, מהנדס ו….. רובוט.
עוד שבועיים והרובוט אוחסן אחר כבוד במחסן והכל חזר לקדמותו.
אוטומציה בכל מחיר ? כשל ניהולי?
ניתוח
פרויקט האוטומציה הושלם. המערכת החלה לעבוד ואז התגלו ליקויים בתפקוד הרובוט.
ההיגיון מחייב שבפני ראשי הפרויקט – מתכנניו ולקוחותיו – עמדו שתי ברירות: להעריך את עלות הטיפול בליקויים ולהקצות התקציב הדרוש כדי לעמוד בצורך. או, לוותר על הפרויקט ולהשבית את המערכת.
ככל הידוע, הנוגעים בדבר בחרו בדרך השנייה.
המציאות מלמדת שברוב המקרים פרויקטים (אפילו שיפוץ בייתי) נגררים אל מעבר למתוכנן וכך גם העלות העוברת על התקציב המקורי. כמובן שיש משמעות גדולה להיקף החריגה אבל להחליט שאפשר לוותר על מערכת שעלתה בממון רב ואפשר להסתדר בלעדיה, רק משום שבעצם צריך היה להשקיע עוד 10% מן העלות המקורית, זה נשמע לא הגיוני.
הערכת סיכונים, בקרה ו"חריגות" – מושגי מפתח בניהול פרויקט
תקלות, שיבושים וסטיות הנם "חלק מן החיים" ולכן צריך, בכל תכנון, לקחת אותם בחשבון.
המשמעות היא שהצדדים המעורבים – המתכננים, המבצעים והלקוחות הסופיים שיקבלו את המוצר – צריכים לקיים הערכת סיכונים ובקרה שוטפת ולחשוב על פתרונות, ועל כך צריכה להיות הסכמה מראש.
כאשר הדבר לא נעשה ובתהליך הפרויקט מאתרים חריגה, צריך לעצור לדון ולסכם על ההמשך. זיהוי חריגה וסטייה מן התכנון צריך לשמש "סימן מעיד" לתקלה יותר מהותית, כפי שקרה בביטוח לאומי. ראה מאמר שפרסמנו ב"זרקור" מחודש יוני 2018 פרויקט המחשוב בביטוח לאומי – כך לא מנהלים פרויקט.
פרויקט איננו מסתיים במועד "מסירת המפתח" ללקוח ותשלום אחרון לספק. בכל פרויקט קיים השלב של "הרצה" ניסיונית ותקופת אחריות, וגם בשלב הזה עשויות להתגלות תקלות. חריגות אלה יש להסדיר עוד בשלב התכנון המקורי, אחרת יכול לחזור על עצמו האירוע המתואר לעיל.
תגיות: הערכת סיכונים, ניהול פרויקט