מדוע פרויקטי IT נכשלים?

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

מה זה, למעשה, הפרויקט "המאותגר", שעליו מדברים גופים מכובדים כמכוני מחקר ידועים ומומחים שונים? זה למעשה פרויקט שהסתיים, נמסר ללקוח ואפילו הוטמע והלקוח משתמש במערכת החדשה. אולם, לפרויקט יש בעיה אחת או יותר כגון: חרג מהתקציב, חרג בזמן, לא עמד בתכולת העבודה [SOW] (לא נמסר במלוא תכונות המערכת שהוגדרו לפרויקט), לא הסתיימה הדרכת ההטמעה, לא הוטמע במלואו במערכות הלקוח, והמקרה הגרוע ביותר – המערכת החדשה ננטשה והלקוח חזר לעבוד עם המערכת הישנה [Roll Back]. לעניות דעתי, אין אפשרות להכריז על פרויקט כהצלחה אבל הוא "מאותגר". אני פשוט אומר שהפרויקט נכשל.

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

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

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

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

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

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

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

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

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

מדוע זו אשמתו של מנהל הפרויקט? הרי הפרויקט נגמר, המערכת נמסרה ללקוח והוטמעה... תפקידו של מנהל הפרויקט לא תם עם מסירת המערכת ללקוח. הוא אחראי לוודא, שההדרכה וההטמעה תבוצענה במלואן ושעובדי הלקוח אכן עובדים על המערכת, שסופקה כמתוכנן. לכן, תפקידו כולל ניטור בזמן אמת של מערך הדרכת הלקוח וביצוע ההטמעה ואינטגרציה מול מערכות הלקוח הקיימות, זיהוי בעיות וכשלים, שעלולים למנוע הטמעה ואינטגרציה מוצלחות ואיתור בעיות הדרכה שתמנענה מעובדי הלקוח לעבוד במערכת החדשה. במידה וזוהו כשלים או בעיות, באחריות מנהל הפרויקט להביא לפתרונן המיטבי.
 
אביעד אהרוני, פברואר 2013
יועץ לפרויקטים טכנולוגיים, מתמחה בהצלת פרויקטים תקועים וכושלים.
tecman.ah@gmail.com