ניהול לו"ז של הפרויקט ככלי פנימי

ניהול לו"ז של הפרויקט ככלי פנימי וכבסיס לתקשורת חיצונית – הכל בתוכנית אחת

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

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

 

נתחיל מחידוד הצורך

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

 

מה לא לעשות

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

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

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

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

 

דרכי פעולה אפשריות

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

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

 

כלי אחד הוא שימוש באבני דרך

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

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

 

לגבי התאריכים אפשר לממש שימוש בכלים כמו תאריכי יעד (Deadline) או תוכנית בסיס (Baseline)

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

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

 

ניהול לו"ז של הפרויקט – סיכום

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

 

לשיתוף המאמר
דילוג לתוכן