עד כמה התרחיש הבא מוכר לכם? הפרויקט יוצא לדרך. יש הגדרה ברורה של תכולה המבוססת על איסוף דרישות וישיבות תיאום. יש גם מסמך תכולה שעבר את סבב האישורים וקיבל את ברכת הדרך של כלל בעלי העניין. ואז אחרי כמה שבועות נזכר אחד מבעלי העניין שבעצם כדאי להוסיף עוד פיצ'ר אחד קטנטן, אפילו לא פיצ'ר עוד עמודה במסך או עוד נתון שצריך לקלוט או עוד טבלה לדו"ח. "זה שינוי קטן, נכון? זה ממש חשוב למשתמשים." ואחרי עוד פגישה, עוד משהו קטן ועוד אחד ועוד. זה תמיד חשוב וכדאי להוסיף כי זה יסייע להטמעה. וכל שינוי נראה קטן, ויחד הם הופכים להיות עניין ותכולת הפרוייקט שאיתה יצאנו לדרך התרחבה בלי ששמנו לב.
מהי תכולה?
נתחיל בהתחלה. תכולת העבודה של פרויקט כוללת את כל העבודות שיש לבצע בפרויקט על מנת לעמוד ביעדי הפרויקט כפי שהוגדרו. בכל פרויקט מוגדרת התכולה במסמך הצהרת תכולה (Scope of Work) המתאר בפירוט את תוצרי הפרויקט שיש לספק, ולרוב גם מגדירה מה אינו כלול בתכולת הפרוייקט על מנת לייצר בהירות מול הלקוח ובעלי העניין. תכולה מוגדרת במונחי תוצר. כלומר, מהם כל אותם דברים שיש לספק לצורך השלמת הפרויקט וזאת להבדיל מפעולות לביצוע. את הפעולות נגדיר על בסיס התכולה בשלב מאוחר יותר. כלי נוח למיפוי התכולה הוא WBS, מבנה תכולת העבודה, המסייע לזהות את כלל התוצרים. זהו מבנה הירארכי, המוצג בדרך כלל כרשימה או עץ, ואשר מציג את חבילות העבודה בפרויקט.
המפלצת הזוחלת
פרויקט אם כן יוצא לדרך עם תכולה מוגדרת וברורה. אלא שכמו שברור לכולנו תוכנית היא דבר אחד, ובמציאות קורים דברים שלאו דווקא תכננו; שינויים קטנים שצריך לבצע כדי לפתור בעיות או כדי לתת מענה איכותי ללקוח למשל. אלא שכל שינוי "קטן" מוסיף לתכולת הפרויקט פעולות נוספות לביצוע שדורשות משאבים ואורכות זמן.
תופעה זו של הרחבת תכולת הפרויקט בצורה איטית ובצעדים קטנים, נקראת גלישת תכולה (Scope Creep). שינויים אלה מתבצעים ללא תהליך בקרה ועדכון, לא מוגשות בקשות שינוי ותוכנית הפרויקט לא מתעדכנת ולעיתי קרובות שינויים "קטנים" אלה לא נבדקים כלל. אלא שסך כל השינויים הולך ומצטבר ובמהרה מורגשות ההשפעות על התקציב, העלויות, הקצאת המשאבים ומשך הפרויקט. תופעת גלישת התכולה, היא אחד מסיכוני ניהול פרויקטים הנפוצים ביותר.
ניהול תכולה
כמובן ששינויים הם חלק בלתי נפרד מכל פרויקט. הדגש הוא על בקרה ושליטה. על מנת להימנע מגלישה זוחלת חשוב לבחון את תהליכי ניהול התכולה. זהו רכיב בתוכנית הפרוייקט המתאר כיצד לבצע בקרה על תכולתו. תהליך כזה מתבסס על מסמך מבנה תכולת העבודה (WBS), והצהרת עבודה (Scope of work) ומגדיר מהם השלבים והבקרות הנדרשות. תוכנית כזו תסייע למנהל הפרויקט לוודא שבעלי העניין מבינים את התכולה וכיצד שינויים עלולים להשפיע על הפרויקט כולו.
ריכזנו כמה המלצות מעשיות בנושא:
שימרו את בעלי העניין בתמונה:
יש לוודא שהתכולה המוגדרת מקובלת ומתאומת עם בעלי העניין. חשוב לבדוק שהדרישות הובנו כראוי ותורגמו בצורה נכונה לתוצרים בפרויקט; ייתכן שמה שאתם חושבים לגבי התוצרים של הפרויקט הוא לא מה שהם התכוונו אליו. אל תוותרו על שיחות ושיחות חוזרות עם בעלי העניין כמו לקוחות, או ספונסר, ושתפו איתם את מיפוי הדרישות. אם יתגלו פערים בשלב מוקדם, הרי שזהו זמן נוח לשינוי התוכנית שכן רמת הסיכון נמוכה.
תעדו את דרישות הפרויקט:
ראשית חשוב שיהיה תיעוד ברור של ההתחייבות ההתחלתית – כל המידע הדרוש לניהול תכולת הפרוייקט. את הפערים נסו לנהל ולתעד כבר בהתחלה. לצורך תיאום ציפיות ויציאה מתואמת לדרך, תוכן זה צריך להיות מוסכם על בעלי העניין, וזמין להם. זהו מסמך חשוב משתי בחינות: ראשית, עצם הכנתו מעוררת מחשבה ובחינה, ושנית, זהו רפרנס חשוב להמשך הדרך שניתן לחזור אליו בכל רגע של מחלוקת.
תהליכי בקרת שינויים:
הגדרת האופן בו תתבצע בקרת שינויים. כלומר, כאשר מזוהה צורך לשינוי, הוא נבדק, מאושר ואז משולב בתוכנית הפרויקט. ניתן לחשוב על סדרי גודל שונים של שינויים, אלה שיעברו תהליך מהיר ואלה שדורשים אישור הנהלה. כמובן שלא ניתן לאשר את כל השינויים מבלי ששינינו את תוכנית המשאבים, התקציב או לוחות הזמנים. אבל לפעמים אפשר לחשוב על תיעדוף שונה, כלומר לא כל "לא" הוא בהכרח דחיה. אפשר גם להגיד "לא עכשיו" ואז להחליט מתי כן, או להחליט שמאשרים את השינוי, אבל מוותרים על משהו אחר. העיקר הוא לקיים דיון, לבחון את הדברים, ולא לבצע שינויים באופן "אוטומטי" רק כי נדמה שלנו שזהו שינוי קטנטן.
סדרי עדיפויות ברורים:
כדאי להגדיר ולפרסם בצורה ברורה את סדרי העדיפויות של הפרויקט. זה יסייע לחברי הצוות לומר "לא" בצורה יעילה ונחושה או לקדם שינויים חשובים כשצריך. זה אף מונע מבעלי עניין להעלות שינויים שברור שאינם במיקוד כרגע, ומקל על המערכת כולה לדחות אותם. סדרי העדיפויות צריכים להיות מתואמים עם מטרות הפרויקט ויעדי הארגון מה שייתן להם תוקף ויקל על כולם "ליישר קו".
צוות הפרוייקט – שומרים בשער:
חשוב שצוות הפרוייקט יבין את תפקידו כשומר התכולה בפרויקט, ולשם כך צריך שיכירו היטב את תהליכי בקרת השינויים. לעיתים, חברי הצוות רוצים להיות מועילים ולשמור על לקוחות מרוצים, ויסכימו לשנות משהו מבלי להחיל את תהליך ניהול השינויים הפורמלי. בכדי למנוע זאת נדרש שכולם יבינו מדוע הבקרה חשובה לפרויקט ומה עלול לקרות אם תכולת הפרויקט תתרחב לאיטה. כלומר, על מנת להיות מועיל עבור הלקוח, הדבר הטוב ביותר לעשות הוא להסביר את תהליך בקרת השינויים ולהציע לסייע באישור השינוי.
מי ישמור על השומר?
זכרו לפקוח עין גם על עצמכם! כמנהלי פרויקטים, תרצו לוודא שאינכם מרחיבים את התכולה על-ידי הוספת תכונות ודרישות נוספות. שמירה על סביבת עבודה שיתופית, שבה מתקיים דיון פתוח היא הדרך הטובה ביותר לצמצם את הסיכון ל גלישת תכולה.
גלישת תכולה – סיכום
גלישת תכולה היא סיכון מוכר, ומנהל הפרויקט מקדיש לנושא תשומת לב ומשאבים כחלק מניהול הפרויקט; צריך לזהות את הצורך בשינוי, להבין ולתעד אותו, ולפעול לאישורו או דחיותו בצורה יעילה מבלי שזו תכביד מדי על הפרויקט מחד, אך לא תהווה צעד קטן לקראת איבוד שליטה מאידך. בניהול קשוב ועם תשומת הלב הנכונה תצליחו לגרום למפלצת הזוחלת לעשות סיבוב פרסה ולא להגיע לפרויקט שלכם.
