מתי פרויקט מסתיים ואיך יודעים שהגענו לקו הסיום? 

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

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

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

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

ובעולם פיתוח המוצרים שבתום הפיתוח עוברים לייצור, שם בכלל הנושא כואב והתחום של העברה מפיתוח לייצור (NPI- New Product Indtroduction) לא תמיד מפותח, שלא לאמר שבחלק מהמקרים כלל אינו קיים.

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

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

הגדרה חשבונאית לסיום פרויקט

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

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

אתן דוגמא-

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

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

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

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

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

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

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

הזמנה להגדרת נקודת סיום והעברת מקל

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

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

בהצלחה!, ואם תרצו סיוע- נשמח לעמוד לרשותכם בלידרה להגדיר את התהליך.

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

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

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

Armed forces toys from Amazon

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

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

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

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

יחד עם זאת, מעט מאוד נכתב על הקשר בין ניהול פרויקטים ובניין כוח צבאי. המעט שנכתב מתייחס לתשתיות או פיתוח אמצעי לחימה⁵ (אף חוברו נהלים כגון: 10/1, 10/2, 10/3 המגדירים שלבים שיבטיחו ביצוע פרויקט מוצלח).

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

להלן המקרה הראשון: מעשה במלך ובאונייה

מלך שבדיה, גוסטב אדולף השני (1594-1632), וויקיפדיה

המקום: שבדיה

הזמן: המאה ה-17

מלך שבדיה, גוסטב אדולף השני (1594-1632), הוא בנו בכורו של המלך קרל התשיעי לבית ואסה (Vasa). הוא כיהן כמלך שבדיה במשך 21 שנים. סיפור המעשה הוא החלטתו האסטרטגית לבצע בניין כוח בצי הימי השבדי. בעת ההיא שבדיה היתה מעצמה ימית אשר הקצתה את הרוב המכריע של משאביה לבנייה ושימור כוחה הצבאי⁶. בתחילת המאה ה-17 ספג הצי השבדי מספר מהלומות קשות: אוניות טבעו לאחר שעלו על שרטון ואוניות אחרות טובעו בקרבות עם הצי הפולני. השאיפה להתאושש ממהלומות אלו, יחד עם מעורבות שבדיה במלחמת שלושים השנים⁷, הביאו את מלך שבדיה להשקיע בבניין כוח צבאי ולחזק את הצי. הוא הורה לבנות חמש אוניות מלחמה, שנועדו להיות בעלות יכולות אש מהגבוהות ביותר בעת ההיא. "ואסה" הייתה האונייה הראשונה בסדרה וכיאה לציפיות והמעמד נקראה על שם שושלת בית המלוכה של המלך.

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

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

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

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

מהסיפור עולות תובנות רבות.

התובנות המרכזיות מסיפור אוניית הואסה הן:

אוניית הואסה, וויקיפדיה

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

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

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

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

המקרה השני: מהנדס מכונות וטילים בליסטיים

הנרי לורנס גאנט (1861-1919), וויקיפדיה

המקום: ארצות הברית

הזמן: המאה ה-19

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

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

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

עבודתו של הנרי גאנט הניחה את הבסיס לפיתוחם של כלים מתקדמים לתכנון וניהול פרויקטים. אחד היישומים המוכרים הוא תרשים PERT (Program Evaluation Review Technique).  הוא פותח כחלק מבניין כוח צבאי בצי האמריקאי, במסגרת המלחמה הקרה בין ארצות הברית וברית המועצות. איום הייחוס אליו התכוננו האמריקאים היה הפצצה גרעינית על ידי הצד השני. במסגרת תהליך בניין כוח, גובשה אסטרטגיה צבאית למענה לאיום זה. המענה כלל פיתוח יכולת שיגור מצוללות של טילים בליסטיים המצוידים בראשי נפץ גרעיניים (פרויקט פולאריס). שיטת PERT פותחה ככלי לחיזוי ומדידת התקדמות תהליך הפיתוח של הפרויקט¹⁰. זאת כדי להתמודד ביעילות עם מימד הזמן עד להכרזה על יכולת מבצעית של שיגור טילים בליסטיים מצוללות. נושא שהפך למרכיב משמעותי בתחרות בין המעצמות.

