ניהול הפרויקט הצליח – הפרויקט נכשל ניתוח מקרה
מאת הסל פרידלנדר, PMP
מאנגלית תומר קידר, PMP

חלק שני – דברים מתחילים להשתבש...

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

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

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

תוצאות הסדנה
הסדנה התגלתה כרחוקה מאוד מאירוע שגרתי! כל המשתתפים נשאלו מה לדעתם צריכות להיות מטרות הסדנה. ברשימה הבאה, המציגה נגזרת לתשובות לשאלה זו, ניתן למצוא סדר יום חבוי מאוד.
1. למצוא התאמה בין ציפיות הלקוח והצעת הספק.
2. להסכים על דרך משותפת קדימה.
3. להגדיר האם המערכת מסוגלת לספק את צורכי הלקוח.
4. להסיר מכשולים ולהבטיח ערוץ תקשורת פתוח ותמיכה הדדית להליכה קדימה.
5. להבהיר מה שנתפס על ידי כל הצדדים כ"בעיות", ולהסכים על דרך פתרונן.
כל תכתובות המיילים, הפגישות, הסדנאות, ההדגמות ואפילו לא סקר הפרויקט, אף אחד מאלו לא הצליח לחשוף את מחשבות הלקוח שמעולם לא הובעו בפועל. "סדר היום הסמוי" כלל את הרגשת הלקוח שלא הייתה עמידה בציפיותיו (נקודה 1). ספקות הובעו בדבר יכולת המערכת לספק את צורכי הלקוח (נקודה 3). היתה הרגשה שקיימים מחסומים שאינן מאפשרים תקשורת חופשית (נקודה 4). אף אחת מנקודות אלו לא הובעה עד אז.
מנהל הפרויקט מצד הלקוח אמר כי קיימת אפשרות שהמערכת החדשה לא תתאים לצורכי החברה העסקיים. המנחה הסדנה אמר אז כי יש להקפיא את הפרויקט ושיש לבצע פרויקט "בחירה והערכת חבילה". נציג הספק התנגד באמרו כי דבר זה מעולם לא הוכנס לתכולת הפרויקט. קרוב לוודאי כי הרקע וסביבת הסדנה אפשרו ללקוח להביע את החששות שניקרו במוחו. התוצרים הבאים מסיכום הישיבה מציגים את הפעולות הנדרשות שתועדו.
1. הספק מחויב לבצע הערכת ביצועים על מנת לבחון האם המערכת עומדת בסטנדרטים המקובלים בתעשייה, בהקשר לפונקציונליות ולביצועי עלות תועלת.
2. יש להעריך את תקני התעשיה אל מול הביצועים הבסיסיים במערכת. יש לבצע ניתוח פערים ולהציגו לוועדת ההיגוי לצורך קבלת החלטה.
3. על הלקוח לקחת החלטה אסטרטגית להמשיך בהטמעת הפרויקט בהינתן שהמוצר יציג יכולת ליישום שינויים מהירים וביחס עלות תועלת סביר. החלטה זו תתבסס על השוואת פונקציונליות בין המערכת הנוכחית לגרסה המשודרגת. התוצאה המצופה היא הערכת לקוח כי בפועל המערכת המשודרגת אכן מציעה יותר פונקציונליות ויכולות מן המערכת הנוכחית.
4. הצעדים הבאים ייקבע על בסיס תוצאות הניתוח.

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

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

 

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

מה השתבש?
שווה לנסות ולהביט על מה שהשתבש.

"Ask Coke to ship two cans of Pepsi with every six-pack!"

הלקוח טען כי לא יוכל לעבור לגרסה המשודרגת אלא אם כן " הספק יבצע הערכת ביצועים על מנת לבחון האם המערכת עומדת בסטנדרטים המקובלים בתעשייה, בהקשר לפונקציונליות ולביצועי עלות תועלת."
דרישה זו דומה לאתגר שהוצב בפני מיקרוסופט כאשר ממשלת ארצות הברית רצתה שמיקרוסופט תכלול את הדפדפן של נטסקייפ במסגרת מערכת ההפעלה Windows98. תגובת מיקרוסופט הייתה: "זוהי דרישה חסרת תקדים, הדומה לבקשה מחברת קוקה-קולה לספק שתי פחיות פפסי בכל מארז שישייה של החברה" [2]. תגובתו של ביל גייטס לתביעה המשפטית של התובע הכללי במשרד המשפטים הייתה "ללא ספק, כל חברה בתעשיה זו צריכה כל הזמן ובאופן מהיר לשפר את מוצריה. זו הסיבה שראיתם את השקעות המו"פ שלנו עולות בפקטור 10 במהלך 8 השנים האחרונות." [3]
ספקי התוכנה מפתחים את המוצרים על מנת להבטיח שיעמדו בדרישות השוק. מן הלקוחות מצופה לבצע "קנייה השוואתית" טרם רכישת התוכנה.

