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

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

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

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

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

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

רקע על תוכנות ועל שדרוגים

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

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

הלך מחשבה זה, ליווה את תהליך קבלת ההחלטות במקרה הנדון.

במסגרת הפרויקט נעשה שימוש במתודולוגיית ה PMBOK, כאשר תשומת לב ניתנה לסעיפים הבאים:

• ניהול האינטגרציה
• ניהול התוכן
• ניהול עלות וזמן
• ניהול איכות
• ניהול החוזה
• ניהול התקשורת
• ניהול סיכונים

ניהול האינטגרציה

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

ניהול תוכן

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

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

ניהול הזמן

הוכנה תכנית "ברמת על", כפי שמופיע באיור 1.

איור 1 - תזמון ברמת על

על גבי התכנית בוצע תזמון משאבים כנדרש.

ניהול עלות

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

ניהול חוזה

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

ניהול איכות

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

איור 2 - מבנה ארגוני של הפרויקט

ישיבת מנהלת שבועית התקיימה באופן קבוע למן תחילת שלב הפיתוח. שני משתתפים קבועים במנהלת כנציגי הלקוח היו מנהל הפרויקט של הלקוח ויועץ טכני של הלקוח, כפי שמופיע בתרשים ה OBS לפרויקט
באיור 2.

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

ניהול סיכונים

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

שלב ראשון – ייזום הפרויקט

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

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

איור 3 - מייל ממנהל התפעול של הלקוח

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

עד כה נראה כי הכל מתנהל כשורה, עם קידום של 80% מהפרויקט. אולם אז החל המצב להשתנות...