סקירת מחקרה של חברת הייעוץ סטנדיש משנת 1995:
כאוס

מאת אבי רוזנברג, naetroze@012.net.il, PMP

חלק א' - הקדמה
למרות שחלף למעלה מעשור מאז פרסומו המקורי, ממשיך להיות מחקרה של קבוצת סטנדיש (www.standishgroup.com) כאוס - הנערך אחת לשנתיים מאז שנת 1994, אבן דרך בהבנת תהליכי הצלחת וכישלון פרויקטים בכלל ופרויקטי IT בפרט. עקב היותו חופשי להורדה ונגיש ברשת האינטרנט, צוטט המאמר המקורי משנת 1995 פעמים רבות הן במחקרים אקדמיים והן במאמרים מקצועיים ולטענת החברה, זהו המחקר המצוטט ביותר בתעשיית ה IT. אחד הממצאים החשובים במאמר, הוא חריגת התקציב הממוצעת בגודל 189% בפרויקטים "מאותגרים", כלומר פרויקטים שאינם הולכים בתל"ם (תכולה, לו"ז, משאבים). מה משמעות חריגה זו? כיצד ניתן להתייחס אליה ביחס לשיעורי הצלחה מקומיים? במאמר זה, הראשון מבין סדרת מאמרים בנושא, נסקור את מחקרה של חברת סטנדיש וננסה להדגיש את הממצאים הסטטיסטיים המרכזיות בו. בגיליונות הבאים, נסקור את ניתוחי המקרים וכן מחקרי המשך של הקבוצה.

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

הפתיח למחקר, המובא להלן מתבסס על מסמך המשווה בניית גשרים לפתוח תוכנה, שהוציא בשנת 1986, אלפרד ספקטור, נשיא חברת Transarc. סיכום המסמך טוען כי: גשרים בדרך כלל נבנים על פי לוח זמנים, בתקציב, ולא מתמוטטים. מצד שני, תוכנה אף פעם לא מפותחת בזמנים או במסגרת התקציב. בנוסף, היא תמיד כושלת במהלך ההפעלה (האמת- גם בבנין גשרים יש חריגות בזמן, בתקציב וחלק גם מתמוטטים).
אחת הסיבות להצלחה בבנין גשרים הינה עקב התכנון המפורט. ואז- התיכון מוקפא, ולקבלן אין כמעט גמישות בשינוי המפרטים. אולם, בעולם הדינאמי של היום, הקפאת תצורה איננה תואמת לשינויים המהירים בצרכים העסקיים. לכן צריך להשתמש במודל גמיש יותר. זה ההיגיון המסתתר מאחורי כשלי פיתוח.
אולם יש עוד הבדל בין כשלי פיתוח תוכנה לבין כשלי בנין גשרים, חוץ מ-3,000 שנות ניסיון. כאשר גשר מתמוטט, מתקיימים בדרך כלל תחקירים ומוכנים דוחות. זה לא המצב בתעשיית המחשוב, היכן שכשלים לעיתים מטויחים, מתעלמים מהם, או שמקבלים זאת כמובן מאליו ובלתי נמנע. עקב כך, אנו ממשיכים לעשות אותן טעויות שוב ושוב.
עקב כך, ניסתה קבוצת סטנדיש לזהות במחקרה על פרויקטים:

• את ההיקף של כשלי פרויקטי תוכנה.
• את הגורמים העיקריים הגורמים לפרויקטי תוכנה להיכשל.
• את המרכיבים העיקריים היכולים להקטין כשלי פרויקטי תוכנה.

היסטורית כשלים
נכון ל- 1996, בארה"ב הוצאו מדי שנה יותר מ- 250 מיליארד דולר על פיתוחי IT, ביותר מ- 175,000 פרויקטים. פרויקט פיתוח ממוצע עבור חברה גדולה נע סביב 2.3 מיליון דולר, בעבור חברה בינונית- 1.3 מיליון דולר ובעבור חברה קטנה, כ- 400 אלף דולר. רבים מפרויקטים אלו נידונו לכישלון. פרויקטי תוכנה מנוהלים בכאוס, ואין אנו יכולים לנהוג יותר כמו שלשת הקופים- לא שומעים, לא רואים, לא מדברים.
המחקר הראה כי 31% מהפרויקטים יבוטלו טרם השלמתם. 52% מהפרויקטים יעלו 189% יחסית להערכה המקורית. וזהו רק קצה הקרחון. עלות הפרויקטים שלא בוצעו, והחלו את ביצועם כפרויקטים כושלים, הינו בתחום טריליוני דולרים. לדוגמה, בדנוור, קולורדו, הכישלון במערכת הטיפול במזוודות נוסעים בשדה התעופה עלה לעיר יותר ממיליון דולר ליום!
המחקר העריך כי ב- 1995 הממשל וחברות אמריקאיות יבזבזו 81 מיליארד דולר על פרויקטי תוכנה שיבוטלו. הם ישלמו עוד 59 מיליארד דולר עבור פרויקטים שיושלמו, אבל חרגו בתקציב. סיכון הינו גורם מובנה בעת שימוש בחדשנות טכנולוגית, אולם רבים מהפרויקטים עסקו בנושאים פשוטים יחסית כגון בסיס נתונים לרישיונות נהיגה, ערכת חשבונאות חדשה או מערכת זימון תורים.
בצד ההצלחה, יש כ- 16% פרויקטים שיושלמו בזמן ובתקציב. אבל בחברות גדולות, מספרים אלו נמוכים יותר- רק 9%. וגם בעת ההשלמה, הביצועים הינם צל חיוור של הדרישות המקוריות. יש להם רק 42% מהדרישות המקוריות. בחברות קטנות- המצב טוב יותר- 78% מהפרויקטים יסתיימו עם 74% מהדרישות המקוריות.
מידע זה אינו מלבב כלל, ובאמת- 48% ממנהלי IT במחקר אמרו כי הם חשים שיש הרבה יותר כשלים מאשר חמש שנים קודם למחקר. החדשות הטובות הן ש- 50% מהם אמרו שמספר הכשלים דומה או נמוך יחסית לתקופה של חמש שנים ועשר שנים קודם למחקר.

