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
2944 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
3019 0
"חוקי הפסקה" בתנאים של אי- וודאות
דצמבר 29 2018 Galit מאמרים 0 comments Tags: PMBOK, PMI, ארגון ושיטות, בקרת פרוייקטים, בקרת פרויקט, מחזור חיי פרויקט, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים, פורטפוליו פרויקטים

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

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

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

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

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

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

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

חוקי הפסקה

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

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

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

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

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

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

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

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

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

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

 

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

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

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

More
2116 0
פרויקט חישמול הרכבת ותחנת יצחק נבון ירושלים
אוגוסט 01 2018 Galit ביקורים- ניהול פרויקטים בארגונים 0 comments Tags: PMI, איכות סביבה, אנרגיה, בטחון, בקרת פרוייקטים, יעדי פרויקט, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, ניהול פרוייקטים, ניהול פרויקטים, קבלני משנה, תחבורה, תשתיות

מה קורה כשישראלי, ספרדי, גרמני ואנגלי נכנסים לרכבת?

סיור ברכבת ישראל,  יולי 2018

מקור: רכבת ישראל

מקור: רכבת ישראל

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

 

מארחינו היו:

בת שבע שגב, מרכז המבקרים של הרכבת

נעמה ברקוביץ, מנהלת התארגנות רכבתית

עמית צלקה, סמנכל, ראש מינהלת החישמול

 

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

האחד פרויקט החישמול, והשני פרויקט הקמת תחנת האומה- יצחק נבון,

וסדר היום היה:

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

ת.ז. לקו המהיר, בפרויקט שנקרא "מהירה לבירה"

ת.ז. לפרויקט הקו המהיר ירושלים- תל אביב

ת.ז. לפרויקט הקו המהיר ירושלים- תל אביב

 

30 דקות,  זהו זמן הנסיעה הצפוי מתל אביב לירושליים
57  ק"מ של מנהרות וגשרים
65  מיליון נוסעים בשנה
93%  אחוזי דיוק בהגעת הרכבת
500  רכבות נוסעים ביממה
1700  ק"מ המסילה, 1200 מתוכם יחושמלו
67  תחנות נוסעים ברחבי הארץ
38  ק"מ מנהרות שנבנו בשתי שיטות כריה: פיצוץ ו-. TBM
3000  נוסעים קיבולת בשעת שיא צפויה ב- 2020

רכבת ישראל- רקע

55_רכבת-1

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

מדובר בתקציב של כ 100 מיליארד שח כאשר חלק מהתוכנית יבוצע על ידי רכבת ישראל (כל מה שמשיק לקווים קיימים), וחלק יבוצע על ידי נת"י (מע"צ לשעבר) בעיקר בכל הקשור לקווים חדשים ובתוליים

פרויקט חישמול הרשת הרכבתית

פרויקט החישמול_רכבת ישראל

פרויקט החישמול_רכבת ישראל

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

 

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

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

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

 

 

1.    סביבת העבודה

בעלי ענין בפרויקט החישמול_רכבת ישראל

בעלי ענין בפרויקט החישמול_רכבת ישראל

סביבת העבודה מאופיינת בריבוי תרבויות:

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

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

מצטרפת אליהם קבוצת יועצים גרמניים;

ואיתם חברת ניהול בריטית.

סוגר את החבורה רגולטור ישראלי.

 

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

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

ועוד. כלומר שהאתגר המרכזי הוא לא ההנדסה אלא ניהול תרבויות. החלטות ואחריות על החלטות של תרבות בלבד. נטו.

2. התקשרויות

שיטת התקשרות בפרויקט החישמול_רכבת ישראל

שיטת התקשרות בפרויקט החישמול_רכבת ישראל

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

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

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

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

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

 

אז איזה תובנות היו לי מהפרויקטים המורכבים האלו?

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

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

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

 

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

ולהתראות בסיורים הבאים, גלית

 

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

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

 

 

More
3669 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
3486 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
8048 0
לא חוסכים בחגיגות
ינואר 09 2018 Galit מאמרים 0 comments Tags: PMBOK, PMI, PMO, PPM, בקרת פרוייקטים, בקרת פרויקט, העברה מפיתוח לייצור, יעדי פרויקט, מדדים, מנהל פרוייקטים, מנהל פרויקט, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים

לא חוסכים בחגיגות

http://www.freedigitalphotos.net/

מה חוגגים?

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

למה לא בעצם?

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

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

צריך לחגוג סיום פרויקט!

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

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

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

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

איך לחגוג סיום פרויקט?

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

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

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

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

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

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

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

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

לסיום

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

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

 

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

גם לכם יש רעיונות וסיפורים על חגיגות סיום פרויקט? שתפו אותנו.

 

