צפי בעיות ופתרונן

ניהול סיכונים

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

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

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

אז אנסה לעזור למתחילים.

למה צריך את זה בכלל?

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

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

והכי חשוב- שיתוף הרבה אנשים יביא לסיעור מוחות, שיעלה אפשרויות, שאולי לא חשבנו עליהן.

איך עושים את זה?

קודם כל יש שלושה סוגים של סיכונים: פגיעה בלו"ז, פגיעה בתקציב או פגיעה בתכולה.

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

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

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

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

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

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

איך מנהלים את זה?

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

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

בסופו של דבר- החלק הקשה- תוכנית פעולה למניעת הסיכון או להתמודדות איתו.

הגעתם עד לכאן?

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

 

  1. תכולה לא מוגדרת
  2. שינויים לא מנוהלים
  3. תוספות מיותרות לתכולת הפרויקט
  4. הערכות לא מדוייקות
  5. תלויות ואילוצים חסרים בתכנון הפרויקט
  6. משימות חסרות בתכנון
  7. הערכות עלות לא מדוייקות
  8. שינויי מט"ח (במיוחד כשהלקוח משלם בדולרים והשכר לעובדים בשקלים)
  9. בקשות שינויים רבות
  10. חוסר החלטיות בהנהלה
  11. הגדרת דרישות לא מדויקת/ חלקית/ דו משמעית
  12. בקשות שינויים עם תיאור לא מדוייק/ חלקי/ דו משמעי
  13. בקשות שינויים הסותרות דרישות קיימות
  14. חברי הפרויקט לא מעודכנים בסטטוסים
  15. ציפיות מהפרויקט שאינן בדרישות
  16. מעבר בעלי תפקידים בפרויקט (כולל מנהל הפרויקט)
  17. מעורבים בפרויקט שמעוניינים בכשלון הפרויקט
  18. אי הסכמה בצוות הפרויקט
  19. איכות תוצרים נמוכה (מוצר/ מסמך/ תהליך/ מצגת…)
  20. עודף תקשורת בפרויקט (כשעובדים יותר על מיילים ופגישות סטטוס ולא נשאר זמן לתוצרים)
  21. מעט מדי תקשורת (ניתן לזהות כשיותר מאדם אחד שואל אותך במסדרון מה הסטטוס- ולא מתוך נימוס)
  22. אנשים המושפעים מהפרויקט נשכחים מרשימות התפוצה
  23. חוסר במשאבים (כ"א, תקציב, זמן)
  24. עקומת למידה של עובדים חדשים מעכבת את הפרויקט
  25. חסר חומר הדרכה
  26. עובדים עם חוסר נסיון
  27. עובדים עם תפוקה נמוכה
  28. חברי צוות עם גישה שלילית לפרויקט
  29. ארכיטקטורה שגויה שאינה מתאימה לדרישות
  30. ארכיטקטורה נוקשה ולא גמישה לשינויים
  31. ארכיטקטורה לא יישימה או יקרה מדי
  32. ארכיטקטורה לא סקלאבילית (scalable)
  33. טכנולוגיה שלא מתאימה לסטנדרטים רגולטורים
  34. טכנולוגיה עם בעיות אבטחת מידע
  35. טכנולוגיה מסובכת ומסורבלת
  36. רכיבים לא יציבים או אמינים
  37. חוסר במסמכים
  38. חסרה תמיכה ברכיבים ממערכות ישנות (אין מי שמכיר את הקוד/ אין מסמכים/ אין את המקור- גם זה קרה)
  39. עיכוב בתשתית
  40. קושי בממשקים עם התהליכים העסקיים (אני אקדיש לזה פוסט שלם מתישהו)
  41. קושי בממשקים עם מערכות קיימות
  42. בעיות בסביבת הבדיקות- המערכת לא תואמת את הייצור או לא יציבה (מתי היא כן תואמת את הייצור או יציבה? זה קרה פעם למישהו?)
  43. קושי בהתאמת המערכת למבנה הארגוני (מאוד חשוב- וגם זה יהיה פוסט מתישהו)
  44. הפרויקט מפריע להתנהלות השוטפת של הארגון- פוגע בהכנסות, בעמידה בזמנים, בתהליכים…
  45. הפרויקט פוגע באסטרטגיה של הארגון
  46. חוסר החלטיות בצוות הפרויקט
  47. החלטות עמומות בנסיון להימנע מלקיחת אחריות
  48. אי הגדרת תפקידים ואחריות
  49. איחורים באישור הנהלה
  50. ההנהלה לא מגבה את מנהל הפרויקט
  51. אי הסכמה בהנהלה לגבי החלטות בפרויקט
  52. תחלופה בהנהלה פוגעת בפרויקט
  53. רה-ארגון יוצר עיכובים בפרויקט
  54. מיזוג ורכישה של חברת צד שלישי גורם לעיכוב בפרויקט
  55. טכנולוגיה חדשה בשוק הופכת את הפרויקט ללא רלוונטי
  56. תלונות מהמשתמשים במוצר
  57. ממשק המשתמש באיכות נמוכה
  58. ממשק למשתמש לא נוח או לא נגיש לנכים/ חרשים/ עוורי צבעים
  59. השימוש במוצר גורם לירידה במדדי המשתמשים
  60. המוצר לא נמכר
  61. המוצר יוצר בעיות משפטיות
  62. המוצר פוגע במיתוג החברה ו/או המוניטין שלה
  63. איחורים באישור רכש וכספים
  64. רכש- אין מענה למכרז או מענה ממעט מאוד חברות
  65. רכש- מו"מ נסגר במחיר גבוה
  66. רכש- ספק עם תנאים לא מתאימים בחוזה
  67. רכש- פרויקט אחר עם הספק משפיע על היחסים בפרויקט הנוכחי
  68. רכש- קונפליקט בין שני ספקים בפרויקט
  69. רכש- הספק מאחר באספקה
  70. רכש- הספק מגיש תוצרים באיכות נמוכה
  71. רכש- הספק גורר מעורבות צד שלשי
  72. רכש- הספק מעביר מידע/ תוצרים למתחרים

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

בהצלחה!

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

להשאיר תגובה

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

הלוגו של WordPress.com

אתה מגיב באמצעות חשבון WordPress.com שלך. לצאת מהמערכת /  לשנות )

תמונת גוגל פלוס

אתה מגיב באמצעות חשבון Google+ שלך. לצאת מהמערכת /  לשנות )

תמונת Twitter

אתה מגיב באמצעות חשבון Twitter שלך. לצאת מהמערכת /  לשנות )

תמונת Facebook

אתה מגיב באמצעות חשבון Facebook שלך. לצאת מהמערכת /  לשנות )

מתחבר ל-%s