השפעת "רוח המפקד" בניהול פרויקט

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

דילמת איכות מול פונקציונאליות

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

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

האינסטיקט הראשון שעולה בדר"כ נותן משקל כבד למילה מנהל (בצמד 'מנהל פרויקט') ומשמעותו –

"אני רוצה גם וגם". גם איכות וגם פונקציונאליות מלאה.

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

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

כיצד? עלינו להבין את משמעות התוצאה בעיני הלקוח של פגיעה באיכות לעומת פגיעה בפונקציונאליות.

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

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

דילמת שיתוף מול מרחב תמרון

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

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

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

גם כאן, הבנת "ראיית הלקוח" תאפשר לנו לקבל את ההחלטה הנכונה.

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

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

דילמת סיום הפרויקט טרם זמנו

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

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

דילמה זו עוסקת דווקא במקרה ההפוך.

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

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

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

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

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

שורת סיכום

מספר דברים -

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

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

בהצלחה.

Picture source - http://www.usmilitariaforum.com/forums/index.php?/topic/143033-general-rank

יוגב טל

יועץ לתהליכי פיתוח וניהול פרויקטים

מאמן אישי וניהולי

/

בחזרה לעמוד הבית - מרעננים את הפיתוח