שיטת המחקר
תוצאות המחקר, שנערך על ידי קבוצת סטנדיש, מתבססות על ממצאים עיקריים ומספר ראיונות אישיים. המדגם כלל חברות בכל גודל- גדולות, בינוניות וקטנות, בענפי תעשיה שונים- בנקאות, קרנות הלוואות, ייצור, מסחר, קמעונאות , ביטוח רפואי, ביטוח, שירותים, ואף ארגונים ציבוריים- ממשלתיים ומקומיים.
המדגם כלל 365 מגיבים מתוך 8,380 פניות. בנוסף, המחקר הוביל 4 קבוצות מיקוד ומספר רב של ראיונות אישיים, שבאו בכדי לתת תוכן איכותי לתוצאות המחקר.
לצרכי המחקר, פרויקטים סווגו לשלש קטגוריות:
1. פרויקט מוצלח- עמד בזמנים ובתקציב, עם תכולה כפי שהוגדרה בתחילה.
2. פרויקט בקשיים- הפרויקט הושלם ומתפקד, אבל חרג בתקציב, חרג בזמנים, ולעיתים מציע תכולה רדודה יחסית לאופיין הראשוני.
3. פרויקט כושל-הפרויקט בוטל בשלב מסוים של מחזור חייו.
סה"כ, אחוז ההצלחה היה 16%, כאשר פרויקטים בקשיים היו 52% , ופרויקטים כושלים סיפקו 31%.

סטטיסטיקת הכשלים
לפילוח הסיבות, חולקו החברות ל-3 קבוצות. גדולות- עם הכנסות של יותר מ- 500 מיליון דולר בשנה. בינונית- הכנסות שנעות בין 200 ל- 500 מיליון דולר בשנה של הכנסות, וקטנות- הכנסות בין 100 ל- 200 מיליון דולר לשנה. אחוזי הכשל היו לא נעימים בחברה מכל גודל שהוא. רק 9% מהפרויקטים בחברות גדולות היו מוצלחים. מספר מדהים של 61% מהפרויקטים בחברות גדולות היו בקשיים, בהשוואה ל- 47% בחברות בינוניות או 50% לחברות קטנות. הנתון הגבוה ביותר של 37% כשלים וביטולים היו בחברות בינוניות, בהשוואה ל-29% בחברות גדולות או 21% בחברות קטנות.

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

גלישה תקציבית
תוצאות דומות היו עבור גלישות תקציביות, גלישות בזמנים, וכשל של היישום לספק את התכונות הנדרשות.עבור פרויקטים בקשיים ופרויקטים כושלים, כמעט שליש מהם גלשו בתקציב ב-150 עד 200%.
הממוצע לכל סוגי החברות היה של 189% גלישה תקציבית יחסית להערכה הראשונית. הגלישה הממוצעת הינה 178% עבור חברות גדולות, 182% עבור חברות בינוניות, ו-214% עבור חברות קטנות.

גלישות בזמנים
עבור אותו שילוב של פרויקטים בקשיים ופרויקטים כושלים, יותר משליש גם חוו גלישה בזמנים של 200 עד 300%. הממוצע היה גלישה של 222% בזמן יחסית להערכה המקורית. בעבור חברות גדולות הממוצע הינו של 230%. עבור חברות בינוניות הממוצע 202% , ועבור חברות קטנות, הממוצע היה 239%.

ביצועים לא מספקים
עבור פרויקטים בקשיים, יותר מרבע הושלמו עם 25% עד 49% מהביצועים והפונקציות שהוגדרו מלכתחילה. בממוצע, רק 61% מהביצועים שהוגדרו מלכתחילה סופקו בסופו של דבר. לחברות הגדולות יש את התוצאות הגרועות ביותר כאשר רק 42% מהדרישות סופקו לבסוף.
עבור חברות בינוניות, האחוז הינו 65%. ועבור חברות קטנות, האחוז הינו 74%.

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

