קוד של הרמוניה – גישור בפרוייקטים טכנולוגיים

מי מפחד מטכנולוגיה ?

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

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

הייטק - זירה של חדשנות ויצירה

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

הייטק זה לא רק סטארטאפים

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

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

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

על פי דוח[3] שפורסם על ידי חברת המחקר STKI (חברה המתמחה בשוק הטכנולוגיה וה IT הישראלי מזה עשרות שנים) וקרת ומנתחת את שוק טכנולוגיית המידע בישראל מזה מספר עשורים, שוק מערכות המידע הארגוניות בישראל נאמד בכ 9.4 מילארד דולר בשנת 2023 וצפוי לצמוח בכ 10% בממוצע בשנים הקרובות. כ 50% מתקציבים אלו, כ 4.8 מילארד דולר מושקעים בפרוייקטי פיתוח, יישום ואינטגרציה של מערכות מיחשוב לארגונים ועסקים.

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

מערכות יחסים ארוכות שנים

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

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

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

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

האתגר – זירה עתירת שחקנים ומורכבויות

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

בשנת 2017 פרסם ארגון PMI (Project Management Institute) [4] סקר עולמי לבחינת אחוזי הצלחה של פרוייקטים טכנולוגיים והגורמים המרכזיים לכשלונם. מהסקר עולים ממצאים מרתקים: כ 14% מבוטלים ללא כל תוצאה משמעותית, 31% אינם עומדים ביעדים שהובטחו , 43% חורגים מהתקציב ו-49% חורגים מלוח הזמנים המוסכם. רק 15% מהפרויקטים עומדים בלוז בתכולה ובתקציב. בסקר נוסף [5] שבוצע ב 2023 עלו ממצאים נוספים המצביעים על כך שככל שהצוותים מקצועיים יותר ורמת הסינרגיה והניהול גבוהה יותר אחוזי ההצלחה גדלים.

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

מדוע זה כלכך מורכב ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כסף אינו סיבה למשבר הוא אמצעי או אינדיקטור.

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

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

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

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

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

1.      Scoping & Quantified Conflict/Escalation – משבר מבוסס תכולה

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

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

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

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

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

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

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

2.      משבר מבוסס איכות – Quality Escalation/Conflict

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

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

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

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

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

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

3.      משבר מבוסס מחוייבות וזמינות – Commitment Based Conflict

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

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

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

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

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

לסיכום

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

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

והכי חשוב אסור לשכוח, טכנולוגיה והייטק – זה בסופו של דבר אנשים.

בהצלחה

From CGPT

write 200 words paragraph explaining how scoping or requierments phase is neccesary to prevent future project conflicts and how wush a conflict can emarge due to lack of scoping or clear requierments document

The scoping or requirements phase of a project is an essential and foundational step in the project management process, primarily designed to prevent future conflicts and ensure project success. This phase involves defining the project's objectives, deliverables, constraints, and stakeholders' expectations in a clear and comprehensive manner.

Without a well-defined scope or requirements document, projects are vulnerable to a host of potential conflicts and challenges. One of the most prominent issues that can emerge is scope creep, where additional tasks or features are introduced into the project without proper evaluation or approval. This can lead to stretched timelines, increased costs, and frustrated team members, ultimately jeopardizing the project's success.

Moreover, unclear requirements can result in misunderstandings among team members and stakeholders, leading to conflicting expectations and communication breakdowns. When project participants have different interpretations of what needs to be accomplished, it can cause delays, errors, and frustration, further hindering progress and collaboration.

Inadequate scoping or requirements documentation can also make it difficult to identify and address potential risks early in the project, increasing the likelihood of unexpected issues arising later on. This lack of clarity can create confusion, reduce accountability, and make it challenging to make informed decisions to steer the project in the right direction.

In summary, a well-executed scoping or requirements phase is indispensable for preventing conflicts, mitigating risks, and ensuring that all project stakeholders are on the same page. It provides the foundation upon which a successful project can be built, saving time, resources, and headaches down the road.

Write 200 words paragraph explaining why quality issues definition is neccesary for Information technoilogy or development project success. Explain how failing to define quality measurments might lead to conflicts and escalations. suggest how can we prevent and identify such quality issues earlier before they bedome a huge escalation or crisys

Defining quality measures is indispensable for the success of information technology and development projects. In the realm of IT, quality isn't just a desirable attribute; it's a fundamental requirement that directly impacts project outcomes and stakeholder satisfaction. Without a clear definition of quality, projects are vulnerable to a host of issues that can lead to conflicts and escalations.

Firstly, a lack of quality definition can result in ambiguous expectations. Stakeholders, including clients and project teams, may have differing interpretations of what constitutes a quality deliverable. This misalignment can lead to frustration, disputes, and delays as everyone involved tries to reconcile their expectations.

Secondly, it hampers accountability. When quality criteria are not clearly defined, it becomes difficult to attribute responsibility for any shortcomings. This lack of accountability can foster a culture of blame and finger-pointing when issues arise.

To prevent and identify quality issues early on, organizations must establish robust quality assurance processes. This includes creating well-defined quality metrics and objectives, conducting regular reviews and inspections, and implementing automated testing where applicable. Early detection mechanisms, such as code reviews and continuous integration, can help catch issues before they escalate into crises. Additionally, fostering open communication channels among project stakeholders and promoting a culture of quality can further mitigate conflicts and ensure successful project outcomes. In essence, a proactive approach to quality management is key to project success in the ever-evolving landscape of information technology and development.

Write 200 words paragraph explaining how lack of management commitment or just commitment of each party involved in IT or IS or development project might and may lead to significant escalation. Explain how can we recognize the fact there is no commitment from one of the parties, share some typical behaviors for such miss-commitment. Suggest how we can re-ensure and rebuilt the commitment to make sure the project will succeed and will not fail or lead to escalation and conflicts. Highlight the most important parts in RED font color

Lack of commitment, particularly from key stakeholders in an IT, IS, or development project, is a recipe for significant escalation and potential failure. When one or more parties involved in a project do not demonstrate commitment, it can manifest in various detrimental ways. Typical behaviors indicative of this lack of commitment include inconsistent involvement, frequent absenteeism from project meetings, a reluctance to allocate necessary resources, or a passive-aggressive approach to decision-making. Moreover, team members may exhibit disinterest or skepticism about the project's objectives, and deadlines may be missed with no proactive effort to rectify the situation.

Recognizing these signs of commitment issues is crucial for timely intervention. Project managers should closely monitor participation levels, assess the allocation of resources, and openly communicate with stakeholders to gauge their level of enthusiasm and engagement. Regular feedback sessions can reveal underlying concerns or reservations.

To rebuild commitment and ensure project success, a proactive approach is essential. Project leaders should engage in one-on-one discussions to address concerns and align stakeholders with the project's goals. It's essential to communicate the project's significance and benefits, emphasizing the value it brings to each party involved. Additionally, establishing clear roles and responsibilities, setting achievable milestones, and fostering a collaborative, supportive environment can reinvigorate commitment.

In summary, commitment from all parties is the lifeblood of project success. Recognizing and addressing commitment issues early on, through effective communication and a supportive project environment, can prevent escalations, conflicts, and the potential downfall of IT, IS, or development projects.

[1] סידביז - סקירת תעשיית ההון סיכון, הסטארטאפ והחדשנות בישראל – דו"ח H1 / 2023

[2] רשות החדשנות – דוח החדשנות השנתי 2023. 

[3] STKI – The Israeli IT Experience 2023

[4] PMI – Transforming the high cost of low performance 2017

[5] PMI – Pulse of profession 2023