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

פרויקטים שמתקדמים בימי קורונה

דף הביתTag "מנהלי פרויקטים"
פרויקטים שמתקדמים בימי קורונה
אפריל 02 2020 Galit מאמרים 0 תגובות תגיות: PMO, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, מערכות מידע, נדל"ן, ניהול סיכונים, ניהול פרוייקטים, ניהול פרויקטים, פורטפוליו פרויקטים, פרויקט, תחבורה, תשתיות

פרויקטים שמתקדמים בימי קורונה

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

 

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

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

פרויקטים שנעצרים

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

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

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

 

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

במקומות רבים הפרויקטים ממשיכים כרגיל או כמעט כרגיל.

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

פרויקטים חיוניים

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

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

 

פרויקטים שפועלים תחת ההגבלות

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

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

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

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

פרויקטים בתנופה

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

פרויקטים שהואצו עקב המצב

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

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

 

פרויקטים שמצליחים למנף את המצב לטובה

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

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

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

מה זה אומר?

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

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

אני מאחלת לכולנו בריאות איתנה וחוסן נפשי,

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

 

 

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

קרא עוד
1877 0
ניהול פרויקטים בעולם טכנולוגי, ראיון לקראת הכנס השנתי 2019
יוני 22 2019 Galit ללא קטגוריה 0 תגובות תגיות: PMBOK, PMI, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, סולם קריירה בניהול פרויקטים

ראיון איתי ב"אנשים ומחשבים" לקראת הכנס השנתי ה-23 של PMI, העמותה לניהול פרויקטים בישראל, יום ג' 18 ביוני האולם ארועים LAGO ראשון לציון

 

"מנהל פרויקטים נדרש לסקרנות, מנהיגות – ומקצוענות"

אמרה גלית יסקרביץ'-טיץ, סגנית נשיא לקשרי תעשייה וממשל ב-PMI ישראל, העמותה לניהול פרויקטים; לדבריה, "השיח של ניהול פרויקטים כיום הוא סביב ניהול פרויקטים בעולם טכנולוגי"

פורסם במגזין אנשים ומחשבים

כנס PMI 2019

כתב: הילל יוסף

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

יסקרביץ'-טיץ התראיינה לקראת הכנס השנתי של העמותה. הכנס, בהפקת אנשים ומחשבים, יתקיים ביום ג', 18 ביוני, באולם אירועים LAGO, ראשון לציון. לצד פעילותה, בהתנדבות, ב-PMI ישראל, יסקרביץ'-טיץ מנהלת את Leadera – חברה שעוסקת בייעוץ מתודולוגי ובהדרכות לניהול פרויקטים.

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

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

12 מומחים בשני חלונות זמנים

במסלול, פירטה יסקרביץ'-טיץ, "ישתתפו 12 מומחים בשני חלונות זמנים. קבוצת המומחים שלנו כוללת מקצוענים בתחומים של: אג'ייל, SAFe שהיא טכניקת אג'ייל, לוחות זמנים של ניהול פרויקטים, סייבר, ניהול סיכונים, הגשת מכרזים, תפקיד ה-PMO, רכיבים רפואיים, פרויקטי IT ועוד. ההתייעצות אינה דורשת רישום מראש ואורכת עד חצי שעה לכל נועץ. בין השעות 11:30-13:00 תהיה לנו קבוצת מומחים אחת, ובין 14:00-16:30 – קבוצת מומחים שניה".

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

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

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

 

 

קרא עוד
2362 0
ניהול פרויקטים ואג'ייל- הצהרת מלחמה?
מאי 18 2019 Galit מאמרים 0 תגובות תגיות: PMBOK, PMI, אג'ייל, מחזור חיי פרויקט, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, מתודולוגיה לניהול פרויקטים, פרויקט

ניהול פרויקטים ואג'ייל- הצהרת מלחמה?

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

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

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

 Agile Practice Guide

