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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מי יודע, אולי יום אחד כל הארגון יעבוד באופן דומה.

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

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

כמנהלים, אנו תמיד נדרשים למחשבה – מה אנחנו מנהלים?

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

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

המשאב האמיתי שאנחנו באמת מנהלים – הוא האנשים שלנו. העובדים, ראשי הצוותים, מנהלי הקבוצות.

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

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

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

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

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

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

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

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

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

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

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

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

כעת ניתן לגשת לבניית תכנית העבודה.

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

מדוע אנו עושים זאת באופן כזה?

משימות גדולות וניהולן

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

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

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

משימות קצרות ומשמעותן

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

תקשור וניהול של תכנית העבודה

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

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

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

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

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

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

טוב, אז בלי הקדמות מיותרות.

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

תכנית העבודה עצמה נשענת על שלושה מרכיבים בסיסיים:

1. תכולת עבודה
2. זמן
3. משאבים וכח אדם

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

מהיכן מתחילים?

כל תהליך של בניית תכנית עבודה מתחיל מנקודה שונה.

לעיתים הזמנים קשיחים.

לעיתים התכולה קשיחה.

לעיתים המשאבים קשיחים.

לעיתים שניים מהמרכיבים קשיחים.

לעיתים כל שלושת המרכיבים קשיחים.

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

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

נתחיל ממקרה ראשון:

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

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

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

נקודות עיקריות בתהליך:

1. ניתוח דרישות תכולה.
2. בניית ארכיטקטורה מתאימה למענה על הדרישות
3. בניית אפיון ותיכון טכני, הנותן מענה לארכיטקטורה המוצעת.
4. בנייה וקידוד תשתיות מתאימות
5. בנייה וקידוד אפליקציה
6. בדיקות יחידה.
7. אינטגרציה
8. בדיקות ובקרת איכות.
9. סבבי תיקוני תקלות.
10. אריזה

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

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

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

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

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