info@leadera.co.il 077-3008614
  • דף הבית
  • אודות
  • הפתרונות שלנו
    • גיבוש תפיסה, הקמת ואיוש PMO
    • בניית קורסים מותאמים לצרכי הלקוח ומסלולי הכשרה וקריירה בניהול פרויקטים
    • פיתוח, שיפור והטמעת תהליכי עבודה ומתודולוגיה ארגונית בניהול פרויקטים
    • בניית מנגנון ייזום דרישות וניהול פורטפוליו פרויקטים
    • תכנון תכנית עבודה לפרויקט ובקרתו
  • הלקוחות שלנו
  • לקוחות ממליצים
  • בלוג
  • צור קשר
  • עברית
  • English

ניהול היבטי סייבר בפרויקט בשיטה ההוליסטית

HomeTag "ארגון ושיטות"
ניהול היבטי סייבר בפרויקט בשיטה ההוליסטית
פברואר 15 2019 Galit מאמרים 0 comments Tags: PMBOK, PMI, אג'יל, ארגון ושיטות, בקרת פרוייקטים, בקרת פרויקט, מחזור חיי פרויקט, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים

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

 

פרויקט פיתוח תוכנה מאובטח, נשמע לך כמו סינית?

פרויקט פיתוח תוכנה מאובטח

www.pixabay.com

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

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

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

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

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

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

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

ניהול הסייבר בכל שלב בפרויקט

שלב הייזום

שלב הייזום

www.pixabay.com

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

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

 שלב התכנון

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

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

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

שלב הביצוע

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

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

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

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

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

שלב הניטור והבקרה

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

  • א. ניהול סטטוס התקדמות של משימות הפיתוח המאובטח.
  • ב. הטמעת כלים אוטומטיים לבדיקות פיתוח המאובטח
  • ג. הגדרת KPI -ים לאיכות הסייבר בכלל והפיתוח המאובטח בכל הפרויקט ובחלקיו

שלב הסגירה

האם צריך לדבר על חשיבות הפקת הלקחים, והעברת הידע לדורות הבאים?!

 

לסיכום

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

שלכם, אריק קליין

פוסט אורח ב Leadera

אתם מוזמנים לפנות בכל שאלה ….

More
3030 2
על מלך, מהנדס מכונות, פיזיקאי, ובניין הכוח הצבאי
ינואר 19 2019 Galit מאמרים 0 comments Tags: ארגון ושיטות, בקרת פרוייקטים, בקרת פרויקט, ד"ר אלי גולדרט, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים, פרויקט, שרשרת קריטית, תורת האילוצים

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

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

https://www.amazon.co.uk/Character-Building-Forces-Marines-Commando/dp/B005D3VC1A

Armed forces toys from Amazon

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

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

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

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

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

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

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

https://he.wikipedia.org/wiki/%D7%92%D7%95%D7%A1%D7%98%D7%91_%D7%94%D7%A9%D7%A0%D7%99_%D7%90%D7%93%D7%95%D7%9C%D7%A3,_%D7%9E%D7%9C%D7%9A_%D7%A9%D7%95%D7%95%D7%93%D7%99%D7%94

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

המקום: שבדיה

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

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

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

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

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

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

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

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

https://he.wikipedia.org/wiki/%D7%95%D7%90%D7%A1%D7%94_(%D7%90%D7%95%D7%A0%D7%99%D7%99%D7%94)

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

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

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

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

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

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

https://en.wikipedia.org/wiki/Henry_Gantt

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

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

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

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

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

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

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

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

https://en.wikipedia.org/wiki/Henry_Gantt

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

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

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

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

https://en.wikipedia.org/wiki/Eliyahu_M._Goldratt

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

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

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

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

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

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

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

