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

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

דף הביתTag "מחזור חיי פרויקט"
ניהול פרויקטים ואג'ייל- הצהרת מלחמה?
מאי 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.

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

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

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

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

קו סיום

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

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

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

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

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

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

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

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

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

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

אתן דוגמא-

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

חוקי הפסקה

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

http://leadera.co.il/

http://leadera.co.il/

תכנון שנתי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. איחוד

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

5. התכנסות

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

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

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

מה הלאה

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

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

Figure 1-4. PMBOM ver 6, PMI

Figure 1-4. PMBOM ver 6, PMI

לסיום

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

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

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

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

בהצלחה!

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

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

*

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

NASA= National Aeronautics and Space Administration:

 

 

קרא עוד
2333 0
תחת אבטחה
מרץ 25 2018 Galit מאמרים 0 תגובות תגיות: PMO, אבטחת מידע, יעדי פרויקט, מחזור חיי פרויקט, מנהל פרויקט, מערכות מידע, מתודולוגיה לניהול פרויקטים, ניהול סיכונים, ניהול פרוייקטים, ניהול פרויקטים, קבלני משנה, קורסים בניהול פרויקטים, רגולציה, תשתיות

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

אבטחת מידע כצוואר בקבוק בפרויקט

 

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

למה זה?- כי מחד דרישות אבטחת מידע הן מחייבות ומחמירות, ומאידך- חוסר זמינות של צוות אבטחת המידע בארגון לתמוך בפרויקט (עקב עומס ועבודה מרובה בכל הפרויקטים), לא מאפשר למנהל הפרויקט להתקדם כראוי ובקצב הנדרש.http://www.freedigitalphotos.net/

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

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

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

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

התכונות של פעילות מערכות מידע מייצרות פגיעות שלהן. תכונות אלו כוללות:

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

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

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

(כנגדם אגב מתפתח תחום חדש יחסית של ביטוחי סייבר…)

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

  • - פרויקטים בתחום מערכות מידע (IT), הכוללים התקנה או שידרוג של מערכות המיחשוב שמאפשרות לעסק לפעול- קרי התקנה של מערכות Enterprise resource planning (ERP)  או Customer relationship management (CRM) בארגון, משאבי אנוש, מערכות פיננסיות וחיובי לקוחות, מערכות ייצור והפצה ועוד; תשתיות מיחשוב של מחשבים, שרתים, ניידים, מערכת דוא"ל, תקשורת לחדרי ועידות וכו.
    לדוגמא מערכת לשינוע חומרי גלם וסחורות ללקוחות בעולם, שמחוברת למערכות של ספקי משלוחים באוניות ואלו מזינים למערכת נתוני מיקום GPS, זמני הגעה ועוד
  • - פרויקטי פיתוח מוצר, הכוללים מוצרים טכנולוגים פיסיים (חומרה) או אפליקטיביים (תוכנה), דוגמת טלפונים ניידים, אוזניות, אפליקציות, שירותי אונליין ועוד.
    לדוגמא, פיתוח תוכנה לניטור ביצועי תחנות קצה של משתמשים, שכיוון שמחזיקה מידע של ועל משתמשים, מחייבת לבצע ולהציג סקר סיכוני אבטחת מידע של המשתמשים.
    סקר זה אגב, בוצע ע"י חברה חיצונית כדי לקבל אישור להתקין את המוצר אצל הלקוח, מה שהוסיף עוד גורם שצריך לתאם איתו ועוד תוספת זמן משמעותית לפרויקט (הסקר יכול להתבצע רק בסוף וצריך להשאיר זמן לתיקונים).
  • - פרויקטים הנדסיים של הקמת מיבנים, אתרים ומפעלים, הכוללים מערכות שליטה ובקרה (במידה והללו מאפשרים כניסת נתונים מבחוץ ואין הפרדה בין רשת פנים לרשת חוץ): דוגמת מערכות שליטה במשאיות תובלה, בניית מבנים עם מנגנוני בקרה מרחוק, הקמת קווי ייצור נשלטי מחשב ועוד.
    למשל, הקמת תחנת כח, שכיוון שעוסקת בייצור אנרגיה היא נמצאת תחת רגולציה של אבטחת מידע תחת רא"מ (רשות אבטחת מידע).

בקיצור- כמעט כל הפרויקטים…

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

למשל, רגולציית ה-(GPDR) General Data Protection Regulation (EU), שתכנס לתוקף במאי 2018, היא אירופאית ומגיעה כחוק עם אכיפה ושיניים חזקים ביותר. החוק מטיל אחריות אישית על הארגון ומנהליו ולא מאפשר להעביר אחריות לגורם מיקור חוץ שביצע את הפרויקט. במקרה של הפרה, קנסות יכולים להגיע גם ל4% מהמחזור השנתי של החברה המפרה…

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

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

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

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

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

 

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

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

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

 

 

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

תודה לאייל, דורון ואיזית על ההכוונה.

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

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

