הפרויקט הסתיים בהצלחה. אז למה כולם מאוכזבים?
מי שמנהל פרויקטים מספיק שנים מכיר את הרגע הזה. חדר הישיבות מלא, מצגת הסיכום פתוחה, מנהל הפרויקט מציג בביטחון את תמונת המצב הסופית: לוחות הזמנים נשמרו, התקציב לא נפרץ, התכולה שסוכמה סופקה, הספקים עמדו בהתחייבויות, צוותי העבודה השלימו את המשימות, והמערכת עלתה לאוויר. מבחינת כל מדדי הביצוע המסורתיים, הפרויקט הצליח. לא כמעט הצליח. הצליח.
ועדיין, משהו בחדר לא לגמרי שלם.
כמה חודשים לאחר המסירה מתחילות להישאל שאלות אחרות. לא שאלות של ניהול פרויקט, אלא שאלות של ערך. האם המשתמשים באמת אימצו את המערכת החדשה? האם תהליך העבודה התקצר? האם החיסכון שהובטח בהצדקה עסקית (Business Case) התממש? האם ההכנסות גדלו? האם חוויית הלקוח השתפרה? האם הארגון נמצא במקום טוב יותר בזכות הפרויקט?
במקרים רבים התשובה אינה חד משמעית. לעיתים היא אפילו מאכזבת. הפרויקט עמד בכל מה שהובטח, אבל הארגון לא קיבל את מה שרצה. זו אינה סתירה. זו אחת התופעות החשובות ביותר בעולם ניהול הפרויקטים המודרני: הפער בין הצלחה טכנית לבין הצלחה עסקית.
במשך שנים לימדו אותנו שפרויקט מצליח הוא פרויקט שעומד בשלושת אילוצי הברזל: תכולה, לוחות זמנים ותקציב. המדדים הללו עדיין חשובים מאוד. הם מייצגים משמעת ניהולית, יכולת ביצוע, שליטה ובקרה. אבל הם כבר אינם מספיקים כדי להגדיר הצלחה. הם עונים על השאלה האם ביצענו את הפרויקט נכון. הם לא תמיד עונים על השאלה האם ביצענו את הפרויקט הנכון.
ודווקא בנקודה הזאת מתחיל הדיון האמיתי על המשמעות של הצלחת פרויקט.
כשהצלחת ניהול הפרויקט והצלחת הפרויקט כבר אינן אותו הדבר
אחת ההבחנות החשובות ביותר שהתפתחו בעולם ניהול הפרויקטים בעשורים האחרונים היא ההבחנה בין הצלחת ניהול הפרויקט (Project Management Success) לבין הצלחת הפרויקט (Project Success). בעבר, שני המושגים הללו התערבבו זה בזה. אם ניהלנו את הפרויקט היטב, הנחנו שהפרויקט הצליח. אם עמדנו בתכולה, בלוחות הזמנים ובתקציב, סימנו וי ועברנו הלאה.
אלא שהספרות המקצועית והמחקרית הראתה שוב ושוב שמדובר בשני מישורים שונים. הצלחת ניהול הפרויקט עוסקת ביעילות הביצוע: האם הצלחנו לנהל את התהליך, לשלוט באילוצים, לספק את התוצרים ולצמצם חריגות. הצלחת הפרויקט עצמו עוסקת בשאלה רחבה יותר: האם ההשקעה יצרה ערך ממשי לארגון, ללקוח ולבעלי העניין.
מחקרם של Aaron J. Shenhar, Dov Dvir, Ofer Levy ו-Alan C. Maltz, שפורסם בשנת 2001 תחת הכותרת Project Success: A Multidimensional Strategic Concept בכתב העת Long Range Planning, מציע מודל רב-ממדי להערכת הצלחת פרויקטים. המודל כולל ארבעה ממדים מרכזיים: יעילות פרויקטלית, השפעה על הלקוח, הצלחה עסקית-ארגונית והכנה לעתיד. לפי החוקרים, הצלחת פרויקט אינה נמדדת רק בעמידה בזמן, בתקציב ובביצועים, אלא גם בתרומתו לערך עסקי, ליתרון תחרותי ולהשגת מטרות אסטרטגיות ארוכות טווח.
גם David Baccarini, במאמרו The Logical Framework Method for Defining Project Success משנת 1999, הבחין בין הצלחת ניהול הפרויקט לבין הצלחת התוצר (Product Success). לטענתו, הערכת הצלחת פרויקט צריכה להתבסס על רמות המטרה הרחבות יותר של הפרויקט ולא רק על עמידה בתכולה, בלוחות הזמנים ובתקציב. מכאן שעמידה במשולש האילוצים עשויה להעיד על הצלחת הניהול, אך לא בהכרח על השגת מטרות הפרויקט או על יצירת הערך שלשמו הוא יצא לדרך.
ההתפתחות הזאת באה לידי ביטוי ברור גם במהדורות החדשות של ה-PMBOK. במהדורה השביעית נכתב כי פרויקטים אינם רק מייצרים תוצרים, אלא מאפשרים לאותם תוצרים להניע תוצאות שמייצרות ערך לארגון ולבעלי העניין:
“The Standard for Project Management and the PMBOK® Guide emphasize that projects do not simply produce outputs, but more importantly, enable those outputs to drive outcomes that ultimately deliver value to the organization and its stakeholders.”
(PMBOK® Guide – Seventh Edition, Preface, p. xi-xii)
במילים אחרות, ארגונים אינם משקיעים בפרויקטים כדי לקבל תוצרים. הם משקיעים בפרויקטים כדי לקבל תוצאות.
המשמעות פשוטה אך עמוקה. התוצר אינו נקודת הסיום. הוא רק חוליה בשרשרת. אם התוצר אינו מניע שינוי, ואם השינוי אינו יוצר תועלת, ואם התועלת אינה נתפסת כערך, הרי שהפרויקט לא השלים את ייעודו המקצועי, גם אם נסגר בצורה מסודרת.
המגמה הזאת אינה נעצרת במהדורה השביעית. גם PMBOK® Guide – Eighth Edition ממשיך את המעבר לגישה ממוקדת ערך, תוצאות ותרומה עסקית, ומרחיב את העיסוק בנושאים כגון מערכות אספקת ערך, חשיבה מערכתית, בינה מלאכותית ומשילות. בכך ממשיך המקצוע להתרחק מהתפיסה המסורתית שראתה הצלחה כעמידה בתכולה, בלוחות הזמנים ובתקציב בלבד, ומאמץ תפיסה רחבה יותר שבה הצלחת הפרויקט נבחנת גם על פי התרומה שהוא מייצר לארגון ולבעלי העניין.
שרשרת הערך: תפוקה, תוצאה, תועלת וערך
כדי להבין מדוע פרויקטים מצליחים טכנית ונכשלים עסקית, צריך לפרק את שרשרת הערך לארבעה מושגים: תפוקה (Output), תוצאה (Outcome), תועלת (Benefit) וערך (Value).
תפוקה היא מה שהפרויקט סיפק בפועל. זו יכולה להיות מערכתCRM חדשה, אתר מסחר, קו ייצור, אפליקציה, תהליך עבודה חדש או מרכז שירות משודרג. זהו המקום שבו רוב מנהלי הפרויקטים מרגישים נוח. אפשר למדוד אותו, לבדוק אותו, לאשר אותו ולסגור אותו.
תוצאה היא השינוי שנוצר בעקבות השימוש בתוצר. למשל, אנשי המכירות עובדים בצורה עקבית יותר מול לקוחות, זמן הטיפול בפנייה מתקצר, מספר השגיאות יורד, או תהליך הייצור הופך מהיר ויציב יותר. כאן כבר לא מספיק לשאול האם המערכת קיימת. צריך לשאול האם אנשים משתמשים בה, האם התהליך השתנה, והאם דפוסי העבודה בארגון אכן השתנו.
תועלת היא ההשפעה העסקית המדידה שנוצרת בעקבות אותו שינוי. חיסכון בעלויות, גידול בהכנסות, שיפור שביעות רצון לקוחות, קיצור זמני אספקה, שיפור תפוקה או הפחתת סיכונים. תועלת כבר דורשת שפה עסקית ולא רק שפה פרויקטלית.
ערך הוא השיפוט הכולל של בעלי העניין: האם התועלות שהושגו היו שוות את ההשקעה, המאמץ, הזמן והסיכון. זה המקום שבו הפרויקט פוגש את המציאות העסקית. לא את התוכנית. לא את הגאנט. לא את מסמך הסגירה. את המציאות.
ניקח דוגמה פשוטה. ארגון משיק אתר מסחר חדש. התפוקה היא אתר חדש, מאובטח, מהיר ומותאם לנייד. התוצאה היא שלקוחות מבצעים רכישות באופן נוח יותר. התועלת היא גידול במכירות המקוונות, ירידה בעומס על מוקדי השירות ושיפור שיעור ההמרה. הערך הוא התרומה הכוללת של המהלך לצמיחה, לרווחיות ולמיצוב התחרותי של הארגון.
הבעיה מתחילה כאשר הארגון עוצר בשלב הראשון. האתר עלה. הפרויקט נסגר. כולם עברו ליוזמה הבאה. אבל אם הלקוחות לא קונים יותר, אם שיעור ההמרה לא השתפר, ואם עלות התפעול לא ירדה, אז הפרויקט סיפק תוצר אך לא יצר ערך.
זה ההבדל בין לסיים פרויקט לבין להשיג מטרה.
איפה הערך מתחיל להיעלם?
אחד המיתוסים הגדולים בעולם ניהול הפרויקטים הוא שהערך העסקי נבחן רק בסוף. בפועל, הוא מתחיל להיבנות או להישחק מהרגע שבו מתקבלת ההחלטה לצאת לדרך.
אחת התובנות החשובות ממחקרי עומק על מימוש תועלות היא שחלק משמעותי מאובדן הערך מתרחש עוד לפני שהפרויקט באמת מתחיל. כאשר ההצדקה העסקית נבנית על הנחות אופטימיות מדי, כאשר היעדים אינם ברורים, כאשר לא קיימת הבנה מספקת של השוק, או כאשר אין קשר הדוק בין הפרויקט לבין האסטרטגיה, הפרויקט יוצא לדרך כשהוא כבר פצוע מבחינה עסקית.
בהמשך, הערך נשחק בשלב התכנון. פשרות ארכיטקטוניות, קיצוץ באימוץ משתמשים, ויתור על הכשרות, צמצום פעילויות ניהול שינוי, או דחייה של יכולות קריטיות לגרסה עתידית עלולים להפוך פרויקט שנראה מבטיח לפרויקט שמספק פחות ופחות מהתועלת המקורית שהובטחה.
בשלב הביצוע, הארגון מתחיל להתאהב במדדי התקדמות. כמה אחוזים הושלמו. כמה משימות נסגרו. האם מדד ביצוע לוח הזמנים (SPI) תקין. האם מדד ביצוע העלות (CPI) נראה טוב. אבל המדדים הללו אינם תמיד אומרים אם הערך נשמר. הם אומרים אם העבודה מתקדמת. לא בהכרח אם היא עדיין העבודה הנכונה.
ולבסוף, לאחר ה-Go-Live, מתחיל השלב שבו ערך אמור להתממש בפועל. זהו דווקא השלב שבו פרויקטים רבים כבר אינם מנוהלים. מנהל הפרויקט עבר לפרויקט הבא. הצוות התפזר. ועדת ההיגוי נסגרה. נותן החסות חזר לעיסוקיו. ואם לא הוגדר בעל אחריות למימוש התועלות (Benefit Owner) ברור, אין גורם שממשיך לבדוק האם ההבטחות העסקיות הפכו לתוצאות.
התופעה הזאת מוכרת היטב גם בספרות המקצועית. במאמרם Benefits Management: How Siemens Focuses on Benefits to Accelerate Value Delivery מציינים Joseph Sopko ו-Andrea Demaria כי כאשר ארגונים אינם מנהלים באופן שיטתי את מימוש התועלות, נוצרת תופעה המכונה "Benefits Leakage" (דליפת תועלות), שקשה לעיתים אף לכמת במדויק.
במקרים רבים, זהו הפער שבין מסירת התוצר לבין מימוש התועלת. הפער שבו פרויקט מסתיים בהצלחה טכנית, אך הערך שלשמו יצא לדרך מתממש באופן חלקי, אם בכלל.
מקרה בוחן: מוטורולה אירידיום, ניצחון הנדסי וכישלון עסקי
פרויקט אירידיום של מוטורולה נחשב עד היום לאחת הדוגמאות המפורסמות ביותר לפער שבין הישג הנדסי מרשים לבין כישלון עסקי.
בסוף שנות השמונים ובתחילת שנות התשעים הציגה מוטורולה חזון שאפתני: רשת תקשורת לוויינית שתאפשר לכל אדם לדבר מכל מקום בעולם. כדי לממש את החזון הזה נבנתה קונסטלציה של 66 לוויינים במסלול נמוך סביב כדור הארץ. מבחינה הנדסית מדובר היה בהישג יוצא דופן. המערכת דרשה פתרונות מתקדמים בתחומי תקשורת, לוויינות, תיאום גלובלי, תשתיות קרקעיות, מכשירי קצה ושיגור לחלל.
הפרויקט סיפק תפוקה מרשימה בקנה מידה יוצא דופן. הלוויינים שוגרו. הרשת פעלה. הטכנולוגיה הוכיחה יכולת. המערכת נחשבה לאחת מיצירות ההנדסה המורכבות של תקופתה.
אבל השוק לא חיכה.
במהלך השנים הארוכות שבהן אירידיום פותחה, רשתות הסלולר הקרקעיות התקדמו בקצב מהיר בהרבה מהצפוי. הן הפכו זמינות יותר, זולות יותר ונוחות יותר. במקביל, המכשיר של אירידיום היה יקר, כבד, מוגבל בשימוש בתוך מבנים ובמרכזי ערים, ועלות השיחה הייתה גבוהה מאוד. במילים פשוטות: הטכנולוגיה עבדה, אבל הצעת הערך כבר לא התאימה למציאות.
הפרויקט הצליח לספק מערכת מתקדמת. הוא לא הצליח לייצר אימוץ שוק משמעותי. החברה כיוונה למאות אלפי מנויים, אך בשיא פעילותה הצליחה לגייס כ-55,000 משתמשים בלבד. בשנת 1999, זמן קצר לאחר ההשקה המסחרית, אירידיום הגישה בקשה להגנה מפני נושים.
מה נכשל שם? לא הטכנולוגיה. לא הביצוע. הכשל היה בחיבור בין פתרון, שוק, לקוח, תמחור, שימושיות ותזמון.
זהו בדיוק הפער שבין הצלחת ניהול הפרויקט לבין הצלחת הפרויקט עצמו. המערכת עבדה בדיוק כפי שתוכננה, אך הערך העסקי שלשמו הוקמה לא התממש בקנה המידה שנדרש.
אירידיום היא תזכורת מקצועית חשובה: לא מספיק לבנות דבר מופלא. צריך לבנות דבר שמישהו צריך, בזמן שהוא צריך אותו, במחיר שהוא מוכן לשלם, ובאופן שהוא מסוגל להשתמש בו.
חמש הסיבות המרכזיות לכישלון עסקי של פרויקטים מצליחים
מקרה אירידיום אינו חריג כפי שנדמה. אמנם מדובר באחד הכישלונות העסקיים המפורסמים ביותר בעולם הפרויקטים, אך אותם דפוסים חוזרים על עצמם גם בפרויקטים קטנים ופשוטים בהרבה. כאשר בוחנים לעומק פרויקטים שהצליחו מבחינה טכנית אך לא הצליחו לייצר ערך, ניתן לזהות מספר גורמים שחוזרים שוב ושוב.
הסיבה הראשונה היא חוסר יישור אסטרטגי. פרויקטים רבים מתחילים משום שמישהו ביקש, משום שנמצא תקציב, משום שמתחרה עשה משהו דומה, או משום שהטכנולוגיה נראית מבטיחה. אבל פרויקט שאינומחובר ליעד אסטרטגי ברור עלול לספק תוצר איכותי שאינו משנה דבר משמעותי בארגון. כאן מנהל הפרויקט צריך לשאול כבר בשלב הייזום: איזה יעד עסקי הפרויקט משרת? איזה מדד אסטרטגי הוא אמור להזיז? ומה יקרה אם לא נבצע אותו?
הסיבה השנייה היא הצדקה עסקית שנשכחה בדרך. בארגונים רבים הצידוק העסקי נכתב היטב בשלב הייזום, אך לאחר אישור התקציב הוא הופך למסמך ארכיוני. בפועל, ההצדקה העסקית צריכה להיות כלי ניהול חי. היא צריכה להיבחן לאורך הדרך, במיוחד כאשר תנאי השוק משתנים, כאשר התכולה משתנה, כאשר העלויות עולות או כאשר התועלות המקוריות כבר אינן סבירות. פרויקט שממשיך מכוח האינרציה רק משום שכבר הושקע בו כסף עלול ליפול למלכודת העלות השקועה. זוהי אחת הסיבות לכך שארגונים ממשיכים לעיתים להשקיע בפרויקטים שכבר אינם משרתים את ההצדקה העסקית המקורית שלהם.
הסיבה השלישית היא אימוץ משתמשים נמוך. מערכת שאנשים אינם משתמשים בה אינה מייצרת ערך. תהליך שאנשים עוקפים אינו משנה ביצועים. כלי עבודה שאינו משתלב בהרגלים, בתמריצים ובשגרות הארגוניות נשאר על הנייר. כאן נכנס לתמונה ניהול שינוי. לא כפעילות הדרכה בסוף הפרויקט, אלא כחלק אינטגרלי מהתכנון, מהתקשורת, מהמעורבות ומההטמעה. שינוי עסקי אינו קורה כאשר מערכת עולה לאוויר. הוא קורה כאשר אנשים משנים דרך עבודה.
הסיבה הרביעית היא מדידה של הדברים הלא נכונים. ארגונים אוהבים מדדים משום שהם מעניקים תחושת שליטה. אבל לא כל מדד הוא מדד טוב. מספר משימות שהושלמו, אחוז התקדמות, מספר פיצ'רים שפותחו או צבע ירוק ב-Dashboard יכולים ליצור תחושת הצלחה גם כאשר הערך העסקי אינו מתקדם. לעיתים נוצרת אפילו תופעת Watermelon Status: הכול נראה ירוק כלפי חוץ, בעוד שהערך העסקי בפועל נמצא בבעיה. אלו מדדים חשובים לניהול ביצוע, אך הם אינם מחליפים מדדי ערך כמו אימוץ, חיסכון, תפוקה, הכנסות, שביעות רצון או קיצור זמני מחזור.
הסיבה החמישית היא היעדר בעלות ברורה על התוצאות העסקיות. מנהל הפרויקט אחראי בדרך כלל למסירה. נותן החסות אחראי לכיוון העסקי. המוביל העסקי אחראי לשימוש ולתועלת. מנהל המוצר אחראי למקסום הערך של הפתרון. ה-PMO אמור לאפשר בקרה ושקיפות. אבל אם אף אחד אינו מוגדר כבעלים של התועלות לאחר המסירה, הערך נופל בין הכיסאות. בפרויקטים רבים יש אחריות ברורה למסירה, אך אחריות עמומה למימוש התועלות. וכאשר כולם אחראים לערך, לעיתים קרובות אף אחד אינו אחראי לו באמת.
הגורם האנושי שאף Dashboard לא רואה
אחד הכשלים העמוקים ביותר בפרויקטים מצליחים טכנית הוא ההנחה שאנשים יאמצו שינוי רק משום שהוא הגיוני.
זו הנחה מסוכנת.
אנשים אינם משנים הרגלים משום שמערכת חדשה עלתה לאוויר. הם משנים הרגלים כאשר הם מבינים למה השינוי נחוץ, כאשר הם רוצים להיות חלק ממנו, כאשר הם יודעים כיצד לעבוד אחרת, כאשר יש להם יכולת אמיתית לבצע את העבודה החדשה, וכאשר הארגון מחזק את ההתנהגות החדשה לאורך זמן.
אחת המסגרות המוכרות ביותר להבנת אימוץ שינוי היא מודל ADKAR שפיתחה חברת Prosci. המודל מבוסס על ההבנה ששינוי ארגוני מתרחש דרך אנשים ולא דרך מערכות. לפי המודל, כדי שאדם יאמץ דרך עבודה חדשה עליו לעבור חמישה שלבים: מודעות לצורך בשינוי (Awareness), רצון להשתתף בו (Desire), ידע כיצד לפעול בדרך החדשה (Knowledge), יכולת ליישם אותה בפועל (Ability) וחיזוק מתמשך שמונע חזרה להרגלים הישנים (Reinforcement).
מחקרי Prosci לאורך השנים מצביעים באופן עקבי על כך שניהול שינוי אפקטיבי הוא אחד הגורמים המשפיעים ביותר על השגת יעדי הפרויקט ועל מימוש התועלות העסקיות שלו. במילים אחרות, גם פתרון טכנולוגי מצוין עלול להתקשות לייצר ערך אם האנשים שאמורים להשתמש בו אינם מאמצים אותו בפועל.
המודל מזכיר למנהלי פרויקטים דבר פשוט אך חשוב: שינוי ארגוני אינו אירוע טכני. הוא תהליך אנושי.
בפרויקטים רבים ההדרכה מגיעה מאוחר מדי. המשתמשים פוגשים את הפתרון רק בשלב הבדיקות. מנהלי הביניים אינם מגויסים. לא הוגדרו מדדי אימוץ. אין מנגנון לחיזוק ההתנהגות החדשה. ואז, ביום שאחרי ה-Go-Live, מתחילים לראות את הסימנים: קבצי אקסל חוזרים לשולחן העבודה, משתמשים מבקשים "רק לעקוף את המערכת הפעם", והארגון מגלה שהטכנולוגיה השתנתה אך ההתנהגות נשארה.
בנקודה הזאת הפרויקט כבר לא נבחן לפי השאלה האם המערכת עובדת. הוא נבחן לפי השאלה האם הארגון עובד אחרת בזכותה.
M.O.R.E: החשיבה החדשה של מנהל פרויקט מוכוון ערך
אם בעבר הצלחת פרויקט נמדדה בעיקר לפי עמידה בתכולה, בלוחות הזמנים ובתקציב, הרי שהמציאות העסקית של היום דורשת ממנהלי פרויקטים הרבה יותר. ארגונים אינם משקיעים בפרויקטים כדי לסיים משימות. הם משקיעים בהם כדי לייצר ערך.
PMIעושה שימוש במסגרת החשיבה M.O.R.E, המסייעת למנהלי פרויקטים להרחיב את נקודת המבט שלהם מעבר לניהול הביצוע ולהתמקד בהצלחת הפרויקט כולו.
האות M מייצגת Manage Perceptions - ניהול תפיסות.
מחקרי PMI מראים שגם כאשר פרויקט עומד ביעדיו הטכניים, הוא עלול להיתפס ככישלון אם בעלי העניין אינם חווים את התוצאות כבעלות ערך. לכן תפקידו של מנהל הפרויקט אינו מסתכם בדיווח על נתונים ומדדים. עליו להבין כיצד בעלי העניין מגדירים הצלחה, אילו תוצאות חשובות להם באמת, וכיצד הם תופסים את הערך שנוצר לאורך הדרך. הצלחה אינה נמדדת רק במספרים. היא נמדדת גם באופן שבו אנשים מפרשים את אותם מספרים.
האות O מייצגת Own Project Success - לקיחת אחריות על הצלחת הפרויקט.
אין הכוונה שמנהל הפרויקט אחראי לבדו על כל התוצאה העסקית. אך עליו לראות את עצמו כבעל עניין פעיל בהצלחת הפרויקט ולא רק בהשלמתו. במקום להסתפק בשאלה האם התוכנית מבוצעת כמתוכנן, עליו לשאול באופן קבוע האם הפרויקט עדיין משרת את המטרה שלשמה יצא לדרך, והאם הערך המצופה עדיין בר השגה. המעבר הזה הוא ההבדל בין ניהול משימות לבין מנהיגות פרויקטלית.
האות R מייצגת Relentlessly Reassess - בחינה מחודשת ומתמדת.
רבים רואים בבחינה מחדש של התוכנית סימן לכך שמשהו השתבש. בפועל, דווקא היכולת לעצור, לבחון מחדש ולהתאים את הכיוון היא סימן לניהול אחראי. תוכנית שנבנתה בתחילת הפרויקט אינה יכולה להישאר חסינה מפני מציאות משתנה. מנהלי פרויקטים מובילים בוחנים באופן שוטף הנחות יסוד, סיכונים, תועלות, סדרי עדיפויות וקריטריוני הצלחה. הם אינם "מתאהבים" בתוכנית המקורית. הם מתמקדים בערך שהפרויקט אמור לייצר.
האות E מייצגת Expand Perspective - הרחבת נקודת המבט.
פרויקטים אינם פועלים בוואקום. כל החלטה משפיעה על לקוחות, עובדים, ספקים, קהילות, תהליכים עסקיים ויעדים אסטרטגיים רחבים יותר. PMI מדגיש כי מנהלי פרויקטים צריכים לפתח חשיבה מערכתית ולהבין את ההשפעות הרחבות של הפרויקט מעבר לתוצרים המיידיים שלו. מנהל פרויקט שמרחיב את נקודת המבט שלו אינו שואל רק כיצד לספק את הפתרון, אלא גם כיצד הפתרון ישפיע על הארגון, על בעלי העניין ועל הערך ארוך הטווח שהוא מבקש ליצור.
תפיסת M.O.R.E אינה מחליפה את יסודות ניהול הפרויקטים. תכנון, בקרה, ניהול סיכונים וניהול תכולה יישארו תמיד אבני יסוד של המקצוע. היא מוסיפה שכבה נוספת של חשיבה עסקית ומנהיגותית, שמחברת בין ביצוע לבין ערך.
בסופו של דבר, מנהל פרויקט מצוין אינו נשאל רק האם עמד בלוחות הזמנים ובתקציב. הוא נשאל האם הפרויקט שינה משהו לטובה, והאם ההשקעה הייתה שווה את המאמץ.
כשהכול ירוק אבל המציאות אדומה
במאמר שפרסמנו בעבר עסקנו בתופעת Watermelon Status: ירוק מבחוץ, אדום מבפנים. בהקשר של מאמר זה, התופעה מקבלת משמעות רחבה יותר. היא אינה רק בעיית דיווח. היא סימפטום של ארגון שמודד פעילות במקום ערך.
זהו גם אחד הגורמים לכך שארגונים ממשיכים להאמין שהפרויקט מצליח, בזמן שהערך העסקי שלשמו יצא לדרך כבר נשחק. כאשר המדדים עוסקים במה שבוצע ולא במה שהושג, קל מאוד לפספס את הפער שבין תפוקה לבין תוצאה, ובין תוצאה לבין ערך.
הדוחות ירוקים כי המשימות מתקדמות. ה-Dashboard ירוק כי אבני הדרך נסגרות. מדדי הביצוע (KPI) ירוקים כי התקציב בשליטה. אבל הערך העסקי יכול להיות אדום לגמרי: המשתמשים אינם מאמצים את הפתרון, הלקוח אינו מרוצה, התועלות נשחקות, ההצדקה העסקית שעל בסיסה אושר הפרויקט כבר אינה תקפה.
כאן צריך להיזהר ממדדי נוחות. אלו מדדים שקל לאסוף, קל להציג וקשה להתווכח איתם. מספר משימות שהושלמו, אחוז התקדמות, ניצול תקציב או עמידה באבני דרך הם מדדים חשובים לניהול הביצוע. הבעיה מתחילה כאשר הם הופכים להיות המדדים היחידים שמעניינים את הארגון.
מדריך PMBOK® מהדורה שביעית מדגיש נקודה חשובה בהקשר זה:
“The value of measurements is not in the collection and dissemination of the data, but rather in the conversations about how to use the data to take appropriate action.”
(PMBOK® Guide – Seventh Edition, Section 2.7, p. 94)
כלומר, מדידה אינה נועדה לאסוף נתונים או לייצר מצגות מרשימות. מטרתה לסייע בקבלת החלטות. הערך האמיתי של המדדים אינו נמצא בגיליון הנתונים, אלא בשאלות שהם מעוררים ובפעולות שהם מניעים. מדדים אינם המטרה, אלא אמצעי להבנת המציאות. כאשר ארגון מפסיק לשאול מה הנתונים אומרים על הערך העסקי ומסתפק בשאלה האם המדדים נשארו ירוקים, הוא עלול לגלות את הבעיה רק חודשים לאחר שהפרויקט כבר נסגר.
זהו בדיוק הרגע שבו פרויקט יכול להיראות כהצלחה מלאה בדוחות הסגירה, ובו בזמן להיכשל במבחן החשוב ביותר: האם הוא יצר את הערך שלשמו הושקעו בו הזמן, הכסף והמאמץ.
איך מחברים בין הצלחה טכנית להצלחה עסקית
הדרך לחבר בין מסירה לערך מתחילה כבר בשלב הייזום. לא מספיק להגדיר תכולה. צריך להגדיר הצלחה. לא רק מה יימסר, אלא מה ישתנה בעקבות המסירה. כבר במסמך ייזום ובהצדקה עסקית צריך להופיע ניסוח ברור של תוצאות ותועלת, בעלי אחריות ומדדי הצלחה עסקיים.
הכלי הראשון הוא תוכנית מימוש תועלות (Benefits Realization Plan). זהו מסמך עבודה חי שמגדיר אילו תועלות אמורות להתממש, מי אחראי עליהן, מתי הן יימדדו, באילו מדדים, ומה יקרה אם התועלות אינן מתממשות. התוכנית הזאת אינה צריכה להיות מסובכת. היא צריכה להיות ברורה, מחייבת ומחוברת למשילות הפרויקט.
הכלי השני הוא סקירת ההצדקה העסקית (Business Case Review). במקום לאשר את הצידוק העסקי בתחילת הדרך ולשכוח ממנו, יש לבחון אותו בצמתים מרכזיים: שינוי תכולה, שינוי תקציב, שינוי שוק, שינוי רגולטורי או שינוי ארגוני. לפעמים ההחלטה המקצועית האמיצה ביותר היא לא להמשיך לבצע את התוכנית המקורית, אלא להודות שהערך השתנה.
הכלי השלישי הוא עץ מדדי ביצוע (KPI Tree). במקום להציג רשימת מדדים מנותקת, צריך לחבר בין יעד אסטרטגי למדדי תוצאה ולמדדי ביצוע. למשל: יעד אסטרטגי של שיפור רווחיות יכול להתחבר לתועלת של הפחתת עלויות תפעול, לתוצאה של קיצור זמן טיפול ולתפוקה בדמות מערכת אוטומציה חדשה. כך כל מדד בפרויקט מקבל משמעות עסקית.
הכלי הרביעי הוא דיווח מוכוון תוצאות (Outcome-Based Reporting). במקום לשאול רק "מה עשינו השבוע", יש לשאול "איזה ערך קידמנו השבוע". זה שינוי קטן בשפה, אבל גדול בתרבות. הוא מחייב את ועדות ההיגוי להסתכל מעבר לגאנט ולשאול שאלות על אימוץ, תועלות, מוכנות עסקית והמשך ההצדקה של הפרויקט.
הכלי החמישי הוא סקירה שלאחר הטמעה (Post-Implementation Review). הערכת הצלחה אמיתית אינה מסתיימת ב-Go-Live. היא צריכה להתרחש שלושה, שישה ושנים עשר חודשים לאחר המסירה. שם אפשר לבדוק האם התועלות התממשו, האם המשתמשים אימצו, האם התהליכים השתנו, ומה צריך לתקן כדי שההשקעה תתחיל להחזיר ערך.
תפקידו החדש של מנהל הפרויקט
האם מנהל הפרויקט אחראי לתוצאה העסקית? התשובה אינה כן מוחלט ואינה לא מוחלט. מנהל הפרויקט אינו שולט בכל הגורמים שמשפיעים על הערך. הוא לא קובע לבד את האסטרטגיה, לא מנהל את כל בעלי העניין העסקיים, ולא אחראי לבדו על התנהגות המשתמשים לאחר ההטמעה.
אבל הוא כן אחראי לוודא שהשיח על ערך אינו נעלם.
בעולם החדש מנהל הפרויקט צריך להיות אינטגרטור מוכוון ערך (Value-Aware Integrator). אדם שמחבר בין תכולה, לוחות זמנים, תקציב, סיכונים, משתמשים, נותן חסות, מוביל עסקי, מדדים ותועלות. הוא אינו מחליף את ההנהלה העסקית, אבל הוא חייב לוודא שהיא ממשיכה להיות מעורבת בהחלטות המשפיעות על הערך. הוא אינו בעל הבית היחיד של ההצדקה העסקית, אבל הוא צריך לוודא שהמסמך הזה לא הופך לקובץ שנשכח בתיקיית הייזום.
זהו שינוי מקצועי עמוק. מנהל פרויקט טוב כבר אינו רק מי שיודע להחזיק תוכנית עבודה. הוא מי שיודע לשאול שאלות עסקיות טובות בזמן הנכון. האם אנחנו עדיין פותרים את הבעיה הנכונה? האם המשתמשים מוכנים לשינוי? האם נותן החסות מעורב מספיק? האם המדדים שלנו מודדים פעילות או ערך? האם יש בעלים לתועלות לאחר הסגירה?
אלו לא שאלות צדדיות. אלו שאלות ליבה.
הצלחת הפרויקט אינה קו הסיום
העולם המקצועי עבר דרך ארוכה ממשולש הברזל ועד מערכת מתן ערך (Value Delivery System). הדרך הזאת לא ביטלה את חשיבותם של תכולה, לוחות זמנים ותקציב. להפך. היא ממקמת אותם במקום הנכון. הם תנאי הכרחי לניהול מקצועי, אבל הם אינם הגדרת ההצלחה המלאה.
פרויקט הוא מנגנון להעברת ארגון ממצב קיים למצב טוב יותר. לפעמים המצב הטוב יותר הוא חיסכון. לפעמים הוא צמיחה. לפעמים הוא עמידה ברגולציה. לפעמים הוא חוויית לקוח טובה יותר. לפעמים הוא יכולת עתידית שהארגון עדיין לא יודע למדוד במלואה. אבל תמיד יש סיבה עסקית שבגללה הפרויקט קיים.
זהו אולי השינוי המשמעותי ביותר שעבר על מקצוע ניהול הפרויקטים בעשורים האחרונים. המעבר מהתמקדות במסירה להתמקדות בערך, ומהשאלה "האם עמדנו בתוכנית?" לשאלה "האם השגנו את המטרה?".
הארגון לא משקיע מיליונים כדי לקבל עוד מערכת, עוד תהליך או עוד מסמך. הוא משקיע כדי להשיג תוצאה עסקית טובה יותר. לכן השאלה החשובה אינה רק האם סיימנו את הפרויקט, אלא האם הארגון השתנה לטובה בעקבותיו.
פרויקט מסתיים ביום המסירה.
הערך מתחיל להיבחן ביום שאחריו.
רוצים ללמוד עוד?
אם אתם שואפים לנהל פרויקטים בצורה מקצועית, לזהות סיכונים מראש ולבצע מענה מתאים למול הסיכונים, לעמוד ביעדים ולשלוט בלוחות זמנים – זה הזמן להצטרף לקורס ניהול הפרויקטים והכנה למבחן ה־PMP שלנו. - לקהל הנרשמים, או לקורס ניהול פרויקטים - PMO -לארגונים המזמינים אותו, הקורסים משלבים ידע עיוני עם כלים מעשיים, כולל סימולציות, תרגולים ומודלים ניהוליים מתקדמים. תלמדו כיצד ליישם את שיטת ה־Critical Path בפועל, איך להתמודד עם עיכובים ואיך להוביל צוות להצלחה. בין אם אתם בתחילת הדרך או כבר מנהלי פרויקטים מנוסים – הקורס ייתן לכם יתרון ברור בשטח.
* המאמר נכתב בלשון זכר מטעמי נוחות בלבד אך מיועד לנשים וגברים כאחד.
מאמר זה נכתב ע"י:
דן ברזילי MEng ,BSc ,PMP
מנכ"ל ומנהל פרויקטים.
וע"י:
הראל הייצין, Bsc, PMP
מנהל פרויקטים
