סדר פסח גם בניהול הפרויקטים

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

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

 

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

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

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

מודעות פרסומת

Scaling Agile

Scaling Agile – אתגרים מורכבים שמחפשים פתרון פשוט

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

  • מימד הרוחב – כיצד רואים תמונה רוחבית של מצב הצוותים, כיצד יודעים היכן יש צווארי בקבוק, כיצד יודעים איזה צוות עובד על משימות שוליות יחסית ואיזה צוות לא מצליח לקדם משימות חשובות, כיצד מקצים מומחים ועוד.
  • מימד האורך – כיצד מבינים מה צפוי לקרות לפרויקט לאורך זמן, כיצד קובעים ROAD MAP ראלי למוצר, כיצד מתחייבים ללקוחות ולמשקיעים ועוד.Scaling Agile תמונה
  • מימד העומק – כיצד מצליחים לייצר תשתית הנדסית נכונה, כיצד מגבירים את ה RE USE
    לצמצום בעיות האיכות, כיצד מוודאים שתהליכי פיתוח מורכבים יחסית נעשים בצורה נכונה, כיצד מסנכרנים בצד ההנדסי בין פיתוחים בצוותים שונים בכלל ובין פיתוח חומרה לפיתוח תוכנה בפרט.

מול האתגרים שמציבים כל אחד מהמימדים הללו, פותחו מספר גישות שהמפורסמות שבהן הן SAFe, Scrum Of Scrum, Spotify model, LeSS, DSDM. כל אחת מהן מציעה פתרונות לחלק מהאתגרים ובחלקים אחרים היא חלשה. לדוגמא, Scrum of Scrum  מציעה פתרון לעבודה המשלבת מספר צוותים, אך היא מוגבלת בכל מה שקשור לניהול הפורטפוליו וניהול התוכניות. גם רמת המורכבות של הגישה משתנה. ככל שההגישה יותר מקיפה ומכילה יותר פתרונות, כך היא גם קשה יותר ליישום ודורשת תהליך הטמעה מורכב יותר.

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

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