מאת: אבי עסיס*
|
אחד הנושאים המדוברים ביותר במסגרת ההכשרה למנהלי פרויקטים הוא לוח הזמנים.
הכלי הבסיסי שבידי כל מנהל באשר הוא ובפרט בתחום פיתוח מערכות מידע הינו תוכנית עבודה מבוססת על לוחות זמנים מדויקים. אין ישיבת סטאטוס או ישיבת הנהלה שנושא הלו"ז אינו עולה כמה וכמה פעמים והמנהל נוזף במשתתפים מדוע הם לא עומדים בלו"ז? אנו יודעים על סטטיסטיקות המראות בבירור כי אחוז הכישלון של פרויקטי מערכות מידע בכלל עומד על 65%, כאשר כישלון פירושו אי עמידה בלו"ז או חריגה בהקצאת המשאבים. מישהו מאיתנו מכיר פרויקט שעלה בדיוק בזמן כפי שמנהל הפרויקט התחייב עליו? אני לא!
כמובן שהזמן הוא אחד המשאבים החשובים במסגרת פרויקט וזמן שווה ערך לכסף – Time is Money. להשלכות העיכוב בלוחות הזמנים בפרויקט יש אספקטים שונים לגורמים שונים בארגון. אם ניקח למשל את הספק המבצע עבורנו את הפרויקט, ובמיוחד פרויקט בעלות קבועה – Fixed Price , הרי כל עיכוב במסירת התוצרים ללקוח פירושו תשלום משכורות לעובדיו, חוסר יכולת לשחרר את העובדים לטובת פרויקטים אחרים (אולי רווחים יותר). מאידך, ברור שבתמחור פרויקטים בשיטת ה- Time and Matiral תיתכן שאיפה של הספקים ל"מרוח" את הפרויקט ככל שניתן… אם ניקח את צד הלקוח – הרי כל עיכוב בלו"ז מעכב את העלייה לאוויר של הפרויקט – דבר שלעיתים יש לו השלכה עסקית או התחייבות מול לקוחות הארגון. לדוגמה אתר אינטרנט שלא עולה לאוויר בזמן בעוד המתחרים כן הצליחו במשימה, או מערכת Billing של חברת תקשורת שלא עולה בזמן וכתוצאה מכך ארגון התקשורת מתקשה לעקוב במדויק אחר חובות הלקוחות או מתקשה בגביה מדויקת מלקוחותיו – כמובן נזק אדיר לארגון. אין ספק שלוח הזמנים מהווה נר לרגליו של כל מתכנן או מנהל פרויקט שהרי בלעדי תוכנית המתבססת על לוחות זמנים לא נוכל להגיע לשום מטרה. אך למרות זאת ברצוני דווקא לתת מבט אחר שלעיתים הקפדה יתרה על לוחות הזמנים יכולה להיות דווקא בעוכרנו. לצורך הדוגמא ניקח ארגון שחיכה 2000 שנים כדי להיכנס לפרויקט ה – CRM (למשל). הארגון הקציב תקציב לנושא, מנהל הפרויקט הציג תוכנית מדהימה ואף הציג לוחות זמנים יומרניים (כמובן בהשראת הספקים) שתוך 6 חודשים יש להם פרויקט באוויר… (נתעלם מדוגמה קיצונית עוד יותר של הבטחות שתוך 90 ימים הפרויקט באוויר…). לצורך המטרה הנעלה נבחר ספק שהתחייב כמובן על לוחות הזמנים, ותוך ביצוע שלב האפיון בפרויקט התברר כי הארגון לא כל כך פשוט כפי שחשבנו תחילה. התהליכים מורכבים יותר, קיימות ועולות דרישות נוספות תוך כדי ביצוע האפיון המפורט, לארגון לא תמיד יש את ה"זמן" לשבת עם מאפייני המערכת (בעיקר בשל בעיות דחופות יותר שצצות ועולות בחיינו הסוערים) וראה איזה פלא … אפיון שהוקצבו לו 60 ימי עבודה תפח ועלה ל 6 חודשים (אתם זוכרים כי תוך 6 חודשים הפרויקט צריך להיות באוויר..?) והתכנון לעלות לאוויר 6 חודשים מיום חתימת החוזה נראה רחוק מתמיד. וכאן עולה הדילמה – האם נאיץ את שלב האפיון המפורט למען המטרה הנעלה של עמידה בלוחות הזמנים? אני מנחש כי רבים מהקוראים יאמרו ודאי שלא – הרי הארגון המתין כל – כך הרבה זמן להיכנס לפרויקט ה-CRM ועתה שאנו בעיצומו נוותר על איכותו? נוותר על אפיון כל ה"פינות" והדרישות של הארגון? וזוהי בדיוק הנקודה שרציתי להדגיש – הלו"ז אכן משמש עמוד עשן לארגון כולו להתייצב מאחורי היעד אך אין להקפיד יתר על המידה אחר יעד זה ולוותר על איכות הפרויקט או לוותר על פונקציונאליות חיונית.
לסיכום:
כל פרויקט ובודאי פרויקטי מערכות מידע חייבים להתבסס על תוכנית מוסכמת ועל לוחות זמנים הגיונים וסבירים, אך יש לזכור כי דווקא בטכנולוגיות חדשות ישנן הפתעות רבות והתכנון שתכננו לא בהכרח עומד במבחן המציאות. מסיבה זו על הארגון לעשות תוכנית סיכונים לפני כניסה לפרויקט ואף לקבוע לוחות זמנים אלטרנטיביים (מבלי לגרום לנזק עסקי). במידה ואין סיכון מיותר בדחיית הפרויקט אזי אפשר להיות גמישים עם הלו"ז ובלבד שנגיע לתוצאה הנכספת – לפרויקט שעובד נכון ומאפשר לארגון להתמודד בסביבה העסקית הדינאמית.
* אבי עסיס (M.Sc.) – הינו מנכ"ל חברת הייעוץ WideLink – תרונות עסקיים בע"מ. מומחים ליישום מערכות CRM ו-ERP. אבי עסיס מרצה בתחום טכנולוגיות מידע ו-CRM באוניברסיטת בן גוריון.
לתגובות, הערות והארות ניתן להפנות לכתובת: avi@widelink-crm.com
קישורים רלבנטיים:
|