הצלחה וכישלון בניהול פרויקטים במערכות מידע

הפרויקט הראשון בהיסטוריה שמתועד הוא בריאת העולם – "בראשית ברא אלוהים את השמים ואת הארץ והארץ היתה תהו ובהו וחושך על פני תהום ורוח אלוהים מרחפת מעל פני המים".

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

השלבים (Milestones) מאוד ברורים – "וירא אלוהים כי טוב…ויהי ערב ויהי בוקר יום…" – עוברים לשלב הבא רק כאשר השלב הקודם הסתיים בהצלחה. אין אפיון פונקציונלי כי אין משתמשים ומסתמכים על אבולוציה. השאלה המרכזית היא האם הפרויקט הצליח?

הפרויקט שהצליח

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

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

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

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

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

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

הפרויקט שנכשל

הפרויקט הראשון המתועד שנכשל – מגדל בבל. "הבה נלבנה לבנים ונשרפה לשריפה ותהי לנו הלבנה לאבן והחימר היה להם לחומר: ויאמרו הבה נבנה לנו עיר ומגדל וראשו בשמים ונעשה לנו שם פן נפוץ על פני כל הארץ".

הדרישה בסיסית ופשוטה: "…פן נפוץ…", אך הפתרון לא ניתן למימוש: "נבנה לנו עיר ומגדל וראשו בשמים". הפתרון נבחר כי הטכנולוגיה כבר הייתה שם – לבנים, והסיבה לכישלון לפי התורה הינה: "…אשר לא ישמעו איש שפת רעהו" .

הפרויקט שנכשל החל בחודש אפריל 1999 והופסק בדצמבר 2006 לאחר השקעה כוללת המוערכת בכ-30 מיליון שקלים. הפרויקט היה חידוש של מערכת Legacy ותיקה בחברה.

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

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

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

בשלבים אלה ניתן למצוא: תיעוד מספק של תיקי עיצוב ותכנות; תיעוד של תהליכי קבלת החלטות על סביבת העבודה (Web) שנבחרה; תיעוד של קבלת החלטות על פיתוח מערכת הנעת עבודה (Workflow); פיתוח ממשקים עם מערכות חברה אחרות ועם מערכות תשתיתיות שפותחו במקביל; התמודדות מקצועית עם סביבות עבודה שונות בחברה; התמודדות עם אלמנטים טכנולוגיים חדשים לחלוטין.

בסך הכל מתקבל הרושם שיש תשתית מערכת עובדת המבצעת פונקציונליות מוגדרת כתוצר של הפרויקט.

אך למרות כל זאת לא היה ברור מי מנהל הפרויקט. האם מנהל הפיתוח = מנהל הפרויקט, או ראש האגף = מנהל הפרויקט.

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

רמות הבגרות בניהול פרויקטי מערכות מידע

* מבוסס על מודל ה-CMMI של אוניברסיטת Carnegie-Mellon.

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

מרבית ארגוני ה-IT אותם פגשתי במהלך השנים, ממוצבות בסביבת רמה 2 העקבית, והמלצתי לכל – להתקדם בתהליך שיפור מתמיד לרמה 3 המוגדרת, ובהמשך לרמה 4 המנוהלת.