בהצלחה!

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

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

 

 

 

More
3010 2
רגע, אז מי בכלל אחראי?
דצמבר 25 2017 Galit מאמרים 0 comments Tags: PMBOK, PMI, RACI, בקרת פרוייקטים, מנהל פרוייקטים, מנהל פרויקט, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים, פרויקט, תקשורת בפרויקטים

רגע, אז מי בכלל אחראי?

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

על מטריצת ה- RACI ואופן השימוש בה.

 

RACI בניהול פרויקטים

RACI בניהול פרויקטים

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

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

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

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

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

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

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

 

חלוקת תפקידים ואחריות

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

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

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

 

RACI

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

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

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

אז בואו נסביר מה זה בדיוק:

RACI הם ראשי תיבות של

R – Responsible – אחראי לביצוע המשימה

A – Accountable – הנושא באחראיות להשלמת המשימה

C – Consulted – מי מתיעצים איתו לביצוע המשימה

I – Informed – מי שמיודע על פרטי המשימה

הרעיון הוא ליצר מטריצה שמגדירה עבור כל משימה מה סוג הסמכות שיש לכל עובד.

בואו נסתכל על דוגמא שתמחיש את הנושא:

יגאל מפתח את פיצ'ר X שיתממשק לפיצ'ר Y שמפתחת יעל. יוגב הוא מנהל הפרויקט ואירית היא מנהלת המרקטינג. עבור פיצ'ר X יגאל הוא -Responsible הוא זה שמבצע את העבודה, יעל היא Consulted כי הפיצ'ר שמפותח צריך להתממשק עם הפיצ'ר שהיא מפתחת, יוגב הוא Accountable כי הוא מנהל הפרויקט ואירית היא Informed כי היא רק צריכה לדעת שהפיצ'ר הסתיים. כך זה יראה בטבלה:

  יגאל יעל יוגב אירית
פיצ'ר X R C A I
פיצ'ר Y C R A I

 

מה הופך את RACI ליעיל?

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

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

 אז איך מנהלי פרויקטים משתמשים ב RACI?

יש שישה שלבים להגדרת המטריצה:

  1. הכנת רשימה של משימות הפרויקט
  2. זיהוי כל המעורבים בפרויקט
  3. זיהוי כל האחראים לביצוע (R) והאחראים למשימה (A)
  4. וידוא שיש רק A אחד לכל משימה
  5. הוספת כל המתיעצים (C) והמעורבים לידיעה (I)
  6. שיחה עם כל המעורבים בפרויקט ווידוא שכולם יודעים מה תפקידם

כללי "עשה ואל תעשה" לשימוש במטריצת RACI

  1. רק Accountable אחד! אם יש יותר מאיש זה כמו שיהיה יותר מנהג אחד באוטו….
  2. ודאו שהכמות הנכונה של אנשים הם Responsible. יותר מדי אנשים לאותה משימה זו דרך בטוחה לבזבוז זמן. אם המשימה קצרה ופשוטה ה A וה R יכולים להיות אותו אדם
  3. אל תשתמשו ביותר מדי Consultants. יותר מדי יועצים יאטו את המשימה ויגדמו לוויכוחים מיותרים ויותר מדי דעות
  4. שמרו על אנשים מיודעים, אולי לא צריך להתיעץ עם כולם, פשוט מספיק לידע אותם? שימו לב שיש אנשים בטור הזה, זה יחסוך אי נעימיות בהמשך הדרך.
  5. הפכו את ההכנה של המטריצה למשימה משותפת. כולם צריכים להרגיש בנוח עם התוצאות.

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

כנראה שה- RACI לא יבטיח שהעבודה תתבצע…, אבל לפחות כל אחד יודע מה חלקו במערכה, וזו כבר התחלה טובה-

בהצלחה!

 

ולקינוח סרטון קצר שמסביר מה זה RACI

More
8218 2
הכנות לחורף הגשום
נובמבר 26 2017 Galit מאמרים 0 comments Tags: PPM, בקרת פרוייקטים, בקרת פרויקט, דשבורד, יעדי פרויקט, מדדים, מנהל פרוייקטים, מנהל פרויקט, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים, פורטפוליו פרויקטים, פרויקט

הכנות לחורף הגשום

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

דשבורד ניהולי

http://www.freedigitalphotos.net/

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

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

הדשבורד (לוח המחוונים) נותן למנהלים עסקיים יתרונות רבים, כולל:

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

 

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

 

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

 

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

חריגות – בין אם מוצדקות או לא.

 

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

 

