ניהול היקף הפרויקט: מה אנחנו מכינים?

הגדר את עצמך להצלחה בפרויקט על ידי הגדרת ברור את היעדים - ההיקף - בהתחלה.

תמונה של דייויד מארק מ- Pixabay

למנוע אסון בפרויקט

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

ניהול היקף הוא מכריע להצלחת הפרויקט

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

למנוע זחילה

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

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

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

החדשות הטובות הן שאם נגדיר היקף בצורה ברורה וננהל זחילה של היקף, אנחנו בדרך להצלחה!

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

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

stevendepolo סטיבן דפולו (CC BY) דרך פליקר

מתי יום שלישי הבא?

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

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

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

מסכים על היקף הפרויקט שלך

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

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

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

נכנסים לאותו עמוד

לכל מי שנפגע מפרויקט יש נקודת מבט משלו, וגם את השפה שלו. כיצד מתרגם ה"דימוי הארגוני "של ההנהלה ל"עמוד הנחיתה האפקטיבי" של השיווק ולהודעות "no 404 Page Not Found" של מחלקת ה- IT. אדריכלות היא היכולת לראות דבר אחד במספר תצוגות, נקודות מבט מרובות ושפות מרובות. כמנהלי פרויקטים, עלינו להיות אדריכלים, המסוגלים לראות את הפרויקט מכל נקודות המבט ולענות על כל החששות.

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

מסכים בהיקף

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

הנחות הבהרה

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

שלבי ניהול ההיקף

המכון לניהול פרויקטים מגדיר ארבעה תהליכים המרכיבים את ניהול היקף:

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

PMI מציע שם מהודר ליצירת הגדרת טווח ברמה גבוהה תחילה ו- WBS מפורט מאוחר יותר. הם קוראים לזה פירוט מתקדם.

שאלות המגדירות את שאר הפרויקט

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

הכללות והכללות

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

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

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

ואז, כאשר האתר נבדק, מנהל בא ואומר, "אבל לא יכולתי לקרוא את האתר בקריאולית. מה קרה?" אנו מביאים את הצהרת היקף ומראים לו שקריאולי לא נכללה לעת עתה.

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

יצירת מבנה התמוטטות לעבודה (WBS)

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

לדוגמא, בואו נגיד שאנחנו בונים מטוס. התיאור הראשוני שלנו נראה כך:

• גוף מטוס אחד
• תא טייס אחד
• בקתה אחת
• שני כנפיים
• מכלול זנב אחד
• בקרות טיסה
• אלקטרוניקה לניווט ולמטרות אחרות

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

• גוף כנף
• מיכלי דלק
• קווי דלק
• דשים

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

יצירת שאר תוכנית הפרויקט

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

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

ניהול היקף במהלך הפרויקט

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

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

ניתוח ערך מושכר

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

ניהול זחילה

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

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

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

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

ניהול כל תשעת האזורים

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

מספק את מה שהבטחת

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

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

אימות ואימות

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

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

• אם אנו מספקים משהו גדול, או מסובך, או משהו שצריך לעמוד בדרישות התובעניות, כנראה שנרצה לארגן אימות הרבה לפני מועד המסירה. זה נותן לצוות הפרויקט זמן להתאים או לתקן כל דבר שלא עומד בדרישות הלקוח.
• אם יש מחלוקת האם הפרויקט שלנו מספק את התוצאות שהלקוח נרשם אליהן, הם יכולים לבקש אימות ואימות עצמאי (IV&V), שם קבלן חיצוני נכנס כדי להגדיר את הפערים בין מה שאנחנו מספקים לבין מה שהלקוח רוצה, ולהמליץ ​​על פתרונות.

מְסִירָה

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

עונג לקוחות

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

מה עוצר את הפרויקטים שלך?