למה פרויקטים נכשלים?

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

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

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

המקרה הזה מתיישב עם נתונים שפרסם ארגון PMI העולמי, שקבע שב-37% מהפרויקטים שנכשלו (שהם 28% מכלל 3,000 הפרויקטים שנעשו בארגונים גדולים שהשתתפו בסקר), הסיבות היו חוסר תקשורת בין ה-IT ללקוחות הסופיים, חוסר מקצועיות של העובדים ותקלות אחרות בלתי צפויות.

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

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

מה באשר לפרויקטים מוצלחים?

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

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

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