האם יש עתיד לPMO?, מהו ה-PMO העכשווי?

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

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

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

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

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

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

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

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

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

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

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

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

http://www.freedigitalphotos.net/

http://www.freedigitalphotos.net/

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

סיכום

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

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

בהצלחה!

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

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

 

 

More
8146
תחת אבטחה
מרץ 25 2018 Galit מאמרים 0 comments Tags: 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

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

More
3485
זוגיות בניהול פרויקטים
מרץ 14 2018 Galit מאמרים 0 comments Tags: מנהל פרוייקטים, מנהל פרויקט, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים

סוחב את האחריות לבד?

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

לא בכדי אוהבים להגיד בעולם ניהול הפרויקטים Make it happen, תגרום לזה לקרות.

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

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

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

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

זה הוביל אותי לחפש קצת על הביטוי שנקרא Two in a box  (הכוונה למבנה ארגוני ניהולי שמייצר שותפות ניהולית), ולראות את ההתאמה שלו לעולם ניהול הפרויקטים.

אז איך ניתן לחלק אחריות?

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

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

סוגי חלוקת תפקוד אפשריים, עליהם למדתי במאמר מומלץ של  Harvard Business Review, הם:

  • על בסיס משימות (Task complementarity )- בדרך כלל תוך אבחנה בין משימות פנימיות לארגון או חיצוניות לארגון. אני קוראת לחלוקה הזו "שר הפנים ושר החוץ"- כלומר, האחד שאחראי על הסביבה החיצונית לארגון, והשני על הסביבה הפנימית של הארגון.
    חלוקה זו נפוצה מאד ועל בסיסה בנויים לרוב התפקידים של המנכ"ל CEO, וסמנכ"ל התפעול COO .
  • על בסיס מומחיות (Expertise complementarity)- כאשר כל אחד מומחה בתחום שונה ושתי המומחיות נדרשות למילוי המשימה. למשל אם אחד מומחה בפיננסים, השני ישלים עם מומחיות הנדסית והכרות עם המוצר.
    טוענים שזו היתה החלוקה בין ביל גייטס וסטיב באלמר במיקרוסופט, כאשר גייטס היה אחראי על החזון הטכנולוגי ובאלמר על השיווק והמכירות.
  • על בסיס השלמה קוגנטיבית (Cognitive complementarity )- כלומר באופן בן אנו מעבדים מידע. אחד רואה את התמונה הגדולה, החזון, המטרה, והשני בקיא בפרטים, בתהליכים, בדרך. נדיר למצוא מישהו שאצלו שני אלו שווים ולכן חלוקה על בסיס זה תהווה השלמה, כמו יזם ומבצע.
  • על בסיס תפקיד חברתי (Role complementarity )- לרוב לכל אדם יש תפקיד חברתי אחד בלבד, אי אפשר להיות אהוב ושנוא ביחד. למשל חלוקה שמוכרת בשם "השוטר הטוב" ו"השוטר הרע".

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

אלו למעשה שיטות ניהוליות, חלקן נפוצות למדיי.

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

http://www.freedigitalphotos.net/

http://www.freedigitalphotos.net/

Two in a Box בניהול פרויקטים

 

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

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

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

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

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

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

 

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

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

אם מי מכם מכיר או היה שותף לניהול פרויקט בשיטת Two in a box- נשמח לשמוע חוויות ותובנות.

 

בהצלחה!

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

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

More
2616
לא חוסכים בחגיגות
ינואר 09 2018 Galit מאמרים 0 comments Tags: PMBOK, PMI, PMO, PPM, בקרת פרוייקטים, בקרת פרויקט, העברה מפיתוח לייצור, יעדי פרויקט, מדדים, מנהל פרוייקטים, מנהל פרויקט, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים

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

http://www.freedigitalphotos.net/

מה חוגגים?

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

למה לא בעצם?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לסיום

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

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

 

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

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

 