Agile Practice Guide

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

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

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

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

גרף האפשרויות נראה כך:

Source: Agile Practice Guide, PMI& Agile Alliance

מה אומרת כל גישה?

הסבר קצר על כל אחת מהגישות:

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

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

דוגמאות…

 

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

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

 

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

 

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

איך זה נראה בפרקטיקה?

באופן טבעי, ככל שהעולם נהיה דינאמי יותר ו"משובש" יותר- הנטיה היא לכיוון ניהול אג'ילי יותר, לתפיסת ניהול גמישה יותר (Agile mindset).

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

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

 

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

מחזקת את ידיכם!, גלית

אז בהצלחה בניהול הפרויקטים! אנחנו כאן ב- Leadera  כדי לסייע.

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

קרא עוד
2863 1
ניהול פרויקטים בעברית- המשך
אפריל 19 2019 Galit ללא קטגוריה 0 תגובות תגיות: PMBOK, PMI, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, ניהול סיכונים, ניהול פרוייקטים, ניהול פרויקטים, פרויקט

חברים יקרים,

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

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

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

אחרים הציעו הצעות שונות ומגוונות, להלן:

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

מה דעתכם?

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

 

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

אז גם לאתגר הזה כבר יש הצעות, להלן:

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

 

בהחלט מגוון הצעות מכובד!

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

גלית וצוות Leadera

 

התשובה של האקדמיה ללשון כפי שהתקבלה, באפריל 2019:

"שלום רב,

תודה על פנייתך.

אתחיל דווקא מהשאלה הרווחת למדי "מדוע באנגלית יש הבחנה בין [act/play; accountable/responsible; tree/wood ועוד] ובעברית לא?"

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

באנגלית wood (או למעשה woods) הוא גם יער שלם. ומצד שני העברית מבחינה בין קיר (של בית) לחומה (של עיר), ואילו האנגלית לא הרגישה צורך בהבחנה זו.

אשר לפרויקט – באנגלית המילה משמשת הן למיזמים גדולים כמו שיקום שכונות וסלילת כבישים הן לעבודות שורשים ולמטלות למידה, ואילו דווקא בעברית מונחים שונים משמשים בהקשרים שונים: תָּכְנִית, מֵיזָם, מִפְעָל, מַטָּלָה, עֲבוֹדָה ועוד. אם כן, מדוע צריך לחדש עוד מילים?

בברכה,

ויקי טפליצקי בן-סעדון

האקדמיה ללשון"

קרא עוד
2047 0
Ata menahel proyekt?
מרץ 09 2019 Galit מאמרים 0 תגובות תגיות: PMBOK, PMI, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, ניהול סיכונים, ניהול פרוייקטים, ניהול פרויקטים, פרויקט

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

את/ה מנהל/ת פרויקט?

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

 

קרדיט תמונה- האתר גלים

קרדיט תמונה- האתר גלים

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

 פרויקט

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

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

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

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

אז מה אתם אומרים, אני מנהלת אזרקים?….

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

 

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

תכנון?

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

סביר להניח שהפעולה שהוא עשה היא "תכנון" והתוצר של הפעולה היא "תוכנית".

אז איפה האבחנה שקיימת באנגלית בין Plan לבין Design?

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

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

ומה עם אחריות?

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

אז למה באנגלית יש שתי מילים שונות: Accountable ו- Responsible? ואיך זה שבעברית יש רק מילה אחת לשתיהן והיא "אחריות"?

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

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

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

טוענים ששפה משקפת תרבות, אז מה זה אומר עלינו?…

 

סיכונים

ואחרון חביב להפעם- ניהול סיכונים בפרויקט.

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

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

 

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

מצאתם עוד מילים כאלו? אשמח לשמוע, שתפו.

 

מחכים להצעות שלכם!,

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

 

 