התובנות המרכזיות מסיפור הנרי גאנט הן:

תרשים גאנט, וויקיפדיה

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

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

המקרה השלישי: פיזיקאי וקצת גאווה ישראלית

ד"ר אליהו גולדרט, וויקיפדיה

הזמן: המאה ה-20

ד"ר אליהו משה גולדרט (1947-2011) הוא פיזיקאי ישראלי שפיתח והגה את תאוריית האילוצים (TOC – Theory Of Constraints). היא פותחה עבור תזמון תהליכי ייצור ובהמשך התרחבה לעולמות תוכן נוספים. בבסיס התאוריה ההנחה כי בתהליך או בארגון קיימים אילוצים אשר מגבילים אותו. גולדרט טוען שתחילה, יש לאתר אילוצים אלו. לאחר מכן, יש להשתמש באילוצים על מנת להגביר תרומה לרווח (Throughput, להבדיל מתפוקה, Output) ולהפחית עלויות.

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

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

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

התובנה המרכזית מסיפורו של גולדרט היא:

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

אז מה למדנו בקשר לבניין כוח צבאי?

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

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

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

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

סיכום

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

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

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

פוסט אורח ב Leadera

הערות:

1. ההגדרה המקובלת של פרויקט היא: "מאמץ זמני לטובת ייצור מוצר, שירות או תוצאה ייחודיים". ניהול פרויקטים מוגדר כ: "יישום של ידע, מיומנויות כלים ושיטות כדי לעמוד במטרות הפרויקט". מתוך גוף הידע לניהול פרויקטים PMBOK (Project Management Body of Knowledge), מהדורה רביעית, הוצאת דיונון, 2010, עמ' 5-6.
2. הארגון הנפוץ הוא הארגון האמריקאי לניהול פרויקטים PMI (Project Management Institute). http://www.pmi.org/ במדינות רבות בעולם ישנם סניפים של העמותה, כולל בישראל.
3. שלמה גלוברזון ואבי שטוב, ניהול פרויקטים – תכנון ביצוע ובקרה, הוצאת דיונון, 2003, עמ' 7.
4. יעקב זיגדון, עיונים בתורת בניין הכוח הצבאי, צה"ל הוצאת "מערכות", משרד הביטחון, 2008, עמ' 37.
5. מעט המסמכים שנכתבו מתייחסים לפרויקטים בהקשר ממוקד של פיתוח אמצעי לחימה. לקריאה נוספת:

בועז נתן, פילוסופיית פיתוח רב-שנתית של מערכות אמל"ח, מערכות, 392, 2003.

נתן יערי, פיתוח מערכות נשק, מערכות, 333, 1993.

דן ר', פיתוח אמצעי לחימה: מתי, מדוע ואיך, מערכות, 257, 1977.

1. The Swedish fiscal-military state and its navy, 1521–1721 Jan Glete, http://www2.historia.su.se/personal/jan_glete/Glete-Swedish_Fiscal-military_State.pdf
2. במלחמת שלושים השנים (1618-1648), השתתפו מרבית המעצמות האירופיות בעת ההיא. הגורמים המרכזיים למלחמה הם עימות דתי בין פרוטסטנטים וקתולים ושאיפתה של השושלת ההבסבורגית לשמר ולהגדיל את עוצמתה באירופה.
3. http://www.vasamuseet.se/en/
4. Patrick Weaver, PM World Journal, Henry L Gantt, 1861-1919: Debunking the myths, a retrospective view of his work, Vol. I, Issue V – December 2012
5. Mats Engwall, PERT, Polaris, and the realities of project execution, International Journal of Managing Projects in Business, Vol. 5 Iss: 4, pp.595 – 616, 2012
6. Kevin J. Watson a, John H. Blackstone, Stanley C. Gardiner, Journal of Operations Management, The evolution of a management philosophy: The theory of constraints, Vol. 25  387–402, 2007
7. אליהו מ. גולדרט וג'ף קוקס, המטרה, הוצאת דניאלה די-נור, 1988.

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