ראיון עם צדוק עובדיה, CPO

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

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

Company overview: http://www.comverse.com/about_comverse/overview/

קומברס מחולקת לחטיבות, כאשר צדוק עובדיה הואChief Project Office (CPO)  בחטיבת Fun Dial. החטיבה מתפקדת כיחידה עיסקית וכוללת גופי פיתוח, ביזנס, שיווק, ניהול מוצר ועוד.

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

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

Orange FunTone, for example:

http://www.orange.co.il/funtone

קרדיט: http://www.freedigitalphotos.net/

הקמת גוף ניהול פרויקטים בחטיבת Fun Dial  של קומברס

ראיון זה התמקד בהקמת משרד ה- PMO בחטיבת Fun Dial ע"י צדוק עובדיה.

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

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

צדוק מונה לאחראי תחום פרוייקטים, Chief Project Officer (CPO), תפקיד שמטרתו לנהל את מנהלי הפרוייקטים והפרוייקטים השוטפים במקביל להקמת התשתית הפרויקטלית לחטיבתFun Dial.

בתור פעולה ראשונית, היה צורך להגדיר אחריות של בעלי התפקידים השונים באגף ה- Operations, ובתוך כך הוגדרו ה-R&R (Roles and Responsibilities) של מנהל הפרוייקט. כמו כן הוגדרו כל הפעיליות של מנהל הפרוייקט לכל אורך חיי הפרוייקט (Project Management Life-Cycle).

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

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

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

שלב 1- בניית סט כלים ותבניות שישמשו את מנהלי הפרויקטים בתפקידם.

בשלב ראשון היה הצורך ליצור תבניות (Templates).

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

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

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

במקביל לארגון התבניות היה צורך להתאים את המבנה הארגוני של משרד ה- PMO בגוף ה- operations  לצרכים. הוחלט על הקמת גוף delivery שירכז תחתיו  את משרד ה-PMO, את הפיתוח הפרוייקטלי ואת הבדיקות הפרוייקטליות. ארתור ויינשטיין מונה להוביל את כל גוף ה-delivery החדש.
תהליך השינוי היה ארוך ובמסגרתו חולקו הפרוייקטים ומנהלי הפרוייקטים לקבוצות וגוייסו מנהלי קבוצות (PMO – Project Manager Officer) שתחתיהם PMs (Project Managers)

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

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

שלב 3- בניית מתודולוגיה לניהול שוטף ובקרה, כולל כלים רלבנטיים.

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

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

כדי לתת מענה לצורך זה פותח כלי ב- ACCESS שנקרא:
Project Management Tool = PMT.

הכלי מכיל את כל הנתונים שמנהל פרויקט נדרש להם לצורך ניהול שוטף של הפרויקט, כגון:

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

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

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

השימוש בכלי עוגן בנוהל שעיקרו:
בתחילת השבוע מנהלי הפרויקטים מעדכנים את הנתונים בכלי, ביום שני ה-PMO סוקר את הנתונים, ביום שלישי ה-PMO סוקר את מצב הפרוייקטים עם מנהל ה-delivery וביום רביעי יש דיון הנהלה בהשתתפות ה-PMOs , מנהלי ה- Delivery ומנהלי קבוצות ב-R&D.

 שלב 4- תהליך Gating, קביעת תהליך אחיד וקבוע לכל הפרויקטים עם שערים.

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

לשם כך הוגדרו חמישה שערים:

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

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

ניהול מערכת שערים מעניק יתרונות רבים:

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

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

התהליך המתואר לעיל, הכולל את שלבים 1-4, ארך כשנתיים.

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

לשם כך הוגדרו ע"י ההנהלה היעדים אליהם היא שואפת ואותם היה צורך לכמת ולמדוד.
ההנהלה בחרה לשפר את לוחות הזמנים והריווחיות.
בהתאם לכך הוכרזו המדדים של (Profit and Loss (P&L ו-   Time To Market (TTM).
נבנתה מערכת לתקצוב פרויקטים ואיסוף נתוני עלות הפרויקטים. מערכת קיימת איפשרה להתחיל לאתר "זוללי עלויות" ולפעול להקטנתם.

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

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

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

עלו והצליחו!

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

נציץ לפרויקט בחברת שופינג.קום, סיפור הצלחה ישראלי.

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

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

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

מחלקת ניהול פרויקטים, PMO, הוקמה לפני כחצי שנה. לאגף הטכנולוגיות, הממוקם בארה"ב, הגיע מנהל חדש שרצה לקדם ולפתח את נושא ניהול הפרויקטים בחברה.
כיום מונה המחלקה 7 איש: Senior Director  בארה"ב ותחתיה 6 Senior PM , שניים מתוכם בארץ. (עדי אחת מהן, ג.י.ט.).

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

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

במה עוסקת המחלקה ועפ"י איזו מתודולוגיה?

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

נוהל העבודה שפותח נקרא:PDLC= Product Development Life Cycle    המבוססת על גישת ה AGILE לפרויקטי פיתוח תוכנה. הנוהל כולל תהליכים ו- Best Practices על פי מחזור החיים של פרויקט. הנוהל נבנה לכל יחידה עסקית כפי שהיא רגילה ובהתאם לצרכיה.

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

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

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

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

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

לפרויקט היה מנהל פרויקט ב- שופינג.קום ומנהל פרויקט ב- eBay.

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

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

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

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

בעוד הכלי הסטנדרטי משתמש במודולוגית RACI *, אנחנו הוספנו את האות ""S .

כך התקבל המקרא הבא, RASCI:

R= responsible

A= approver

S= support (team member)

C= consult

I= inform

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

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

השימוש במודל RASCI איפשר תקשורת שוטפת.

מה היו יעדי הפרויקט? האם הפרויקט הצליח? כיצד נמדדה הצלחה זו?

יעדי הפרויקט היו:

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

הפרויקט הצליח ועמד ביעדיו.

קרדיט: http://www.freedigitalphotos.net/

 ולסיום- האם הקמת מחלקת PMO תרמה ושיפרה את ניהול הפרויקטים בחברה?

אכן כן.

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

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

תודה עדי ובהצלחה בהמשך הדרך!

הערה :

* RACI – מטריצה מסוג RAM – Responsibility Assignment Matrix, או בשמה העברי – מטריצת הטלת אחריות. לפירוט ראה פרק HR ב-PMBOK.