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

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

דף הביתTag "ניהול פרויקטים"
ניהול היבטי סייבר בפרויקט בשיטה ההוליסטית
פברואר 15 2019 Galit מאמרים 0 תגובות תגיות: 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

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

קרא עוד
127 1
מהי נקודת סיום פרויקט?
ינואר 30 2019 Galit מאמרים 0 תגובות תגיות: יעדי פרויקט, מדדים, מחזור חיי פרויקט, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, מערכות מידע, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים, פרויקט, תשתיות

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

קו סיום

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

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

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

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

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

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

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

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

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

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

אתן דוגמא-

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

אני שמחה לארח בבלוג שלנו פוסט מאת סא"ל רן שניאור, לשעבר ראש מדור ניהול ובקרת פרויקטים 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.

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

 

 

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

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

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

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

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

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

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

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

חוקי הפסקה

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

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

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

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

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

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

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

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

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

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

 

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

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

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

קרא עוד
339 0
ענווה בניהול פרויקטים?
דצמבר 16 2018 Galit קצרצרון 0 תגובות תגיות: מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, מערכות מידע, ניהול פרויקטים, סולם קריירה בניהול פרויקטים, קורסים בניהול פרויקטים

מישהו עוד זוכר את התכונה ענווה? עוד מעולמו של מנהל פרויקט

 

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

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

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

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

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

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

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

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

אתר גודי'ז

https://www.goodiz.tv/ramon-crater-roundtrip/

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

השתרר שקט בחדר…

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

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

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

אז הלכתי ובדקתי את הפירוש בוויקפדיה:

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

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

 

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

אז אני השתכנעתי, ומה אתם אומרים?

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

 

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

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

קרא עוד
553 0
אסטרטגיית רכש בפרויקט- חלק ב'
נובמבר 28 2018 Galit מאמרים 0 תגובות תגיות: PMBOK, PMI, מימשקים, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, מתודולוגיה לניהול פרויקטים, ניהול סיכונים, ניהול פרוייקטים, ניהול פרויקטים, פרויקט, קבלני משנה

אסטרטגיית רכש בפרויקט

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

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

למה אסטרטגיית רכש חשובה?

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

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

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

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

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

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

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

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

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

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

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

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

השיתוף הזה יסייע לי להפוך את איש הרכש מ"גורם עוין" ל"גורם מאפשר".

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

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

ותודה לדן על הסיוע בכתיבת הפוסט!

נסו ושתפו איך היה לכם,

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

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

קרא עוד
377 1
אסטרטגיית רכש בפרויקט- חלק א'
נובמבר 14 2018 Galit מאמרים 0 תגובות תגיות: PMBOK, PMI, יעדי פרויקט, מימשקים, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, מתודולוגיה לניהול פרויקטים, ניהול סיכונים, ניהול פרוייקטים, ניהול פרויקטים, פרויקט, קבלני משנה, תשתיות

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

https://www.schmalz.com/en/services/procurement/

רכש בפרויקטים

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

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

מה זה "אסטרטגיית רכש"?

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

ניהול הרכש כולל 4 תהליכים כאשר הפעם נתרכז בראשון מבינהם שהוא תכנון ניהול הרכש (תהליך 12.1). תהליך שמטרתו תיעוד החלטות רכש של הפרויקט ובראשן החלטת קנה-יצר (Make or Buy)- האם לקנות חלק מהמוצרים או השירותים מחוץ לפרויקט או לעשות ייצור עצמי. בנוסף תהליך זה כולל פירוט הגישה וזיהוי ספקים אפשריים. במסגרת תכנון ניהול הרכש, מומלץ לבנות את אסטרטגיית רכש (שזה אגב, חידוש שלא היה בוורסיה 5 והתווסף בגרסה הנוכחית של הספר, גרסה 6).

אסטרטגיית הרכש (Procurement strategy ) היא אוסף ההחלטות הנדרשות לגבי אופן ביצוע הרכש וההתקשרויות. החלטות אלו כוללות:

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

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

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