קרא עוד
2154 2
גיוון והכלה בניהול פרויקטים
דצמבר 11 2017 Galit מאמרים 0 תגובות תגיות: גיוון והכלה, מחזור חיי פרויקט, מימשקים, מנהל פרוייקטים, מנהל פרויקט, ניהול פרוייקטים, ניהול פרויקטים, צוות הפרויקט

גיוון והכלה בניהול פרויקטים

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

גיוון והכלה בניהול פרויקטים

http://www.freedigitalphotos.net/

מה הכוונה בגיוון (Diversity) והכלה (Inclusion)?

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

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

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

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

(מבוסס על הנאמר באתר של שטראוס)

 

אז למה זה נהיה טרנדי וחשוב פתאום?

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

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

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

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

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

 

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

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

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

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

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

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

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

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

גיוון מקצועי או גיוון אנושי?

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

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

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

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

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

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

 

מה אני עושה עם זה?

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

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

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

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

 

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

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

 

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

 

בהצלחה!

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

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

 

קרא עוד
2390 1
מה הפעיל את הצ'קלקה?
אוקטובר 16 2017 Galit מאמרים 0 תגובות תגיות: PMBOK, PMI, PMO, PPM, בקרת פרוייקטים, מדדים, מחזור חיי פרויקט, מנהל פרוייקטים, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים

מה הפעיל את הצָ'קָלָקָה באבחון?

אתגרים בהטמעת תהליכים בניהול פרויקטים  - PMO

אתגרים בהטמעת תהליכים בניהול פרויקטים- PMO

הקניית שיטות עבודה בניהול פרויקטים כחלק מתפקידו של גוף ה-PMO

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

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

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

אז מה לא עובד?- אחרי האופוריה הופעלה הנורה האדומה

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

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

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

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

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

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

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

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

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

לסיכום

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

 

בהצלחה! גילית סגל, גלית יסקרביץ- טיץ, וצוות Leadera

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

קרא עוד
1904 0
מה זה מסמך ייזום? ואיך הוא קשור ליציאה לחופשה?
יולי 13 2017 Galit מאמרים 0 תגובות תגיות: PMBOK, PMI, PMO, יעדי פרויקט, מחזור חיי פרויקט, מנהל פרוייקטים, מנהל פרויקט, מסמך ייזום, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים

 

http://www.freedigitalphotos.net/

Project charter

מה זה מסמך ייזום?

את המונח מסמך ייזום כבר שמעתם? ואולי כתב אמנה? יש כאלה המכירים אותו בתור Project charter. אז על מה אנחנו מדברים פה בעצם?

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

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

 

מה כולל המסמך?

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

נושאים במסמך הם:

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

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

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

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

 

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

מכמה וכמה סיבות.

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

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

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

בנוסף המסמך עושה סדר ומבהיר מידע נחוץ לתחילת הדרך.

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

 

אז מה הקשר ליציאה לחופשה?

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

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

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

מסמך ייזום עוצרים בעין יהב

 

 

מסמך ייזום בראש שקט

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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

והכי חשוב- תבלו ותעשו חיים בחופשה!

 

להשתמע בפוסט הבא,

נטע קופלמן-הורביץ וגלית יסקרביץ-טיץ

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

 

קרא עוד
4620 1
פרויקט במרוץ שליחים
אפריל 19 2017 Galit ללא קטגוריה 0 תגובות תגיות: העברה מפיתוח לייצור, מחזור חיי פרויקט, מנהל פרוייקטים, מנהל פרויקט, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים, קורסים בניהול פרויקטים
http://www.freedigitalphotos.net/

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

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

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

"מה עושים" שאלו אותנו. והתשובה? "מעבירים מקל מסודר בדיוק כמו במרוץ שליחים"! כל ארגון והתהליך הארגוני שלו, כל ארגון והעברות המקל שלו. אחד הנפוצים הוא העברת המקל מארגון המחקר והפיתוח לארגון התפעול והייצור. בארגונים יצרניים שונים, הפרויקט מתחיל את דרכו בשלב הייזום במחלקת מחקר ופיתוח ועובר למחלקת התפעול והייצור בהמשך דרכו. בארגונים אחרים המקל עובר מהקמה לתחזוקה, יש כאלו בהם המקל עובר מיישום לשירות וכד'. בכל מקרה מדובר בתום הפרויקט ומעבר לשלב הבא כחלק מה- Life Cycle Cost (LCC).

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

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

אז המקל נפל – מה הבעיה?

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

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

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

והפתרון?

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

לסיכום

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

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

 

גילית סגל, מנהלת פרויקטים ויועצת בכירה Leadera

מומחית למצוינות וניהול פרויקטים בפריסה גלובלית

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

קרא עוד
3189 0
  • 1
  • 2
  • 3

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

ניוזלטר

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

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

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

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

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

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

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

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

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

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

ניוזלטר

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

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

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

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

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