לבעלי וותק, אפילו קצר, בעולמות מערכות המידע האפליקטיביות, יצא לחוות לפחות פרויקט אחד, שהתארך מעבר לצפוי באופן חריג מאד(!), שהתקציב חרג, מאד(!), והתוצר... איך לומר זאת בעדינות?...לא עונה על הציפיות.
ככל שפרויקט גדול יותר או ככל שהארגון דינמי יותר - הסיכוי לדימום גדל.
זה לא אומר שאין פרויקטים מוצלחים, אבל סביר להניח, שבפרויקטים מוצלחים, אחרי שנגלח את השיווק המוצלח שלהם, ונוודא שאכן עמדו בזמן, בתקציב ובציפיות...נגלה שהם היו בנפח קטן יחסית.
בפוסט זה ננסה להבין גורמים לדימום ולהציע רעיונות לצימצומו.
נגדיר - דימום:
הוצאה הכספית זורמת (מדממת), באופן קבוע, בשעה שהתמורה אינה תואמת את הציפיות (בטווח שבין: אין תמורה כלל, לבין התמורה אינה עומדת בלוח הזמנים והתוצר אינו עומד בציפיות). הדילמה אם לעצור את הדימום לרוב שקולה לדילמה האם "להוריד את התינוק עם המים"...
ההוצאה על המשאבים
בטרם התחלת פרויקט יש לקיים תהליך המסתיים באישור תקציבי. בהינתן אישור תקציבי, אפשר לגייס ספקים או כ"א פנימי או שילוב. בנוסף למשאבי כוח האדם יש לשלם רישוי ולעיתים יש לשלם מראש גם על תשתיות.
בכדי להבטיח את זמינות המשאבים, הארגון צריך להתחיל להזרים כספים (כ"א, רישוי ותשתיות). במהלך כל פרויקט, מה שקבוע ובטוח היא ההוצאה. אחרת אי אפשר להבטיח את המשאבים. אולם מה שמשתנה הוא התפוקה.
לפני שניכנס לסיבות, מסתבר שהתפוקה אינה ביחס ישר להוצאה, אלא היא סובלת מגלים וניצולת נמוכה. על כן, באופן כמעט ודאי התפוקה לא מתאימה לתוכנית.
המשמעות: ככל שהפרויקט ארןך יותר, כך גוברת חוסר ההתאמה בין ההוצאה לתמורה.
בתרשים אפשר לראות את ההוצאה הקבועה (לשם המחשה: נגדיר גם שהתפוקה הצפויה שקולה להוצאה). לעומתה אפשר לראות את התפוקה הפוחתת בציר הזמן.
ניצול המשאבים
מדוע התפוקה בפרויקטים נוטה לרדת ולהתרחק מעמידה ביעדים המתוכננים?
ישנם מספר רב של משתנים המשפיעים על התפוקה. להלן העיקרים:
1. תשומות ישירות שכל ייעודם הוא הפרויקט כמו כוח אדם:
זמינות האנשים: תזמון הגיוס, עובדים שמתחלפים, היעדרויות, הכשרות.
הידע הרלוונטי. לא כולם שווים. לא בידע הראשוני, לא ביכולת וקצב הלימוד ולא ביכולת המימוש.
מוטיבציה, עבודת צוות, ניהול מוכוון מטרבפרוייקטים ה.
2. מיקוד ארגוני הוא משאב יקר מאין כמוהו ומאד דינמי. בארגון ישנם בעלי תפקידים אשר מהווים משאבים הכרחיים להתקדמות הפרויקט, אך אינם מוקצים לו, כגון שכבת מקבלי ההחלטות או מקצוענים שיש להם תרומה הכרחית. יש נטייה להניח שאם פרויקט הוא חשוב, כל בעלי התפקידים הרלוונטיים בארגון יתפנו לפי קריאה ויהיו זמינים לצוות הפרויקט כלומר יתמקדו בפרויקט. המציאות שונה באחוז גבוה של המקרים. מאחר וכל פרויקט הוא משימה שמעבר לשוטף הארגוני, לא נכון לחשוב שבעלי התפקידים בארגון יכולים לוותר על השוטף. יתרה מזו, בארגון חי ובועט, סביר להניח שיש יותר מפרויקט אחד בו זמנית. ופרויקטים שמגדילים את ההכנסה, או פרויקטים שמשמרים את ההכנסה, תמיד יועדפו על פני פרויקטים ארוכי טווח שבטווח הקצר עיקרם הוצאה...על כן הפרויקט שלנו יהיה במוקד תשומת הלב של אותם משאבים לפרקי זמן קצרים שתדירותם תרד ככל הציר הזמן יתקדם.
3. ציר הזמן. ככל שיתארך יתווספו משתנים המשפעים על אורך ומורכבות כל פרויקט. לדוגמה:
מצד אחד, הארגון מגיב לשוק, לצרכי לקוחותיו ולתחרות. וכשם שאלה משתנים, גם הארגון חייב להתאים את עצמו. לכן הוא מוציא מוצרים חדשים, משנה תמחור, מנהל אחרת את המלאים, מרים קמפיינים חדשים מייצר שיתופי פעולה וכיוצ'. מאידך הפרויקט עובד לפי המתוכנן ברגע תחילתו. לכן כל שינוי שקורה מחייב תכנון מחדש. ובמצבים מסוימים אפילו את מה שכבר נעשה תחת פרויקט יש לשנות.
כוח האדם. ככל שציר הזמן מתארך הפרויקט חשוף יותר לתחלופת משאבים (סעיף 1). כל תחלופה כואבת מאחר שיש להשלים פער ידע הגדל עם הזמן.
הטכנולוגיה. אף רכיב תוכנה לא נשאר מקובע. כולם חייבים להתעדכן. כל עדכון מחייב השקעת זמן, מחייב השלמת פערי ידע ולעיתים גם מביא אתו בעיות שיש להשקיע זמן בלפתור אותן. ככל שציר הזמן מתארך, הפרויקט נחשף ליותר רכיבים שמשתנים.
רישוי והתשתיות, בחלקן משלמים רק כאשר שלב ביצוע הפרויקט מסתיים והתוצרים מתחילים לעבוד בפועל. בתלות בהסכמי הרכש. אולם, תמיד יש חלק שאותו משלמים מהתחלה, שהרי יש לפחות להרים סביבות פיתוח ובדיקות ולשלם רישוי מינימלי. ככל שפרויקט מתארך, תשלומי הסרק יגדלו.
פרדוקס החוב הטכני: כאשר ותוך כדי החלפת המערכת הישנה בחדשה, נוצר צורך עסקי מידי, המערכת החדשה אינה מוכנה עדיין, באיזו מערכת יבוצע השינוי? נכון – בישנה. ומה זה אומר? שהארגון קיבל החלטה שבמקרה הטוב מכפילה את היקף העבודה (מאחר שהשינוי צריך להיות מבוצע גם במערכת הישנה וגם בחדשה) ובכך דחינו במודע(!), את זמן החלפת המערכות. מתי המעגל הזה יסתיים?
ככל שפרויקט יסתיים מהר ייחשף פחות לפגעי הזמן...
המסקנה המתבקשת מהבנת המשתנים היא ש: ציר הזמן הוא האויב !
צד הפתרון
אם הבנו, לפחות חלק, מהסיבות ל"דימום" נציע מספר גישות לצימצומו:
מתמחים בריצה למרחקים קצרים
כפועל יוצא מתובנת "הזמן הוא האויב של פרויקט מוצלח" יש להגיב על ידי פירוק כל פרויקט גדול למרכיבים. לא, אין כאן רמיזה למתודולוגית ה Agile או Lean, אלא פירוק פרויקט למרכיבים "הכי קטנים שיכולים להיות עצמאיים" וכל מרכיב כזה יהיה פרויקט בפני עצמו. זאת על מנת להתמקד בתוצרים בעלי טווח פעולה המנטרל את הבעיות שהוצגו לעיל.
שינויי הטכנולוגיה
לתכנון ארוך טווח, יש קונפליקט עם השוק. מנהלים שהבינו את זה, בונים ארגונים דינמיים שיודעים לנצח את התחרות בריצה למרחקים קצרים. אבל עולמות הטכנולוגיה הארגוניים, יודעים לרוץ באותו קצב?
בעולם הטכנולוגי, מסתבר, יש המון רכיבים, להחליף את כולם כל הזמן, לא כלכלי, לא יעיל ולמעשה בלתי אפשרי. על כן הוטמע והושרש המונח "ההחזר על ההשקעה" אשר ממקד את הארגון במאמץ להגדיל את הניצולת של כל השקעה טכנולוגית.
האם יש קונפליקט בין ההיגיון של ה ROI (מקסום ההחזר על ההשקעה) לבין השוק בו בד"כ פועלות החברות? – לחלוטין !
כיצד נהוג ליישב את הקונפליקט? העולם הטכנולוגי בנוי מרבדים (למשל רכיבים תשתיתיים כגון: חומרה, תקשורת, אבטחה, מערכות הפעלה, בסיסי נתונים, פלטפורמות פיתוח, סלי תוכנות ורכיבים אפליקטיביים כגון: מערכת מכירות, ניהול מלאי או סל שירותים ללקוח). גישת ה ROI בד"כ גוברת ברכיבי התשתית, כאשר תגובה מהירה לשוק בד"כ תשפיע על הרכיבים האפליקטיביים (הרבדים העליונים). כלומר ארגון המגיב במהירות לתנאי שוק משתנים, ינסה להתמקד בשינוים של התהליכים העסקיים בקצב הנדרש ולהפחית שינויים ברכיבי תשתית אשר השפעתם העסקית פחותה.
תובנה זו מובילה את הארגונים ליישום פלטפורמות לפיתוח מהיר (RAD/Low Code) כחלק אינטגרלי מכל פתרון, בדיוק מהסיבה הזו – לאפשר Time To Market מעולה לשינוי העסקי הבא.
לתאם ציפיות ולהקטין את הפתרון החדש
פרפקציוניזם הוא אחד הגורמים העיקריים לכך שמערכות חדשות לא עולות בזמן, נחשפות לפגעי הזמן ומייצרות פער הולך וגדל בין הרצוי למצוי.
יצא לכם לפגוש את המנהל שלא מוותר על שום פסיק שמקפיד על קטנה כגדולה ובטוח שהוא הוא מציל את הארגון...?
תיאום ציפיות וניהול סדרי עדיפויות נכונים הם מתפקידיו של המנכ"ל/מנהל אחראי, שאמור לדעת לכוון מערכת חדשה באופן שתיכנס לתפקוד עם המינימום פונקציונליות הנדרשת. זאת בכדי לאפשר לארגון לעבור מהר לפלטפורמה החדשה ולהשקיע את כל המשאבים רק בה מבלי לייצר חובות טכניים על גבי המערכת הישנה. כלומר הפחתת ציפיות ופונקציונאליות מהמערכת החדשה, תאפשר לה לתפוס את מקומה ואז הארגון יוכל להשקיע יותר משאבים בצמצום הפערים.
שותפות אמיתית בין הגוף המבצע לארגון
בפרויקט תוכנה, חשוב לוודא שהמוטיבציה (אופן התשלום) של הספקים השונים זהה לזו של הארגון. כלומר יש לקשור תשלום בהצלחה (לפי תפיסת הארגון).
תפיסה זו חייבת להיות מתורגמת להסכם המכריח ניטור מצב הפרויקט ומתאים משאבים באופן תואם את אפשרויות ההתקדמות.
מיקוד ארגוני
על הארגון, לוודא שצוואר הבקבוק של הפרויקט לא יעצור במשאבים הפנימיים שלו. אם זה קורה, משמע שהמשאבים הישירים שמוקצים לפרויקט לא יעילים ושוב חזרנו לציר הזמן...
לכן מראש יש להקצות משאבים פנימיים להתאמה לצורך וללו"ז.
יחד עם עם ההצעות כאן הפוסט על דגשים לפרויקט החלפת מערת מידע - יוסיף.
לסיכום - ההמלצה החשובה ביותר בניהול פרויקט תוכנה מורכב:
מאחר והזמן הוא הגורם המרכזי ל"דימום" בפרויקטים גדולים, חשוב לצמצם אותו בכל דרך אפשרית. החל בפירוק הפרויקט למספר פרויקטים קטנים, הפחתת הפונקציונאליות בכדי לאפשר החלפת מערכות, תיאום ציפיות, ובניית מערך טכנולוגי המאפשר ביצוע שינויים עסקיים – במהירות.