תהליך הרכש ו"חֲרַטָת הקונה"
היה זה שווה לנסות ולהבין מה גרם ללקוח לתת אמון כה קטן בתוכנה המשודרגת. מנהל הפרויקט מצד הלקוח אמר לכל אורך הדרך כי הוא מרוצה מן המערכת הקיימת. האם היה לו בסיס כל שהו לספק בדבר אי התאמת השדרוג לצרכיו העסקיים?
תהליך קבלת ההחלטות אצל הקונה, מתואר במספר דרכים שונות. [4] הביטוי "מודל צרכנים" מתייחס לראיה או לתפיסה הכללית בדבר השאלה מדוע (ולמה) מתנהגים יחידים כפי שהם מתנהגים. בפרט, קיימים מודלים של צרכנים המציגים ארבע דרכי ראייה שונות שייבחנו להלן.
הראייה הכלכלית (Economic)
בראייה זו הצרכן מקבל החלטות רציונליות בכך שהוא:
• מודע לחלופות
• בעל יכולת לתעדף נכונה כל חלופה
• מסוגל לזהות את החלופה הטובה ביותר
נהיר מתוך מה שהתרחש בפרויקט זה כי לא כך היו פני הדברים, והמודל הכלכלי לא אומץ.
הראייה הפסיבית (Passive)
ראייה זו הפוכה לראייה הכלכלית והיא מתארת את הצרכן כמקבל את מרות המשווקים על האינטרסים שלהם ועל מאמציהם לקידום מכירות. בפרויקט זה הספק פנה ללקוח והציע את השדרוג. הלקוח לא בחן חלופות אחרות. מנהל הפרויקט מטעם הלקוח, שטען להיותו חף מכל ידע על חלופות אחרות, אישר זאת.

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