כמה דוגמאות:

  • - למשל, הקמת כביש 6 בוצעה על ידי חברת דרך ארץ, שהיא זכיינית שנבחרה על ידי המדינה, והגישה הייתה Build-Operate-Transfer (BOT) בנה-הפעל-העבר, שפרושו שדרך ארץ הקימה את הכביש, מימנה את הקמתו, ומתפעלת אותו למשך תקופה קבועה מראש, שבסיומה יעבור הכביש לידי מדינת ישראל.
  • - או- הקמת מפעל כימי – את בניית החצרות והשלד אתן למתכנן חיצוני, שיקח אחריות תכנון וביצוע ועמידות של המבנה לדרישות שלי, אבל את תכנון המערך הכימי באם זה IP שלי, אני אהיה אחראית על התכנון ואתן לקבלן לבצע את ההקמה (ביצוע).
  • - פרויקטי תשתית במדינה בוצעו שנים רבות בגישת מכרזי ביצוע, כלומר שהסקטור הציבורי אחראי על התכנון המפורט של הפרויקט ומוציא מכרז לבחירת גורם מבצע ופיקוח על הביצוע. הגורם המבצע עוסק בתהליך ההקמה ובסיומו הוא מוסר את הפרויקט לגורם הציבורי המזמין שמתפעל אותו.
  • - בשנים האחרונות הוכנסה גם שיטה של Design-Build (DB) תכנון- ביצוע, לפיה הגורם הציבורי מבצע תכנון ראשוני בלבד ומעביר את האחריות לתכנון מפורט + לביצוע אל הסקטור הפרטי.
    וכן הלאה.

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

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

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

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

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

  1. שלבי הרכש ומעבר משלב לשלב-
    מה השלבים השונים של הרכש ומה קורה בכל שלב, איזה אבני דרך ישמשו לבקרה, מה הקריטריונים לעבור משלב לשלב וכד'.

 

זוהי אסטרטגיית רכש לפרויקט.

למה היא חשובה ואיך זה קשור אליי כמנהלת פרויקט?- על זה בפוסט המשך. הרשמו לניוזלטר שלנו (בחלק החתון של הדף) כדי לקבל את חלק ב'.

 

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

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

*כשמדובר בפרויקט הקמה או בינוי, צריך להחליט האם הגישה היא turnkey, design build (DB), Design build operate (DBO), build own operate transfer (BOOT)  וכו'
**סוגי חוזים מקובלים הם: fixed price, cost plus, time and material ועוד.

קרא עוד
509 0
מה זה פרה- מורטם?
ספטמבר 01 2018 Galit קצרצרון 0 תגובות תגיות: PMBOK, PMI, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, מתודולוגיה לניהול פרויקטים, ניהול סיכונים, ניהול פרוייקטים, ניהול פרויקטים

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

ולכן כבר כתבנו לא מעט פוסטים בנושא:

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

פרה- מורטם

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

– לזהות את הסיכונים הפוטנציאליים;

– לתת להם ציון שמבוסס על הסבירות להתממשות הסיכון כפול חומרת הסיכון במידה ויתממש;

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

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

 

אחת הטכניקות הפופולריות בימים אלו נקראת Pre Mortem, או בעברית "פרה מורטם" :)

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

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

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

וזוהי טכניקת הפרה- מורטם.

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

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

 

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

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

קרא עוד
698 0
ברבור, סרטן וזאב מים
אוגוסט 27 2018 Galit קצרצרון 0 תגובות תגיות: בעלי ענין, מיומנויות בניהול פרויקטים, מימשקים, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, ניהול פרוייקטים, ניהול פרויקטים, קורסים בניהול פרויקטים

ברבור, סרטן וזאב מים

רק עכשיו שיתפתי את המחקר החדש שפורסם ב World Economic Forum וסוקר את המיומנויות שידרשו ב- 2020 לעומת 2015.
על פי המחקר ניהול אנשים (People management)  ותיאום עם אחרים (Coordination with others) יורד בחשיבותו ממקומות 2-3 בשנת 2015 למקומות 4-5 בשנת 2020, שזה האמת הפתיע אותי. יורד?

https://www.weforum.org/agenda/2018/08/here-s-how-vulnerable-to-automation-your-job-is/

 

 

 

 

 

 

 

 

 

 

 

 

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

 

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

עילית נר, מצגת משרד החינוך למשל קרילוב

עילית נר, מצגת משרד החינוך למשל קרילוב

מדובר במשל בשם "ברבור, סרטן וזאב המים" (ידעתם שיש חיה כזו זאב מים?!…)

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

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

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

 

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

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

קרא עוד
807 4
פרויקט חישמול הרכבת ותחנת יצחק נבון ירושלים
אוגוסט 01 2018 Galit ביקורים- ניהול פרויקטים בארגונים 0 תגובות תגיות: 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.

 

 

קרא עוד
815 0
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9

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

ניוזלטר

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

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

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

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

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

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

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

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

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

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

ניוזלטר

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

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

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

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

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