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

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

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

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

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

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

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