בהצלחה!

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

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

 

 

 

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

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

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

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

 

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

RACI

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

בהצלחה!

 

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

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

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

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

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

http://www.freedigitalphotos.net/

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

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

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

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

 

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

 

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

 

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

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

 

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

 

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

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

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

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

בהצלחה!

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אז מה זה אומר?

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

 

בהצלחה!

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

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

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

More
3005
"מד דופק" לניהול פרויקטים בארגון מצליח
אוקטובר 29 2017 Galit מאמרים 0 comments Tags: PMBOK, PMI, PMO, יעדי פרויקט, מדדים, מנהל פרוייקטים, מנהל פרויקט, מתודולוגיה לניהול פרויקטים, ניהול פרוייקטים, ניהול פרויקטים, סולם קריירה בניהול פרויקטים, ספונסר

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

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

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

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

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

resource: PMBOK6 by PMI, Sep 2017

אז איך אני יכול להתקדם ולהשתייך ל"אלופים"?

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

  • שפה, טכניקות ושיטות-

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

 

  • כישורים רלבנטיים-

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

 

  • דפוסי פעולה נדרשים-

  • נמצאו מספר דפוסי פעולה שמאפשרים פרויקטים מצליחים:

  • עובדים הפועלים כשותף אסטרטגי בארגון שלהם

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

  • עובדים המחברים בין האסטרטגיה לפעולותיהם

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

  • עובדים המאמצים גישות גמישות

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

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

שורה תחתונה

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לסיכום

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

 

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

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

More
3079
מה התחדש בגרסת PMBOK החדשה?
ספטמבר 27 2017 Galit מאמרים 0 comments Tags: PMBOK, PMBOK6, PMI, PMO, PMP, מנהל פרוייקטים, מנהל פרויקט, מתודולוגיה לניהול פרויקטים, ניהול פרויקטים, קורסים בניהול פרויקטים

PMBOK6, גוף הידע בניהול פרויקטים בגרסתו החדשה

PMBOK6

PMBOK6 by PMI

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

למי שלא מכיר, ספר ה- (PMBOK) Project Management Body Of Knowledge , ובעברית- גוף הידע בניהול פרויקטים,  נודע גם בכינויו "התנ"ך בניהול פרויקטים" ומכיל את כל ההגדרות, מינוחים, תהליכים וטכניקות הנדרשים לניהול הפרויקט. הספר הוא מטעם Project Management Institute (PMI), העמותה העולמית לניהול פרויקטים, ששוקדת על עדכונו והפצתו מידי מספר שנים.

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

אז מה התחדש בורסיה הנוכחית?

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

אג'יליות

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

דגש על אסטרטגיה וידע עסקי

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

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

תפקידו של מנהל הפרויקט כמנהיג צוות הפרויקט

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

תחומי הידע, Knowledge Area

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

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

ניהול תכולה- יש התייחסות לממשק ולקשר בין מנהל הפרויקט ל- Business Analyst. PMI הוציאה לאחרונה את ה- Business Analysis Practice Guide וכעת היא מחברת ומתארת את המימשק בין שני התפקידים.

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

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

ניהול משאבי כח אדם- שינה שם והפך ל- Project Resource Management כדי לכלול את כלל המשאבים של הפרויקט ולא רק כח האדם.

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

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

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

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

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

 

בנוסף, נושא ה- ITTO, כלומר Inputs, Tools &Technique, Outputs , נעשה פשוט יותר כאשר מסמכים דומים קובצו תחת כותרות משותפת. למשל- Project Management Plan שמהווה אינפוט אחד ומכיל בתוכו תוכנית לניהול לוח זמנים, תוכנית לניהול תכולה, הערכת עלויות ועוד.

 

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

 

איך זה משפיע על ההסמכה?

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

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

ולסיום

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

 

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

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

 

More
5206

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

ניוזלטר

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

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

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

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

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

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

ניוזלטר

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

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

Copyright © 2014 Leadera. All Rights Reserved.

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