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

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

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

ניתוח אירועים
בנוסף למאות השאלונים, ארבע קבוצות מיקוד וראיונות אישיים, ביקשו החוקרים להעמיק את אפיון מונחי הצלחה וכישלון פרויקט על ידי ניתוח קפדני של שני מקרים ידועים של פרויקטים שנכשלו ושני פרויקטים שהצליחו. למטרות השוואה, שימשו קריטריוני ההצלחה מהמחקר (ראה חלק א' של המאמר) בנוגע לפרויקטי IT כדי ליצור את טבלת "פוטנציאל ההצלחה". קריטריוני ההצלחה קבלו משקל יחסי, בהתבסס על הקלט ממחקר מנהלי IT. הקריטריון החשוב ביותר- "מעורבות הלקוח", קיבל 19 " נקודות הצלחה". הפחות בחשיבותו: "צוות עובד קשה, וממוקד"- קבל 3 נקודות. שני קריטריונים חשובים- "ציפיות ריאליות" ו-"אבני דרך בשלבי ביניים תכופים"- קבלו 10 ו-9 נקודות בהתאמה. לבסוף, כפי שיפורט בהמשך, ניתנה הערכה לכל אחד מהמקרים הנחקרים.

מקרה ראשון - משרד התחבורה בקליפורניה (DMV)
בשנת 1987, החל משרד התחבורה בקליפורניה פרויקט מהותי להנפקה עדכנית של רישיונות נהיגה ומספרי רכב. בשנת 1993, לאחר הוצאה של 45 מיליון דולר, בוטל הפרויקט.
על פי דוח מיוחד של משרד התחבורה, המניע העיקרי לפיתוח היישום המחודש היה אימוץ טכנולוגיה חדשה. המשרד הצהיר בגלוי: "היעד הממוקד של הפרויקט משנת 1987 היה להשתמש בטכנולוגיה מודרנית לתמיכה בייעוד משרד התחבורה, ולתמוך בגידולו על ידי מיצוב אסטרטגי של המשרד בסביבת עיבוד נתונים התומכת בתגובה מהירה לשינויים". בנוסף, על פי משרד התחבורה, "השלבים השתנו מספר פעמים, אך הגורמים הטכניים במשרד אף פעם לא היו בטוחים ביישומיות שלהם...".
לפרויקט לא היה חישוב כדאיות כלכלית, לא הייתה תמיכת הנהלה בכירה, לא הייתה מעורבות מצד הלקוחות המשתמשים, התכנון היה גרוע, תכנון המפרטים לא היה מספק והיעדים לא היו ברורים. לפרויקט גם לא הייתה את תמיכת הנהלת גופי המידע של המדינה.
לא מדובר כאן על פרויקט של טכנולוגית הנעת טילים. ישנם יישומים הרבה יותר מסובכים מאשר רישיונות נהיגה ולוחיות רישוי. אבל בשל פוליטיקה פנימית, יעדים לא ברורים, ותכנון גרוע, הפרויקט נידון לכישלון כבר מתחילתו.

מקרה שני - American Airlines (AA)
בתחילת 1994, חברת AA סיימה את התביעה מול החברות בדג'ט, מלונות מריוט וכן מלונות הילטון, לאחר שפרויקט CONFIRM בהיקף של 165 מיליון דולר, לשכירת רכבים והזמנת חדרי מלון, התמוטט לתוהו ובוהו.
הפרויקט נכשל כי היו יותר מדי טבחים- והתבשיל הקדיח. ההנהלה הבכירה- לא רק תמכה בפרויקט- אלא גם הייתה מעורבת באופן פעיל. כמובן, כדי שפרויקט בהיקף כזה יכשל, צריך שיהיו סיבות רבות. סיבות עיקריות נוספות היו ריכוז דרישות שאינו מלא, חוסר מעורבות משתמשים, ושינויים בלתי פוסקים לדרישות ולמפרטים.

מקרה שלישי - Hyatt Hotels
בעוד מריוט והילטון בודקים את מערכת ההזמנות הכושלת שלהם, השיקה חברת מלונות היאט מערכת טובה משלה. היום, אתה יכול להתקשר מכל טלפון סלולארי במטוס בגובה 10 ק"מ, לבצע הזמנה לחדר במלון היאט, לתאם את הסעת החינם משדה התעופה, ולאסוף את המפתחות משולחן הקבלה המהירה. מערכת הזמנות חדשה זו סופקה לפני הזמן המיועד, עמדה בתקציב- וספקה תכונות נוספות ביחס למפרט, וזאת בפחות מ- 15 מיליון דולר. היה שימוש בסביבת פיתוח מודרנית ופתוחה, עם בסיס נתונים Informix ומערכת TUXEDO לניטור פעולות, בחומרה מבוססת Unix.
להיאט היו את כל המרכיבים הנכונים כדי להצליח: מעורבות המשתמש, תמיכת הנהלה בכירה, הצהרה ברורה של הדרישות, תכנון הולם, ואבני דרך תכופות.

מקרה רביעי - Banco Itamarati
לאחר שנה של הכוונה אסטרטגית מחודשת, הציג הבנק הפרטי הברזילאי Banco Itamarati, גידול נטו ברווחיות של 51% ועלה מהמקום ה-47 למקום ה-15 ברשימת הבנקים בברזיל. שלשה גורמים מהותיים תרמו לשינוי זה: ראשית, היה לבנק חזון ברור עם יעדים מפורטים ומתועדים. שנית, רמת המעורבות top-down אפשרה לבנק להישאר בנתיב הנכון. ולבסוף, הבנק הציג גידול עקבי ומדיד בתוצאות בשלבי התכנון והיישום.
היעד הברור של הבנק היה להיות אחד מחמשת הבנקים הפרטיים הגדולים בברזיל עד שנת 2000. יעדים נוספים כללו שמירת קשר קרוב עם הלקוחות כדי לשפר ולשמר את הבנת צרכיהם, הצעת פתרונות פיננסיים תחרותיים, הבטחת שביעות רצון לקוחות, ולבסוף- הצגת תוצאות רווחיות לבעלים. יעדים אלו שולבו בתוך תוכנית אסטרטגית שזיהתה תוצאות מדידות ברורות ואחריות אישית להשגתם.
התוכנית האסטרטגית שלהם הפכה את הטכנולוגיה למפתח עיקרי של האסטרטגיה העסקית. הם השתמשו במוניטור GRIP OLTP כדי לבצע אינטגרציה של מרכיבי תוכנה. על פי המנהל האחראי לפיתוח הארגוני: "אנו אחד הבנקים הראשונים ליישם ארכיטקטורת לקוח- שרת, המשיאה את הפוטנציאל של אינטגרציית מרכיבים". מנהיגות ההנהלה, תוכנית מתוקשרת היטב, וצוות רב-גוני מיומן, נתנו את הבסיס לבנק להשיג את היעדים ארוכי הטווח, עוד לפני לוח הזמנים.
סיכום חקר האירועים
סיכום "נקודות ההצלחה" בכל פרויקט מופיע בטבלה הבאה:

עם 10 נקודות בלבד, פרויקט משרד התחבורה בקליפורניה היה באופן מעשי חסר סיכוי להצליח. עם 100 נקודות הצלחה, מערכת ההזמנות של היאט הייתה עם כל המרכיבים להצלחה. עם 29 נקודות בלבד, מערכת CONFIRM הייתה עם מעט סיכוי להצליח. ועם 85 נקודות, אולי לא בצורה בטוחה כמו היאט, התחיל בנק ITAMARATI את הפרויקט בסבירות הצלחה גבוהה.

הגשר להצלחה
מחקר זה איננו מעמיק דיו כדי לספק פתרון אמיתי לבעיה הנוכחית הסבוכה כל כך, של אחוזי כשל בפרויקטים. פרויקטי יישומים בתוכנה הם באמת בלב המערבולת. כדי לעשות סדר במהומה זו, אנו זקוקים לבחון מדוע פרויקטים נכשלים. בדיוק כמו גשרים, כל כשל תוכנה חייב להיחקר, להילמד, להיות מדווח ולחלוק את הניסיון הנרכש ממנו.
כיוון שזהו תוצר רעיונות מנהלי IT, טבלת " פוטנציאל ההצלחה" הינה כלי שימושי לחיזוי פוטנציאל ההצלחה של פרויקטים, או להערכת כישלון פרויקטים.
המחקרים של Standish Group גם מצביעים שמסגרות זמן קטנות יותר לשלבים השונים, עם מסירה של תוצרים מוקדם ולעיתים תכופות, תגדלנה את שיעור ההצלחה. מסגרות זמן קצרות יותר מתבטאות בתהליך איטרטיבי של תכנון, אב טיפוס, פיתוח, בדיקה והטמעה של מרכיבים קטנים. תהליך זה נקרא תוכנה "גדלה" ( פיתוח אינקרמנטלי), במקום המונח הישן של "פיתוח" תוכנה. תוכנה גדלה נמסרת מוקדם יותר ללקוח, לכל מרכיב יש משתמש או קבוצת משתמשים , והציפיות הינן אוסף סדור וריאלי. בנוסף, לכל מרכיב תוכנה יש תכולה ברורה ואוסף יעדים. מרכיבי התוכנה ופרויקטים קטנים נוטים להיות פחות מורכבים. הפיכת הפרויקט לפשוט יותר הינו מאמץ כדאי, כיוון שהמורכבות גורמת רק לבלבול ועלויות גדלות.
ישנו היבט נוסף סופי שצריך להילקח בחשבון בכל רמה של כשלון פרויקט. כל הצלחות מעוגנות במזל או בכישלון. אם התחלת עם מזל, לא תלמד מאומה חוץ מגאווה. אם תתחיל עם כישלון ותלמד להעריכו, תלמד גם להצליח. הכישלון מעודד ידע. מתוך הידע תרכוש חוכמה, ורק עם חוכמה תוכל להיות מצליח באמת.
בגיליונות הבאים נסקור מחקרי המשך של סטנדיש, ביניהם מחקר ממרץ 2003, בו מציגה סטנדיש גידול של 50% בהצלחת פרויקטים.

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