הראייה הרגשית (Emotional)
כאשר מרכן מקבל החלטה קניה על בסיס רגשי, פחות מאמץ מושקע בחיפוש אחר מידע טרום הקניה. במקום זאת, מיקוד רב יותר מושם על מצב הרוח הנוכחי. ההחלטה להמשיך עם השדרוג התקבלה לאחר שזוהו היעדים העסקיים של הלקוח. יעדים "קשוחים" נקבעו והוחלט כי יש צורך דחוף לשדרג את מערכת המחשב במטרה לסייע לארגון להשיג את מטרותיו.
הלקוח אכן החליט, כי המערכת הנוכחית היא הברירה היחידה. מעניין ככל שייראה, כאשר הובעו ספקות והפרויקט הוקפא, מנכ"ל הלקוח נשאל מדוע הוא עדיין שוקל את מערכת הספק. הוא ענה "מערכת היחסים שלנו עם הספק היא דבר חשוב ואני אעשה ככל יכולתי להבטיח שתישאר כך".
מדוע ישפיעו זוויות ראייה אלו שהוצגו על הפרויקט או על תוצריו? איור 5מראה את ארבע זוויות הראייה השונות, המיוצגות בצבעים ירוק או אדום בהתאם להשפעתן האפשרית על הפרויקט.
צרכן המסומן כבעל ראייה אדומה מציב סיכון גדול יותר לפרויקט, ועל אנשי המכירות לקחת נקודה זו בחשבון. צרכן זה יזדקק לתמיכה ולעידוד. הסיבה לכך היא שלצרכנים בקטגוריות האדומות יש מידע מועט מאוד או אין מידע כלל בדבר אפשרויות אחרות, וחוסר ידע זה עלול לטעת ספקות ככל שהם למדים יותר על מוצרים מתחרים.
כאשר צרכנים עושים שימוש במוצר או נחשפים אליו, הם מעריכים את ביצועיו לאור ציפיותיהם. כלל שתהליך זה ארוך יותר, כך גדלה האפשרות שהלקוח יערער על החלטתו הראשונה. הדבר מציב שלוש אפשרויות: הביצועים יכולים לעלות, לתאום או להיות נמוכים מן הציפיות. [6]
רכיב חשוב בהערכה לאחר מעשה של רכישה היא הפחתת אי הבהירות או הספקות שהיו ללקוח בנוגע לבחירתו. כחלק מניתוח לאחר מעשה של רכישתם, צרכנים מנסים להבטיח לעצמם כי בחירתם הייתה נכונה; כלומר, הם מנסים להפחית את הדיסוננס הקוגניטיבי שלאחר הרכישה.
מה ניתן לעשות על מנת להפחית את הסיכון? נעשה ניסוי שהתמקד בהשפעות החרטה שלאחר החלטת הקונה על הרכישה. [7] בשנת 1970, דונלי ואיבנסביץ ביצעו ניסוי שהתחקה אחר קונים בשתי סוכנויות רכב. כל אחד מן הלקוחות קיבל החלטה לרכוש מכונית והמחקר ביקש לבחון כמה מקונים אלו יחזרו בהם לפני קבלת המכונית.
דונלי ואיבנסביץ הניחו כי הקונים יחוו דיסוננס שלאחר החלטה, בין מועד קבלת ההחלטה ועד למועד קבלת המכונית. כדרך להפחתת דיסוננס זה, חלק מן הקונים ישנו החלטתם בנוגע לרכישת המכונית. במילים אחרות, דיסוננס שלאחר החלטה יתבטא בהפחתת אטרקטיביות רכישת המכונית בעבור מספר קונים ושינוי החלטתם המקורית היוותה שיטה להפחתת הדיסוננס.
לאחר מכן, הנסיינים ביקשו להפחית את הדיסוננס אצל חלק מן הקונים באמצעות מספר פניות של איש מכירות אליהם, לאחר ביצוע המכירה הראשונית. איש המכירות ישוחח עימם בצורה אוהדת על המכונית שנקנתה, וייתן חיזוקים לקונה שקיבל את ההחלטה הנכונה. הניסוי תוכנן כך שקבוצה אחת קיבלה את שיחות התמיכה של איש המכירות וקבוצה הביקורת לא קיבלה שיחות אלו.
תוצאות הניסוי נטו לתמוך בהשערותיהם של החוקרים. אותם קונים שלא קיבלו את שיחות החיזוק נטו יותר לבטל את החלטותיהם מאשר אלו שהיו בקבוצה שקיבלה את התמיכה החיובית. בפועל, רק 2.5% מן הקונים שקיבלו את שיחות הטלפון האדיבות ביטלו את החלטתם לרכוש את המכונית, בעוד ש 6.4% מן הקונים שלא קיבלו שיחות אלו חזרו בהם מן ההחלטה המקורית שקיבלו. מחקר זה מראה את חשיבות החיזוק החיובי כאמצעי להפחתת הדיסוננס, כפי שניתן לראות באיור 6.
בפרויקט הנידון בניתוח אירוע זה, הסיכון שהציג הלקוח דורג בצבע אדום, שמשמעותו שהיה צורך "לטפל בו". אנשי המכירות היה צריך לשמור על קשר ולספק חיזוקים לכל אורך הדרך. דבר זה לא קרה כלל, וצוות הפרויקט היווה את הקשר היחיד עם הספק, עד שהיה מאוחר מדי.
כיצד להימנע ממצבים כאלו? כיצד ליישם לקחי אירוע זה בתהליכי ניהול התכולה, ניהול האיכות, ניהול התקשורת וניהול הסיכונים? כל אלו ייסקרו בחלקו השלישי של המאמר, שיפורסם בהמשך.

2. Gates, Bill, May 1998 (reported on Microsoft web site)
3. Gates, Bill, interview Business Week, June 1 issue, 1998
4. Schiffman, L, & L. Kanuk, Consumer Behavior, 6th ed. Prentice Hall, Upper Saddle River, NJ, 1997, pp560-561, 582
5. March, J. & H. Simon, Organizations, Wiley, New York, 1958, pp140-141
6. Olskavsky, R., Towards a More Comprehensive Theory of Choices, in E. Hirschman and M. Holbrook, (eds) Advances in Consumer Research 12 (Provo, UT: Association for Consumer Research), 1985, pp465- 70
7. Donnelly, J, and J. Ivancevich, 1970. Post-purchase reinforcement and back-out behavior, Journal of Marketing Research, 7, pp399-400

___________________________________
הסל פרידלנדר, שעלה לאחרונה מדרום אפריקה, החל דרכו כמתכנת, אולם רק לאחר שהפך יועץ עסקי החל לראות את התמונה דרך עיני הלקוח. להסל ניסיון עשיר בתעשיית ה-IT. בין השאר עסק הסל בפיתוח תוכנה, אסטרטגיה עסקית ופרויקטי תשתית. להסל עניין רב בלימוד, וחלק קטן מזמנו הוא מקדיש לפיתוח והרצת מערכי הדרכה.
ניתן ליצור קשר עם הסל באמצעות כתובתו: hesself@013.net