המסר העיקרי הוא - פרויקטי IT רבים מדי נכשלים מסיבות שונות כשבראשן: התבססות על נתונים שגויים, הערכות שגויות, סיבוכים טכנולוגיים, בעיות כוח אדם וחוסר בידע ניהולי וכלכלי של המנמ"ר.
הנתונים לגבי כשלון פרויקטים ברורים ורבים: רק 28% מהפרויקטים שיצאו לדרך ב-2004 הגיעו לסיום מוצלח (יחסית ל-34% בשנת 2003), 18% מהפרויקטים הופסקו (לעומת 15% ב-2003) ו-51% עדיין "חיים", אבל כבר חרגו מהמסגרות שנקבעו (על פי נתוני סקר Standish Group).
התייחסות בסיסית לבעיה מתחילה בהגדרות, כהגדרת "כשלון": האם פרויקט ש"נכשל" הוא פרויקט שהופסק מאחר ולא עמד בתנאי התקציב ולוחות הזמנים שנקבעו? האם ניתן לקבוע בבירור כי פרויקט שבנקודת זמן מסוימת אינו עונה על הציפיות הוא פרויקט ש"נכשל", או שיש לחכות להמשכו (בהשקעת זמן ותקציב נוספים, שלא תוכננו מראש) ו/או להורדתו הסופית כדי להכריז עליו ככזה? מי ידביק לו רשמית את תווית ה"כשלון" ואיזו מחלקה, או דרג בארגון, יהיו אלו שיחליטו האם להמשיך או לעצור ולפי אלו קריטריונים יקבעו זאת?
הסיבות לכישלון
כח עליון? טעויות אנוש? עד עצם היום הזה, לא גיבשו האנליסטים הסכמה מלאה על הסיבות העיקריות לכשלון: על פי הערכת Gartner, למשל, התבססות חברות באופן שגרתי על נתונים "פגומים" (לא מדוייקים / עדכניים) בתהליך קבלת החלטות, היא הגורם העיקרי לכישלון פרויקטים רחבי היקף ועתירי השקעה בתחומי IT (כרבע מהחברות הבינלאומיות הגדולות עובדות עם נתונים באיכות ירודה), ואילו PMI מונה כ-15 סיבות אפשריות לכשלון פרויקטי IT, ביניהן הערכות שגויות, סיבוכים טכנולוגיים ובעיות כח אדם.
את הסיבות הנפוצות ביותר לכישלון בפרויקטי IT ניתן לחלק למספר תחומי כשל, על פי PMI: חוסר תכנון ראשוני (או תכנון ראשוני בלתי מספק), בעיות הצצות במהלך הפרויקט, גורמים טכנולוגיים, גורמים אנושיים וגורמים ארגוניים שונים כמו חילופים בהנהלת הארגון ושינוי סדרי עדיפויות ארגוניים הנובעים מכך.
חוסר בידע ניהולי וכלכלי אצל חלק גדול של המנמ"רים, מהווה סיכון גדול במיוחד לכשלון פרוייקטים. אם נוסיף לכך את העובדות כי פרויקט IT שנכשל מקצץ בתקציבים הנותרים למחשוב, פוגע באמינותו המקצועית של המנמ"ר ובנכונות ההנהלה להפקיד בידיו פרויקטים נוספים, נראה כי למנמ"ר יש את כל הסיבות כדי לעשות כל שביכולתו, על מנת לצמצם בצורה ניכרת את הסיכויים לכשלון.
נקודות אזהרה
הערכות מאולצות, ציפיות מוגזמות ובחירות שגויות הן חלק מהדוגמאות לסמני אזהרה ונקודות מבחן, שמודעות להן ותגובה נכונה תצמצם סיכוי לכישלון פרויקט. נורות אזהרה נוספות יכולות להיות כמות שעות עבודה חריגה, ירידת מורל בקרב העובדים ובעיות תקציביות.
ניתן לצמצם את הסיכוי לכישלון באמצעות הכנה נכונה של השטח, מיצוי יעיל של תוכנות לניהול הפרויקטים, תרגול על יבש ומעקב צמוד טכנולוגי, תקציבי ואנושי.
האם כשלון בפרויקט IT מחויב מציאות? למרות שעל פי הערכת IT Cortex, לפרויקט יש סיכויי-כשלון גדולים יותר מסיכויי-הצלחה, ניתן לומר בפה מלא כי ישנן דרכים לצמצום הסיכויים הנזקים והכשלון בפרויקטי IT. הערכות ראשוניות זהירות, בחירה מתאימה של מתכננים ומבצעים, גמישות מחשבתית והבנה לדעת מתי "להוריד את המסך" על פרויקט שגורר אחריו חריגות תקציביות ואין לראות סיום מוצלח שלו בעתיד הנראה לעין הן אחדות מהדרכים.
כללים במשחק
להלן מספר מושגים בתחום ניהול פרויקטים שכדאי להכיר: אילוץ הוא מגבלה החלה על הפרויקט. למשל, על תאריך התחלת הפעילות או סיומה. MSO הוא התאריך בו חייבים להתחיל את הפרויקט. MFO הוא התאריך בו חייב לסיים. ALAP פירושו מאוחר ככל שניתן. ASAP, מוקדם ככל האפשר. CPM (Critical Path Method), מתודולוגית הנתיב הקריטי, נחשבת לסטנדרט המסורתי של ביצוע ובקרת פרויקטים. CCPM (ר"ת Critical Chain Project Managemen)היא "שרשרת קריטית" בפרויקט המוגדרת כרצף הפעילויות-התלויות הארוך ביותר שבפרויקט. CMM ( (ר"ת Capability Maturity Model) היא שיטה לתיאור ניהול ארגון תקין הכולל התייחסות לניהול פרוייקטים. Knowledge Gap PM היא גישה המתבססת על ההנחה, כי לפער הגדול בין ההערכה הניתנת (למשל הערכת זמן לשלב בפרויקט) למציאות, יש חלק גדול בכישלון הפרויקט ומטרתה לצמצם פער זה ככל הניתן.
פתרונות מובנים בתוכנות:
אלו כמה תוכנות ניהול פרוייקטים בולטות, שיסייעו לצמצום הכישלונות: Artemis Views, הכוללת חבילת מודולים המיועדים לטיפול ומעקב אחר תוצאות בפרויקט בכל שלב; פתרון הקוד הפתוח Open Workbench לניהול פרויקטים; Project Management, מודול המסייע בניהול משותף של פרויקטים, אותו מציעה Mercury במסגרת IT Governance Center (מערכת ניהול ל-IT); מיקרוסופט מציעה גרסאות שונות של Microsoft Project ו-Microsoft Office Project, ואת Axapta, כלי המסייע בניהול פיננסי של פרויקטים, ו-Great Plains, המסייע בניהול ביצועי פרוייקטים והבטחת עמידה בתקציב; Project Portfolio Management של PlanView; P3E היא מערכת מבוססת Web המאפשרת סימולציות תכנון ואפיון, ניתוח סיכונים בהיבטי תקציב, לוחות זמנים ותכולה, של Primavera, המציעה מוצרים נוספים לבקרת תהליכים וניהול פרויקטים; Ps Next, מערכת מבוססת Web לניהול בסביבה מרובת-פרויקטים, של Sciforma.
סיכום
התעמק בפתרונות לניהול סיכונים בפרויקט. אם תהיה קשוב לסימני האזהרה ותנקוט בכל האמצעים המומלצים להלן, תצמצם במידה ניכרת את סיכויי הכשלון.
אנשים מהתחום, מוזמנים להגיב לתרום ולהוסיף...
התקציר לקוח מתוך תחקיר pCon בשם למה נכשלים פרויקטי IT?.
הרחבות, ראיונות עם מומחים, טיפים מעשיים וקישורים להעמקה ניתן למצוא בכתובת -
http://www.pcon.co.il/v5/Debrief.asp?debrief=706
למאמרים מקצועיים ואובייקטיביים נוספים של קובי שפיבק, בתחומי מידע מחשבים ואינטרנט, באתר "מאמרים" ראה - http://www.articles.co.il/author/1944
קובי שפיבק Bsc., MBA הוא העורך הראשי של תחקירי pCon ואתר pCon-line. כמי שעוסק במחשבים, על מכלול היבטיהם משנת 1976 וכן כמי שכתב וערך למעלה משמונה מאות תחקירים על כל היבטי המחשוב העיקריים, הוא נמנה על אותם אנשים בודדים בארץ ובעולם, שבאמת ובתמים, מבינים לאן הולך עולם המחשוב ומהן השלכותיו המידיות והעתידיות, על אנשים וארגונים. הוא גם פרסם מספר רב של מאמרים במרבית העיתונים הגדולים והמקצועיים, והופיע פעמים רבות בערוצי הטלוויזיה והרדיו המרכזיים. נכון להיום הוא מייעץ למרבית מנהלי המחשוב בארגונים המובילים בישראל, והוא נחשב בעיני רבים, לגורו של המחשוב העסקי.
