של מי המערכת שהספק שלכם מפתח?

מהו גבול השקיפות שהספק צריך לאפשר?

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

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

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

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

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

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

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

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

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

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

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

רונן שמחון

RS-IT