מערכתיות – התבוננות מערכתית שלמה על הזרימה (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.

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

 

 

More
3124 0
"חוקי הפסקה" בתנאים של אי- וודאות
דצמבר 29 2018 Galit מאמרים 0 comments Tags: PMBOK, PMI, ארגון ושיטות, בקרת פרוייקטים, בקרת פרויקט, מחזור חיי פרויקט, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים, פורטפוליו פרויקטים

"חוקי הפסקה"  בתנאים של אי- וודאות- מתי בפעם האחרונה נתקלתם בפרויקט שנעצר והופסק? (ולא כי הלקוח ביטל הזמנה…)

הפסקת וביטול פרויקטים

חוקים בתנאים של אי-וודאות

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

חוקים בעולם ניהול הפרויקטים

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

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

חוקי הפסקה

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

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

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

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

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

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

אחד החוקים שאני מכירה בהקשר הזה הוא של פרופ' בעז רונן, שמדבר על "תפיסת 25/25":

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

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

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

 

בהצלחה! ואיחולי שנה אזרחית טובה

כאן בשבילך, גלית יסקרביץ- טיץ, וצוות Leadera

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

More
2205 0
איך נאס"א מנהלת את תוכנית הפרויקטים השנתית
יולי 11 2018 Galit מאמרים 0 comments Tags: PMBOK, PMI, PMO, PPM, ארגון ושיטות, בקרת פרוייקטים, בקרת פרויקט, מחזור חיי פרויקט, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים, פורטפוליו פרויקטים

איך נאס"א* מנהלת את תוכנית הפרויקטים השנתית

http://leadera.co.il/

http://leadera.co.il/

תכנון שנתי

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

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

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

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

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

תוכנית ששת השלבים של נאס"א

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

  1. בניית תוכנית אסטרטגית
  2. קריאה להצעות
  3. ציונים ועדיפויות
  4. איחוד
  5. התכנסות
  6. תכנית שנתית

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

1. בניית תכנית אסטרטגית

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

2. קריאה להצעות

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

3. ציונים והעדפות

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

  • Compliance: אליו פרויקטים שהארגון מחויב אליו על פי דרישות רגולציה
  • חזון: פרויקטים שיעזרו לארגון לעמוד במטרות ארוכות הטווח שלו
  • חדשנות: רעיונות שאף אחד לא עשה קודם
  • יכולות חדשות: פרויקטים שיכניסו יכולות חדשות לארגון
  • שימור של יכולות: פרויקטים שנדרשים כדי לשמר יכולות קיימות (למשל שדרוג גרסה למוצר לפני End of life)

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

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

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

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

4. איחוד

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

5. התכנסות

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

6. תכנית שנתית

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

מה הלאה

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

בגוף הידע בניהול פרויקטים, ה-PMBOK יש תרשים שמתאר את מעגל ה- Organizational Project Management בצורה פשוטה:

Figure 1-4. PMBOM ver 6, PMI

Figure 1-4. PMBOM ver 6, PMI

לסיום

נשמע הגיוני ומוכר?

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

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

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

בהצלחה!

כאן בשבילך, גלית יסקרביץ- טיץ, וצוות Leadera

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

*

נאס"א- מנהל האווירונאוטיקה והחלל הלאומי

NASA= National Aeronautics and Space Administration:

 

 

More
3582 0
האם יש עתיד לPMO?, מהו ה-PMO העכשווי?
אפריל 28 2018 Galit מאמרים 0 comments Tags: PMBOK, PMI, PMO, ארגון ושיטות, בקרת פרוייקטים, בקרת פרויקט, יעדי פרויקט, מה זה PMO, מנהל פרוייקטים, מנהל פרויקט, מתודולוגיה לניהול פרויקטים, ניהול ידע, ניהול פרוייקטים, ניהול פרויקטים, פורטפוליו פרויקטים, שינוי ארגוני

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

מי שלא הולך קדימה הולך אחורה

מיכאל גורבצ'וב אמר ש"מי שלא צועד קדימה במוקדם או במאוחר ימצא את עצמו צועד אחורה". כמו בכל מקצוע, גם ה- PMO (Project Management Office)  צריך להתקדם ולהתאים את עצמו לדרישות העדכניות של הארגון שלו והשוק בכללותו. בימים אלו, כשמדברים על "עולם בהפרעה" (Disruptive world)- הדבר נכון פי כמה וכמה.

יש הרבה יישומים של PMO

במחקר גלובלי של Project Management Solutions נאמר שב-2016 ל-85% מהחברות יש גוף PMO  פעיל!, ואחוז זה עולה ככל שהארגון גדול יותר. זה מספר עצום ביחס לתפקיד שעד לפני כמה עשרות שנים לא היה קיים בכלל.
גיל ממוצע של גוף PMO  הוא 5 שנים, כאשר חלק ניכר מה-PMO  מתמודדים עם האתגר של להוכיח את ערכם על בסיס קבוע. אתגר נפוץ נוסף הוא להתמודד עם התפיסה של העובדים בארגון שתהליכי עבודה בניהול פרויקטים נתפסים כבירוקרטיה ותקורה מיותרת.

יש הרבה מודלים ויישומים של PMO  (Project Management Office), שמתורגם בעברית ל"משרד לניהול פרויקטים". בLeadera- אנחנו מסייעים ללקוחותינו להקים ו/או לשדרג גופי PMO, ואצל כל לקוח אנחנו רואים הגדרות ויישומים שונים של התפקיד.

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

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

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

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

להלן שני תחומים שכאלו.

http://www.freedigitalphotos.net/

http://www.freedigitalphotos.net/

התפתחויות המשפיעות על ה- PMO

חיבור לביזנס באמצעות מנגנוני PPM- Project Portfolio Management-

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

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

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

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

סוגיות כמו חלוקת משאבים טובה יותר בין הפרויקטים; תעדוף של פרויקטים וסינון שלהם לפורטפוליו על פי רמת התרומה שלהם לאסטרטגיה העיסקית; שיקולים של Time to Market; קבלת החלטות על פתיחת ו/או סגירת פרויקטים בראייה ארגונית כוללת; בניית תוכניות עבודה שנתיות או תקופתיות;  ועוד.

התאמה לסביבה פרויקטלית דינאמית-

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

כבר כיום רואים בארגונים ערב רב של שיטות וסוגי ניהול. בעוד ה- Agile תופס כל חלקה טובה בפרויקטי פיתוח תוכנה, הרי שבפרויקטים המערבים דיספלינות נוספות רואים גיוון ושונות בשיטות ניהול הפרויקט. בחלק מהמקומות פרויקטים מסוימים עובדים אג'ילי וחלק אחר Waterfall . ב-PMBOK  האחרון, ורסיה 6, יש פירוט של מגוון השיטות שניתן למצוא כיום- אג'ייל, מחזורי Iterative)), מסתגל (Adaptive) או היברידי.

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

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

 

