שאלות ראיון לתפקיד מנהל פרויקטים

גישה: מטרה ← בעלי עניין ← היקף ← תוכנית ← ממשל

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

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

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

גישה: היקף בסיס ← הערכת השינוי ← פשרות ← החלטה ← תקשורת

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

גישה: הערכת מצב ← שורש הבעיה ← אפשרויות ← החלטה ← תקשורת

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

גישה: קיבולת ← עדיפות ← פשרות ← יישור קו

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

גישה: זיהוי ← אחראי ← תאריך ← סיכון ← הסלמה

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

גישה: זיהוי ← הערכה ← הפחתה ← ניטור ← הסלמה

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

גישה: הבהרה ← השפעה ← אפשרויות ← החלטה ← עדכון קו הבסיס

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

גישה: עובדות ← השפעה ← אפשרויות ← המלצה ← ההחלטה הנדרשת

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

גישה: אי-ודאות ושינוי מול צפיות ושליטה

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

גישה: תכנון, סנכרון, סקירה, שיפור

תכנון הספרינט (Sprint Planning) מגדיר על מה הצוות יעבוד ולמה. הסטנדאפ היומי עוזר לצוות להסתנכרן, לזהות חסמים ולהתאים את הביצוע. סקירת הספרינט (Sprint Review) מציגה את העבודה שהושלמה ואוספת משוב. הרטרוספקטיבה מזהה שיפורים בתהליך לקראת הספרינט הבא. חידוד הבקלוג (Backlog Refinement) שומר על העבודה הקרובה ברורה ומוכנה. הטקסים חשובים רק אם הם משפרים את הביצוע. סטנדאפ יומי הוא לא פגישת דיווח סטטוס עבור מנהל הפרויקט; הוא כלי תיאום של הצוות. רטרוספקטיבה לא מועילה אם לא עוקבים בפועל אחר ביצוע הפעולות שסוכמו בה. בראיון אדגיש תוצאות: שקיפות, תעדוף, משוב, נראות של סיכונים ושיפור מתמיד.

גישה: תאריך קבוע פירושו היקף גמיש

אם התאריך קבוע, צריך לנהל בזהירות את ההיקף, את רף האיכות, את המשאבים או את הסיכון. קודם כול אברר איזו תוצאה חייבת להיות מושגת עד הדדליין ואילו פיצ'רים באמת נדרשים. לאחר מכן אתעדף את הבקלוג לחובה (Must-have), רצוי (Should-have), אפשרי (Could-have) ובהמשך. אגדיר את ההיקף המינימלי הנדרש לדדליין ואציג את הפשרות במפורש. אשתמש בתכנון ספרינטים ובמעקב Burn-up או Burn-down כדי לנטר את ההתקדמות מול יעד הגרסה. בנוסף אזהה סיכונים מוקדם: תלויות, בדיקות, אישורים, נעלמים טכניים וקיבולת הצוות. אם המגמה מראה שהצוות לא עומד בקצב, אסלים מוקדם עם אפשרויות: לצמצם היקף, להוסיף קיבולת, להאריך את התאריך או לקבל סיכון. Agile לא אומר שתאריכים לא חשובים. המשמעות היא שהצוות מתאים את ההיקף ואת התוכנית על סמך נתונים, תוך שמירה על שקיפות.

גישה: קהל ← מסר ← תדירות ← ערוץ ← אחראי

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

גישה: הבהרת מטרות ← זיהוי פשרות ← שימוש בקריטריונים ← החלטה

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

גישה: סטטוס RAG ← התקדמות ← סיכונים/בעיות ← החלטות ← צעדים הבאים

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

גישה: השפעה ← חוזה ← אפשרויות התאוששות ← הסלמה ← מניעה

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

גישה: ייצוב ← תקשורת ← טריאז' ← החלטה ← הפקת לקחים