קרא עוד
2729 1
היום מצפים ממנהל פרויקט ליותר!
פברואר 23 2019 Galit מאמרים 0 תגובות תגיות: PMBOK, PMI, מנהל פרוייקטים, מנהל פרויקט, מנהל פרויקטים, מנהלי פרויקטים, ניהול פרוייקטים, ניהול פרויקטים, פרויקט

היום מצפים ממנהל פרויקט ליותר!

http://www.freedigitalphotos.net/

http://www.freedigitalphotos.net/

מיהו מנהל הפרויקט העתידי?

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

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

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

אז מה עכשיו?

תכונות נוספות שמצפים שיהיו למנהל פרויקט

הדיון על מיהו מנהל הפרויקט המתאים והמקצועי נמשך, כמו למשל בסקר של PMI על The Project Manager of the Future . אנחנו ב-Leadera עוסקים בנושא בלא מעט פוסטים (ענווה, גריט, פיצוח אגוזים ועוד). השינויים התכופים שקורים בעולם בקצב גובר והולך, משפיעים גם על התפקיד של מנהל הפרויקט, וזה עוד לפני שנכנסנו לדיון על מהו תפקידו של מנהל פרויקט שעובד בגישה האג'ילית.

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

  • להגיב מהר – כל שינוי שקורה מצריך טיפול מיידי ולא "בגרסה הבאה". אם אני מנהל פרויקט שמכין אפליקציה לטלפונים ויוצאת גרסת אנדרואיד חדשה, אי אפשר לחכות ואני חייב להתאים מיד את האפליקציה לגרסה החדשה.
  • לספק מידע רציף – אם פעם היינו מכינים דוחות ופעם בשבוע/חודש היינו מציגים אותם להנהלה, היום יש ציפייה שהמידע יהיה זמין ולרשות המנהלים יהיה דשבורד עם כל נתוני הפרויקט מעודכנים אונליין.
  • לייעץ ולקשר – בגלל המבנה המורכב של הנהלת הפרויקט יש ציפייה ממנהל הפרויקטים שיהיה לפעמים יותר יועץ ומקשר ממנהל. לדוגמא בפרויקטי אג'ייל שבהם יש מספר מובילים כמו ה- Scrum Masters וה- Product Owner , יש צורך שמנהל הפרויקט יהיה יועץ לאותם אנשים שלפעמים מומחים בתחומם אבל חסרים ידע וניסיון בעולמות ניהול הפרויקטים. דוגמא אחרת היא של פרויקטים בהם מספר רב של קבוצות מדיסיפלינות שונות ואז מנהל פרויקט הוא הגורם שמקשר בין כל הגופים ו"מביא אותם לשולחן" כשיש צורך לפתור בעיות.
  • להתאים את גישת הפרויקט לצורך ולסביבת הפרויקט- כבר לא מדובר במתודה אחת שברגע שאני מכיר אותה- אני מסודר. היום מדברים על ריבוי גישות (דוגמת אג'ייל, ניתן לחיזוי ועוד) שאני צריך להכיר ולדעת לעשות את ההתאמה הרלבנטית לפרויקט שאני מוביל בהתאם למאפייניו, ואף לשלב בין גישות במה שנקרא "היברידי". למשל, האם יש לי תוכנית מוגדרת ויכולת להגדיר את דרישות הפרויקט בצורה מפורטת כבר בתחילתו, או שהדרישות מוגדרות תוך כדי עבודה? כל אחת מהסיטואציות תגרור אופי אחר של תכנון, בראשונה התכנון חד פעמי ובשניה התכנון הוא דינאמי.
  • להבין במספר רב של תחומים –מנהל הפרויקט צריך להיות מעורה בכל חלקי הפרויקט. וכיוון שהפרויקטים פעמים רבות הם מולטי- דיספלינריים, מתקבל שמנהל הפרויקט צריך להבין בתחומים רבים. לא סתם ב-PMBOK יש 10 תחומי ידע הכוללים בין השאר ניהול עלויות, התקשרויות ורכש, איכות, ועוד נושאים שבמבט ראשון לא בהכרח נראים קשורים למנהל הפרויקט.
  • לוודא ולהתנהל בחוזים גמישים – כיוון שהשינויים תכופים, פעמים רבות אנו מוצאים את עצמנו נדרשים לשנות את תכולת הפרויקט תוך כדי תנועה. אם יש לנו קבלני משנה שמסייעים בפיתוח הפרויקט אנחנו חייבים להבטיח שהחוזים איתם גמישים מספיק ומכילים פתרון למצב של שינוי תכולה כך שלא נצטרך לשלם סכומים גדולים בכל שינוי שנעשה.

ועוד

עולם משובש והשפעתו על ניהול הפרויקטים

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

השפעת שינויים כלכליים/ פוליטיים על פרויקטים

למשל:

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

ועוד

השפעת שינויים טכנולוגיים על פרויקטים

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

  • ענן, Cloud-
    יש האומרים שאם אתה לא שם אתה לא קיים. כמעט כל מוצר ושירות חושב איך לשלב את שרותי הענן בשירותים שלו. גם נושא הרשתות החברתיות (שכולן כמובן בענן) מצריך אותנו לחשוב איך ההשפעה של כל שינוי מגמה משפיעה על הפרויקט שלנו.
  • האינטרנט של הדברים, IOT – Internet of Things-
    היום כמעט כל מכשיר הופך "חכם" ולפעמים זה אומר שגם הפרויקט שלנו צריך להיות "חכם".
  • בינה מלאכותית, AI – ArtificialIntelligence-
    היכולות ההולכות וגדלות של בינה מלאכותית יכולות לגרום לנו לשנות את אופן פיתוח המוצרים שלנו ואת אופן קבלת ההחלטות בפרויקט.
  • Big data-
    יכולות ניתוח המידע שקימות היום יכולות להשפיע על ההחלטות שאנחנו מקבלים וכך גם על כיווני הפיתוח של המוצרים. יש לה השפעות גם בעולם ניהול בפרויקטים. אם למשל תבצעו ניתוח היסטורי של כל הפרויקטים שהתבצעו בחברה תוכלו לזהות סיכונים פוטנציאלים הרבה יותר טוב. היום שמתחיל פרויקט ואנחנו שואלים את האנשים מה הסיכונים, הרוב עדיין אופטימיים וכמות הסיכונים קטנה. אם ננתח מידע היסטורי נוכל לזהות סיכונים שלא עלו בשיחות עם האנשים.
  • Blockchain –
    היום יותר ויותר אנשים רוצים להשתמש במטבעות קריפטוגרפיים וההנחה שהמספר רק ילך ויגדל. אם אני היום מנהל פרויקט של מכירת מוצרים כדאי לי לשאול את עצמי אם לתמוך בתשלומים בביטקוין ודומיו או לא.
  • רובוטים ורכבים אוטונומיים-
    שני תחומים שיכולים להפוך על פיהם פרויקטים רלוונטיים ביחוד בעולמות הייצור והרכב.

 

אז מה כל זה אומר?

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

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

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

 

אז בהצלחה בניהול הפרויקטים! אנחנו כאן ב- Leadera  כדי לסייע.

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

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

קרא עוד
1915 1
ניהול היבטי סייבר בפרויקט בשיטה ההוליסטית
פברואר 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

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

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

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

קו סיום

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

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

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

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

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

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

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

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

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

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

אתן דוגמא-

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

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

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

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

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

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

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

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

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

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

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

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

 

קרא עוד
1905 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.

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

 

 

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

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

 

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

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

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

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

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

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

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

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

אתר גודי'ז

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

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

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

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

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

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

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

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

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

 

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

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

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

 

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

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

קרא עוד
1565 0
  • 1
  • 2

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

ניוזלטר

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

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

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

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

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

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

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

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

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

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

ניוזלטר

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

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

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

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

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