מדוע פרויקטים ב-IT עדיין נכשלים?

בעבר, לכישלונות של פרויקטים ב-IT היו השלכות תקציביות גבוהות והם כוונו בעיקר למגה פרויקטים של מאות שנות אדם, מאות מיליוני דולרים ולוחות זמנים של חמש שנים ומעלה. אבל כישלונות ה-IT היום הם לעתים קרובות בעלי אופי שונה מאשר בעבר. מתודולוגיות כמו אג'ייל, devops ו-continuous delivery שינו את האופן שבו IT מטפל בפרויקטים.

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

אותות האזהרה

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

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

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

הדוגמה לעיל ליישום מערכת CRM אינה בודדה. הדו"ח השנתי של ארגון ה-PMI ל-2017: Pulse of the Profession מצא כי:
● 28% של היוזמות האסטרטגיות נחשבו לכישלונות מוחלטים.
● כ-37% מתוך למעלה מ-3,000 אנשי מקצוע בתחום ניהול הפרויקטים שהגיבו ציינו כגורם לכישלון את היעדרם של אבני דרך ויעדים ברורים ו/ או ניתנים להשגה בבירור, כדי למדוד את ההתקדמות.
● 19% הצביעו על תקשורת גרועה.
● 18% על היעדר תקשורת עם ההנהלה הבכירה.
● 14% זיהו את התנגדות של העובדים.
● 9% הצביעו על מימון חסר.

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

גורמים לכישלון

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

סקר ה-Digital Digital IQ של PwC 2017 Global Digital IQ Survey, סקר 2,216 מנהלי עסקים ומנהלי IT מ-53 מדינות ושאל אותם מה מעכב שינוי דיגיטלי:
● 64% מהנשאלים אמרו כי חוסר שיתוף הפעולה בין ה-IT לבין העסק הוא האשם.
● 58% ציינו את התהליכים הלא-גמישים או איטיים.
● 41% ציינו חוסר שילוב של הטכנולוגיות חדשות עם קיימות.
● 38% הצביעו על טכנולוגיות מיושנות.
● 37% דיווחו על חוסר כראוי צוותים מיומנים.

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

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

חברת המחקר IDC, מעריכה כי 35%-30% מהפרויקטים של IT יכולים להיחשב ככישלונות, ומייחסת את הכשלים לשינויים בסדרי העדיפויות העסקיים או במטרות. כלומר, הטכנולוגיה עובדת בסדר אבל אינה מספקת את התוצאות הרצויות.

אג'ייל ואוטומציה כפתרון אפשרי

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

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

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

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

האם סיכוני הכישלון נשארים?

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

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

בינתיים, שבירת החומות הוורטיקליות בין היחידות העסקיות וה-IT יכולה להוסיף סיכון לכישלון הפרויקט. כשיותר ויותר טכנולוגיה ממומנת מתקציבי היחידות העסקיות ולא מקופת ה- IT (לפי הסקר של PWC כ-68% מההוצאות על טכנולוגיה מקורן מחוץ לתקציב ה- IT), מנהלי היחידות העסקית יכולים להחליט ולאמץ טכנולוגיות ללא קשר אם הם מבינים לחלוטין את משמעות השילוב שלהם עם מה שקיים בארגון.