דפים

יום חמישי, 14 בנובמבר 2013

גישות מוטעות בניהול פרויקטים

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


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

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

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

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

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

בהצלחה !

*אם יש לכם תהיות והתלבטויות הקשורות לייעוץ והכוונה בנושא –
צרו קשר – yogev05.t@gmail.com



יוגב טל, PMP


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

3 תגובות:

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

    השבמחק
    תשובות
    1. היי,
      ראשית אקדים ואומר שאני אחד מהתומכים הנלהבים בשימוש באג'ייל. הטמעתי את השיטה במספיק מקומות ע"מ שאוכל
      לומר שהיא מאד אפקטיבית.
      מדוע הטיפוס הראשון אינו נופל לקטגורייה זו :
      אג'ייל מדבר על דגימות קצרות ומוגדרות (ראה daily meeting) אשר למעשה מספקות 3 מטרות עיקריות -
      1. סנכרון כל אנשי הצוות
      2. קבלת תמונת מצב מלאה (ועל בסיסה קבלת החלטות זריזה)
      3. פינוי אנשי הצוות מישיבות סטטוס ארוכות ולא יעילות

      מנהל הפרויקט בפרופיל הראשון רואה לנגד עיניו בעדיפות הראשונה את השליטה המלאה בפרויקט.
      הגישה שבה הוא נוקט היא דגימות תכופות (מספק פעמים ביום), יצירת עוד ועוד מדדים אשר אמורים לתת לו יותר בטחון ושליטה,
      ויותר קבלת החלטות 'מותאמת למצב'.
      בפועל פעולות אלו גורמות בדיוק את ההיפך ופוגעות בהתנהלות התקינה של הפרויקט.
      בראייה אג'ילית הוא נוגד הרבה עקרונות אג'יליים - כגון Collaboration, Team Responsibility, Noise reduction from team וכו'
      בשורה תחתונה - אג'ייל הוא מתודולוגיה יעילה כאשר מבינים היטב את העקרונות של השיטה ומיישמים אותה עלפיהן
      כאשר מתמקדים במדדים ובכלי שליטה בלבד, התוצאה יכולה להיות הפוכה.
      יוגב

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

    השבמחק