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

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

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

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

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

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

"יש לנצל את משאבי הפרויקט ... כאשר חוסר בתקשורת עלול להוביל לכישלון." PMBOK.¹⁰

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

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

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

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

"נקיטת פעולות מקדימות להפחתת השפעות סיכון על הפרויקט, אפקטיבית הרבה יותר מאשר לנסות לתקן את השלכות התממשותו." – PMBOK. 13.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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