איך בונים את ה"מרזב" הזה נכון?

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

  1. בחירת ערכים (KPIs) להצגה – בכדי שהדשבורד יהיה אפקטיבי, חשוב להגדיר את הערכים המדויקים אותם נרצה למדוד ולהציג בכדי להשיג שיפור ארגוני משמעותי. לא נוכל לעקוב אחר כל המדדים הארגוניים ולכן חשוב לדייק מהם אותם נקודות בדיקה (checkpoint) קריטיים שישקפו את המצב בצורה המיטבית.
  2. אלמנטים ויזואלים – שימוש באלמנטים ויזואליים כמו גרפים, טבלות, חלוקה לריבועים, צבעים, גדלים וצורות – מה שנדרש כדי למנף תפיסה חזותית. במקביל יש להמנע מעודף צבעים או גרפים מתוחכמים מידי שיסיחו את הדעת מהמסר המרכזי. לרוב שימוש בצבעי הרמזור המוכרים (אדום, צהוב ירוק) מאפשרים למקד את תשומת הלב לאזורים "האדומים" לקבלת התייחסות.
  3. Less is More (פחות זה יותר) – אם הוא אינו מתאים לדף אחד, הוא אינו לוח מחוונים, זהו דוח! מתן תמונה עסקית מלאה על עמוד אחד (בהנחה שזה משקף בבהירות את תמונת המצב) מאפשר הבנה מהירה של במידע. מחקרים קוגניטיביים עסקו בשאלה כיצד המוח האנושי מעבד מידע והוכיחו כי היכולת לדמיין את כל מקורות המידע הקשורים זה בזה מעצימה את הקלות והבהירות בהבנת המשמעות הכוללת של מידע המוגדר ביתר דיוק.

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

בהצלחה!

כאן בשבילך, גילית סגל, וצוות Leadera

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

More
5149 1
האם רבין ניהל סיכונים בארוע הזה?
נובמבר 12 2017 Galit מאמרים 0 comments Tags: PMBOK, PMI, בקרת פרוייקטים, בקרת פרויקט, מנהל פרוייקטים, מנהל פרויקט, מתודולוגיה לניהול פרויקטים, ניהול סיכונים, ניהול פרוייקטים, ניהול פרויקטים

האם רבין ניהל סיכונים בארוע הזה?

 האם רבין ניהל סיכונים בארוע הזה?

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

 

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

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

הפוסט הפעם יעסוק בארוע איזוטרי ואנקדוטי על רבין, שבסופו של יום קשור לניהול סיכונים, וזה הולך ככה:

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

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

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

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

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

אתם כבר מנחשים מה קרה?….

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

איך זה קשור לניהול סיכונים בפרויקט?

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

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

הטיפול בו רבין בחר הוא למעשה תוכנית תגובה, Risk response, מסוג תוכנית מניעה. כלומר- אני  אנקוט בפעולה שמטרתה להקטין את הסבירות שהסיכון יתממש.

מהו סיכון שניוני?

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

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

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

עדכון למתודת ניהול הסיכונים

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

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

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

  • * הימנעות Avoid- פעולה כדי לסלק את האיום או כדי להגן על הפרויקט מפני השפעתו. לרוב היא כרוכה בשינוי תוכנית ניהול הפרויקט שמטרתו לסלק את האיום כליל.
  • * העברה Transfer- פעולה שמטרתה הסטה של השפעת האיום ואת האחריות למענה עליו לצד שלישי. העברת סיכון למעשה מוסרת לצד אחר את האחריות לניהול הסיכון. ההעברה אינה מבטלת את הסיכון וגם אין משמעותה התנערות מאחריות. היא תמיד כרוכה בתשלום פרמיית סיכון לצד השלישי שנוטל על עצמו את הסיכון. כדוגמת שימוש בביטוח בחשיפה לסיכון פיננסי.
  • * שיכוך Mitigate- פעולה כדי לצמצם את ההסתברות להתממשות הסיכון או את ההשפעה שלו. באופן הזה משככים וממזערים את עוצמת הסיכון (זו האסטרטגיה בה נקט רבין בסיפור שלפנינו)
  • * קבלה Accept- החלטה של מנהל הפרויקט והצוות להכיר בעצם קיומו של הסיכון ולא לנקוט בשום פעולה אלא אם הסיכון מתממש. אסטרטגיה זו מתאימה רק במקרים שבהם לא ניתן או לא כלכלי להתייחס לסיכון הספציפי בדרך אחרת.

אסטרטגיית תגובה חדשה- הסלמה

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

אז מה זה אומר?

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

 

בהצלחה!

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

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

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

More
2928 1
  • 1
  • 2

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

ניוזלטר

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

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

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

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

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

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

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

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

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

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

ניוזלטר

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

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

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

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

תנאי שימוש | מדיניות פרטיות