קבוצות מיקוד
לתמיכה בממצאי הסקר, קיימה קבוצת סטנדיש גם 4 קבוצות מיקוד, בהן מנהלי IT של חברות מובילות. המשתתפים הגיעו ממגוון תעשיות, כולל ביטוח, גופים ממשלתיים וציבוריים, עסקי מסחר וקמעונאות, גורמי ייצור ומתן שירותים. שתיים מקבוצות המיקוד התכנסו בבוסטון, שתי האחרות- בסן-פרנציסקו. בכל קבוצת מיקוד היו כ-10 משתתפים בממוצע, סה"כ 41 משתתפים. המטרה של קבוצות מיקוד אלו הייתה לחדד את התפיסות בנוגע לכשלי פרויקטים. בנוסף, התקיימו ראיונות אישיים עם מנהלי IT שונים. כמה מהערותיהם אכן האירו את מגוון הבעיות המלוות פיתוח פרויקטים.
הערות רבות חזרו על ממצאי הסקר הנרחב: " יש לנו 500 פרויקטים. אף אחד איננו עומד בלוחות הזמנים או בתקציב. בשנה זו, 40% יבוטלו" אמר סגן נשיא למערכות מידע בחברת תרופות.
הערות אחרות נגעו ישירות בסיבות הכישלון. מנהל IT בחברת ציוד רפואי מובילה אמר: "זהו בעצם מצב מחשבתי קבוע, לפיו בלתי אפשרי להביא הנהלה, הן בהיבט מקומי והן בהיבט כלל עולמי, להסכמה על סט כללים לניהול הפרויקטים...מדובר באתגר כשלעצמו, מפני שבמספר מקרים, כללים אלו יפעלו לטובת החברה, ולא בהכרח לטובתם. אתה צריך לרכוש את הסכמתם – אחרת תיכשל, ואז לא תהיה משמעות לעובדה אם מדובר בפרויקט גדול או פרויקט קטן." מנהל בחברה ממשלתית, הוסיף:" כנראה 90% מהיישומים בפרויקט כושלים עקב פוליטיקה!". מתכנתת בחברת תקשורת, הציעה הערה שנונה נוספת: "לפעמים צריך לקבל החלטות שאינך אוהב. אפילו נגד טבעך אתה. אתה אומר,מילא- זה מוטעה, אבל אתה מקבל החלטה זו. זה כמו להכות בפטיש על אצבעך. זה כואב!". מנמ"ר בבית חולים, העיר לגבי גורמים חיצוניים התורמים לכשלי פרויקטים: "בעייתנו הגדולה ביותר היא לתעדף קדימויות"..."רק היום בצענו אירגון מחדש. מהלך זה צורך את כל המשאבים. והאתגר הגדול ביותר העומד בפניי הוא איך להסביר להנהלה הבכירה שמשך הפרויקט באמת תואם לתכנון, אבל עקב האירגון מחדש- נזדקק לעוד 6 חודשים בפרויקט זה, עקב השינוי בסדרי העדיפויות". מנמ"ר בקרן השקעות הוסיף "שינויים, שינויים, שינויים- הם הורסי הפרויקטים האמיתיים".
הערות רבות כללו הומור שחור; " משתמשי קצה חסרי יכולת" אמר מנתח יישומים בגוף בנקאי ומתכנת בחברת מוצרי צריכה הוסיף " כאשר הפרויקט החל להיכשל, ההנהלה התייצבה מאחוריו- הרחק הרחק מאחוריו".
ההערה שהבליטה יותר מכל את התוהו ובוהו בפרויקטי פיתוח באה ממנהל פרויקטים בחברת ביטוח: "הפרויקט איחר בשנתיים. שלושים אנשים עבדו בפרויקט, ולבסוף סיפקנו יישום שהמשתמש לא היה צריך - הם הפסיקו למכור את המוצר שנה קודם."
כפי שניתן לראות, התיאורים האיכותיים שנתקבלו בראיונות, חיזקו את ואף הוסיפו עומק להבנת ממצאי המחקר.

סיכום חלק א'
בחלק הראשון של מאמר זה הצגנו נתונים כמותיים ואיכותיים מתוך מחקרה המקורי משנת 1994 של קבוצת סטנדיש הנקרא כאוס. המחקר מציג ממצאים לפיהם כשליש מפרויקטי התוכנה ייכשלו, חצי לא יעמדו בלוח הזמנים ו/או בתקציב ובתכולה והשאר ייחשבו כהצלחה.
בגיליונות הבאים, נסקור את ניתוחי המקרים וכן מחקרי המשך של הקבוצה.
______________________________________________
הכותב, אבי רוזנברג, PMP (MBA, B.Sc.), בעל ניסיון של למעלה מעשרים שנה בתחום הפיתוח והתחזוקה בחיל האוויר. כיום מרצה במסגרות שונות על ניהול פרויקטים, ויועץ בתחום פרויקטים ולוגיסטיקה