PMO- "איך" יותר מ"מה"

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

סיכום

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

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

בהצלחה!

כאן בשבילך, גלית יסקרביץ- טיץ, וצוות Leadera

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

 

 

More
8145 0

נשמח לעמוד לרשותכם

ניוזלטר

הירשמו בחינם לניוזלטר שלנו ותהיו הראשונים לקבל את כל המאמרים החדשים והעדכונים שלנו

הפתרונות שלנו

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

מאמרים מומלצים

  • מה זה PMO?
  • ניהול פורטפוליו פרויקטים – למה?
  • טיפוח ושימור מנהלי הפרויקטים לשם הגדלת ריווחיות החברה
  • מנהל פרויקט- יש לך ספונסר?
  • English

קטגוריות נפוצות

  • ביקורים- ניהול פרויקטים בארגונים
  • הצצה לפרויקט
  • ללא קטגוריה
  • מאמרים
  • קצרצרון

פוסטים אחרונים

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

נשמח לעמוד לרשותכם

ניוזלטר

הירשמו בחינם לניוזלטר שלנו ותהיו הראשונים לקבל את כל המאמרים החדשים והעדכונים שלנו

הפתרונות שלנו

  • גיבוש תפיסה, הקמת ואיוש PMO
  • בניית קורסים מותאמים לצרכי הלקוח ומסלולי הכשרה וקריירה בניהול פרויקטים
  • פיתוח, שיפור והטמעת תהליכי עבודה ומתודולוגיה ארגונית בניהול פרויקטים
  • בניית מנגנון ייזום דרישות וניהול פורטפוליו פרויקטים
  • תכנון תכנית עבודה לפרויקט ובקרתו
  • English
Copyright © 2014 Leadera. All Rights Reserved.

ייעוץ ואסטרטגיה דיגיטלית – מיכאל פינגרוט | מיתוג ועיצוב – Nylon | פיתוח - Shmi Go La mobile