קודם כול אייצב את המצב. אוודא את הכשל, את חומרתו, את ההשפעה על המשתמשים, את המערכות המושפעות והאם אפשר לבצע Rollback. ארכיב את צוות התגובה המתאים ואגדיר גורם אחד שמוביל את האירוע. לאחר מכן אעדכן במהירות. בעלי העניין צריכים לדעת מה קרה, מה ההשפעה, מה נעשה כרגע ומתי יגיע העדכון הבא. יש להימנע מהשערות. אם לקוחות או משתמשים מושפעים, אתאם תמיכה ותקשורת חיצונית לפי הצורך. אבצע טריאז' ואחפש את שורש הבעיה תוך הגנה על המשתמשים. האפשרויות כוללות Rollback, Hotfix, כיבוי Feature Flag, השקה חלקית, פתרון עוקף ידני או דחייה. ההחלטה תלויה בחומרה, בסיכון ובמידת הביטחון בהתאוששות. אחרי ההתאוששות אקיים תחקיר. אזהה פערים טכניים, תהליכיים, בבדיקות, בתקשורת ובקבלת ההחלטות. השיפורים יכולים לכלול קריטריוני Go/No-Go טובים יותר, תוכניות Rollback, בדיקות Smoke, צ'קליסט השקה, ניטור או פריסה הדרגתית.

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

המדדים תלויים בסוג הפרויקט, אבל מדדים נפוצים כוללים סטטוס אבני דרך, סטיית לוח זמנים, סטיית תקציב, שינויי היקף, סיכונים ובעיות פתוחים, סטטוס תלויות, מספר באגים, השלמת בדיקות, ניצולת משאבים, Burn-up או Burn-down, Velocity ומדדי מוכנות. בפרויקטי Agile אוכל לעקוב אחר עמידה ביעדי הספרינט, מגמת Velocity, Cycle Time, בריאות הבקלוג, חסמים ו-Burn-up של הגרסה. בפרויקטי Waterfall או הטמעה אוכל לעקוב אחר השלמת אבני דרך, הנתיב הקריטי, שערי שלב, תקציב ובקשות שינוי. מדדים צריכים לתמוך בהחלטות. מדד שלא מוביל לפעולה הוא בדרך כלל רעש. אשלב מדדים כמותיים עם שיקול דעת איכותני, כי סיכון בביצוע לא תמיד נראה בדשבורד. כשאפשר, אעקוב גם אחר הערך העסקי: אימוץ, הפחתת עלויות, השפעה על לקוחות, מוכנות רגולטורית או שיפור תפעולי. מדדי ביצוע לבדם לא מוכיחים שהפרויקט הצליח.

גישה: נראות, בעלות, תלויות, החלטות

כלים צריכים ליצור נראות ואחריותיות משותפות. ב-Jira המשמעות היא פריטי בקלוג ברורים, אחראים, עדיפויות, סטטוסים, קריטריוני קבלה, מעקב אחר ספרינטים או גרסאות ותלויות. ב-MS Project או ב-Smartsheet המשמעות יכולה להיות מבנה פירוק עבודה (WBS), תאריכים, תלויות, נתיב קריטי, אבני דרך והקצאת משאבים. הכלי צריך להתאים למודל הביצוע. צוותי תוכנה עשויים להעדיף את Jira. הטמעות ארגוניות עשויות לדרוש תצוגת גאנט ומעקב תלויות. דיווח להנהלה עשוי לדרוש דשבורד מסכם נפרד. הטעות היא להתייחס לכלי כאילו הוא הפרויקט עצמו. תוכנית שמעודכנת בצורה מושלמת לא מחליפה שיחות, החלטות, ניהול סיכונים ויישור קו עם בעלי העניין. הכלי תומך בביצוע; הוא לא מנהל את הפרויקט בעצמו.

גישה: מטרה ← מורכבות ← התפקיד שלכם ← פעולות ← תוצאה

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

גישה: בעלי עניין ← התנגדות ← יישור קו ← פעולה ← תוצאה

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

גישה: כישלון ← לקיחת אחריות ← התאוששות ← לקח

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