מאמר זה מציג מאפיינים שונים לפרויקטי מחשוב במגזר הציבורי כדי לשפר את ההתמודדות עם האתגרים הכרוכים בניהולם.
לעתים קרובות חריגות התקציב והדחיות השונות הן תוצאה של דרישות לשינויים (שו"שים), כאשר לקוחות הפרויקט נותרים ללא יכולת להגיב לשינויים אלה בשל היעדר תקציב מתאים.
מאמר זה מציג את מאפייני פרויקטי מערכות מידע במגזר הממשלתי לטובת שיפור ההיערכות לניהול הפרויקטים וההתמודדות עם האתגרים הכרוכים בניהולם.
קריטריונים לכניסה לפרויקט
האם הפרויקט אכן נדרש ? לעתים פרויקטים מתגלים כלא נחוצים רק לאחר התנעתם (לעתים אפילו לאחר סיומם). יש להיות משוכנעים כי אכן אנו מעוניינים בפרויקט. מהם המדדים המחייבים כניסה לפרויקט בקריטריונים השונים ?
אופן מימוש הפרויקט – Make or buy
האם לבחור בפיתוח פנימי באמצעות צוות ה IT בארגון, או לבחור בספק חיצוני אשר יתחייב לתוצר הפרויקט ? לפיתוח פנימי (Make) יתרונות וחסרונות. פיתוח פנימי הינו כדאי כאשר צוות ה IT מסוגל ופנוי לטפל בפרויקט, וכאשר יש תמריץ להשאיר את הידע ב"בית", אולם לא תמיד לצוות ה IT היכולת להתמודד עם אתגרי הפרויקט ולכן נאלצים להעביר את ביצוע הפרויקט החוצה. לעתים מעוניינים לבצע זאת כדי לגדר את תקציב הפרויקט ומתקשרים בפרויקט Fix עם הספק.
אולם גם לפיתוח על ידי ספק (Buy) חסרונות שונים. הדרישות לפרויקטים רבים אינן מלאות בשלב ההתקשרות והלקוח חשוף להרחבת מסגרת התקציב בשל שו"שים (שינויים ושיפורים). פעמים רבות יש לספק אילוצים שאינם מוצגים בשלב ההתקשרות והלקוח נאלץ להתמודד איתם בשלב הביצוע (זמינות אמיתית של מנהל הפרויקט, זמינות צוות הפרויקט, ידע טכנולוגי ומומחיות ועוד).
בין אם הפרויקט מבוצע באמצעים פנימיים או באמצעות ספק, לעתים יש להחליט האם רוכשים ומטמיעים מוצר מדף או שמפתחים אותו. גם כאן יש יתרונות וחסרונות לכל החלטה, וקיימות דוגמאות של כשלונות או הצלחות לכאן ולכאן.
יש לשים לב היטב ליכולת הפיתוח האמיתית, ליכולת הניהול של פרויקט בהיקף רב ולהבנה הטכנולוגית להתאמת הפתרון המוצע לצרכי הארגון.
במקרה של רכישה והתאמת מוצר מדף יש לבדוק את ניסיון הספק ויישומים שונים בארץ ובעולם. יש להקפיד לשוחח עם משתמשים בארגונים שהטמיעו מוצר זה ולבדוק את יתרונות וחסרונות המוצר.
יש להתייחס למרכיבי הפרויקט השונים כולל רשיונות, תשתיות חומרה, פיתוח ויישום, רכש, בדיקות מיוחדות כמו בדיקות ביצועים או סקרי אבטחת מידע. יש לתת דגש לשלב התחזוקה ולהגדיר מהו ה SLA הנדרש ומהי תקופת התחזוקה. יש להתייחס לצורך ב Help desk, מדריכים / מטמיעים, הגדרת אחריות הספק, דרישות רישוי, דרישות Hosting, DR וכד'. יש לתת את הדעת לשמירת רזרבות תקציביות לחריגות.
הגדרת האחראי לפרויקט מטעם גוף ה IT ותחום האחריות שלו. מנהל הפרויקט אחראי לעמידה במטרות הפרויקט ויש לתת לו את תמיכה ההנהלה הבכירה ככל הנדרש. לעתים ילווה מהלך מינוי מנהל הפרויקט בשינוי ארגוני כפי שמפורט בהמשך.
יש לתקצב תקנים לשלבי הפרויקט השונים – החל משלב ייזום הפרויקט ועד לשלב תחזוקת המערכת. לעתים יש לבצע שינוי ארגוני על מנת להכפיף אל מנהל הפרויקט מנתחי מערכות או משתמשים לתקופת הפרויקט. בהמשך יידרש למנות מנהל מערכת אשר יהיה Single point of contact לכל נושא שיעלה.
גוף PMO
יש לבחון את הצורך בגוף PMO שיתמוך בניהול הפרויקט למעקב ובקרה אחר התקדמות הפרויקט, ולתקצב אותו בהתאם. PMO טוב יכול לספק תמונת בקרה ניהולית טובה למקבלי ההחלטות. מנהל הפרויקט מטעם הספק כדאי לאתר מראש מועמדים אפשריים בעלי ההתמחות והיכולת להוביל את הפרויקט מטעם ספקים שונים או ספק ספציפי.
מנהל הפרויקט מטעם הספק
צריך להיות אדם שאנו מאמינים ביכולתו להוביל את הפרויקט לשביעות רצוננו. הוא צריך להיות בעל יכולת ניהולית והרקע הרלוונטי לפרויקט.
ועדות היגוי מלוות
יש למנות וועדות היגוי שילוו את הפרויקט. הן יכולות לכלול וועדת היגוי משרדית למחשוב, וועדת היגוי לפרויקט ועוד. וועדות ההיגוי יתכנסו אחת לחודש או בתדירות אחרת שתוחלט על מנת לדון במצב הפרויקט ולקבל החלטות על מנת לנווט את הפרויקט כך שיעמוד ביעדיו. יש להגדיר מהו הפורום המשתתף בכל וועדת היגוי. יש לשאוף שסטטוס הפרויקט שיוצג יהיה מתואם בין מנהלי הפרויקט מטעםהספק והלקוח.
אופן ההתקשרות עם הספק
יש להגדיר מהו תהליך ההתקשרות הרצוי על פי ההוראות. יש לבחון שימוש בנוהל מפת"ח למסמכי הפרויקט השונים – RFP, מכרז וכד'. בנושא התמורה יש להתייחס לשלבי הפרויקט השונים – פיתוח ותחזוקה, ולהתאים את התמורה לפי הצורך. למשל – לשלב הפיתוח התמורה תהיה ב Fix, ואילו בשלב התחזוקה התמורה תהיה לפי Time and material.
