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

מאת: אריק כץ, חברת רפאל
arickatz@yahoo.com

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

משך פרויקט מציאותי יותר
כיצד ניתן להשיג משך פרויקט מציאותי יותר?
בעזרת כלים פשוטים ומוכרים ניתן לשחרר בקלות את האילוצים של חד פעמיות הפרויקט ושל משכים המוזנים כערכים דטרמיניסטים, ואשר אינו מייצג נכונה את "החיים האמיתיים". הדרך לפתרון מבוססת על סימולאציית מונטה-קרלו. היכולת להריץ את תוכנית הפרויקט כמודל סימולציה מספר רב של פעמים משחררת אילוצים אלו. כל חזרה (הִשָּׁנוּת) של מודל הסימולציה היא תרחיש חדש לתוכנית הפרויקט, כשבכל פעם מוגרלים משכים שונים לפעילויות ובכל פעם נאספים הפלטים של משך הפרויקט, המשאבים הקריטיים והשרשרת / הנתיב הקריטי. נקודת המוצא למודל הסימולציה הם משכי הפעילויות המשמשים כבסיס להגדרת החריגות הצפויות. מה שנותר הוא להגדיר את גבולות החריגה לכל פעילות בנפרד או לכל הפעילויות באופן גורף. את החריגה ניתן להגדיר כאחוזי סטייה או כמשך אופטימי ומשך פסימי.
לדוגמא בעבור פעילות שהוגדרה כעשרה ימי עבודה ניתן להגדיר חסם איחור עליון של שלושה-עשר ימים וחסם הקדמה תחתון של תשעה ימים, או בהתאמה סטייה של עד 30% איחור ו 10% הקדמה. בעבור כל פעילות בתוכנית הפרויקט יוגרל משך מתוך טווחי החריגה שהוגדרו במטרה ליצור מגוון רחב של תרחישים אפשריים לתוכנית הפרויקט. כדי שנוכל להשתמש בתפיסה זו לא רק לשלב התכנון, נכון להשתמש במשך הנותר ולא במשך המתוכנן כדי לקבל תרחישים שמתייחסים אך ורק לאותן פעילויות שטרם התחילו או שהתחילו וטרם הסתיימו.
לאחר הרצה של x תרחישים ניתן לסדר את הפלטים באופן הבא: ריכוז תאריכי הסיום / משכים שהתקבלו מכל התרחישים בסדר יורד וחישוב האחוזון לכל ערך. סידור זה יציג את הסיכוי שהפרויקט יסתיים עד y ימים.

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

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

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

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

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

אריק כץ,
ארכיטקט Project Server, חברת רפאל

.
______________________________________________
על הכותב
אריק כץ עובד בחברת רפאל משנת 2000 ועד היום שם הוא ממלא תפקיד של מוביל טכנולוגי, מפתח ראשי במחלקת מערכות מידע ניהוליות וראש פרויקט של ITG ביחידת המחשוב. אריק חבר בצוות ניהול סיכונים בפרויקטי הפיתוח של רפאל ובצוות אבטחת איכות לתהליכי פיתוח ביחידת המחשוב. arickatz@yahoo.com