1. General Dynamics & Computer outsourcing the IS function
Sciences Corporation
outsourcing the IS function
מגישים: ביתן שושי
בן חיים אביגיל יעקב דיקלה
גלוזר שרית נחמיאס נוריאל
חיימי אשר בלסיאנו פבל

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

3. רקע כללי:
עד שנת 1989 – נפילת חומת ברלין – העולם מחולק לשני גושים:מזרח ומערב.
המצב בן שני הגושים מוגדר כ"מלחמה קרה" – שני הגושים מתחמשים לקראת מלחמה עתידית לא ידועה תוך ניהול קרבות במדינות עולם שלישי וחימוש צבאות ידידים לכל צד.
דבר הגורר בעקבותיו מרוץ התחמשות בלתי נפסק – שגורר פריחה של שוק צבאי בעולם.
לאחר נפילת המשטר הקומוניסטי והמהפכות שניהל גורבצ'וב השתנה המצב בעולם והוכרזה סופה של המלחמה הקרה
בסביבה הזאת עובדת חברת General Dynamics – חברה לייצור נשק.

4. רקע כללי על חברת GD חברה שעוסקת במגזר הממשלתי בטחוני.
מייצרת כלי טייס,צוללות,טילים,מערכות אלקטרוניקה ועוד.
החברה השנייה בגודלה בתחום.
בעת המלחמה הקרה הגיעו הכנסותיה מהממשל לשיא של 10.2 מיליארד דולר.
עם סיום המלחמה הקרה תקציב הביטחון של הממשל בארה"ב צומצם מ-96.8 מיליארד דולר ב-1985 ל-54.4 מיליארד בשנת 1993.
לחברה מונה מנכ"ל חדש ויליאם א. אנדרס בשנת 1991 (הצטרף לחברה ב-1990).
בחברה פועלת מחלקת IT ריווחית –DSD (Data System Division) –עם הכנסות של 370 מיליון דולר בשנה.

5. המשך...
בשנת 1991 התקשרה חב' GD בחוזה ל- outsourcing למנגנון מערכות המידע שלה עם חברת CSC.
חוזה ה- outsourcing למערכות המידע הגדול ביותר בהיסטוריה.
חב' GD תמכור את חטיבת מ"מ שלה (DSD) לחברת CSC על כל נכסיה,כולל כ"א.
במשאבים החדשים, תמשיך חברת CSC לספק שרותי מערכות מידע ל-GD ובנוסף גם ללקוחות נוספים.

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

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

8. DSD – (Data System Devision)
בעקבות בדיקה שנעשתה בשנת 1972 הוחלט לרכז את הפעילויות לחטיבת רווח והפסד.
עד שנת 1976 הושלם הריכוז לחטיבה עצמאית עם כ-1500 עובדים.
שם היחידה נקבע : Data System Servious
בשנת 1981 הוחלף השם ל- Data System Devision.
מתקני החטיבה היו ממוקמים ב-3 מרכזים אזוריים ו-28 אתרי שרות קטנים.
החומרה כללה 19 מחשבי MF,מחשב CRAY,440 מחשבי מיני,3700 תחנות עבודה ויותר מ מחשבי מיקרו.לחטיבה 3 רשתות מבוזרות.

9. DSD- המשך... עיקר הפעילות התרכזה בתחומים הבאים:
סיפוק מגוון רחב של שרותי המידע לכל החברה כולל עיבוד מידע,מערכת הנדסה,פיתוח תוכנה ומערכות מורכבות בתוך הארגון.
ניהול המידע העסקי של החברה:כספים ,מלאי וכדומה.
היכולות כללו CAM/CAD , יישומים עסקיים,עיבוד מבוזר,מע' אלקטרוניות.
שווי הנכסים בשנת 1991 היה 140 מיליון דולר.
סך העובדים בחטיבה בשנת 1991 היה 3400 עובדים.

10. CSC – Computer Sciences Corporation
הוקמה ב-1959, חברת התוכנה הראשונה ב- NYSE.
חברה המתמחה בטכנולוגית IS למגזרים הפרטי והפדראלי.
בשנת 1991 היו למעלה מ-23,000 עובדים.
העובדים חולקו ל-4 חטיבות הבאות:
- חטיבת מערכות.
- חטיבת שרותי תעשיה.
- חטיבת יעוץ.
- חטיבת אירופה.
החברה בעלת הכנסות של מיליארד דולר בשנת 1991.
החברה זכתה ב-54% מהמכרזים החדשים של הממשל.

11. אסטרטגית CSC
החברה התמקדה במגזר הממשלתי בארה"ב והיוותה את החברה הגדולה בתחומה.
החברה בחנה באופן מתמיד את האפשרות להיכנס לשוק המסחרי.
בחמש השנים עד 1991 האסטרטגיה הייתה לפתח חוסן כלכלי ולהגדיל את הנוכחות בשוק המסחרי. בתקופה זו החברה הגדילה את הכנסותיה בכ-15% לשנה.
מטרת CSC הייתה להיות אחת משלוש החברות מספקות השירותים המובילות בעולם.
עסקת DSD אמורה להוות את הפריצה לשוק המסחרי.

12. Outsourcing in CSC לחברת CSC לא היה ניסיון ב-outsourcing .
רכישת DSD היוותה נקודת מפנה בתחום ה- outsourcing לחברת CSC.

13. השתלשלות האירועים:
– חברת CSC מציגה להנהלת GD את תצורת העבודה שלה כחברת outsourcing .
עד – בסדרת פגישות נבחנה האפשרות לפרויקט משותף בין שתי החברות.
– הוחלט ש-CSC תוביל את הפרויקט המשותף.
– מונה מנכ"ל חדש ל-GD.
– ההחלטה על פרויקט משותף מתקבלת.
– נדחות המלצות של חברת ייעוץ חיצונית לפירוק DSD למרות החיסכון הצפוי של למעלה מ-240 מיליון דולר בארבע שנים.

14. המשך...
– בחינה הדדית של החברות לביצוע הפרויקט מובילה לפיצוץ העסקה עקב אי יכולת לגשר על הפערים –הפרש של 100 מיליון דולר בין הצדדים.
לאחר בחינת הנתונים הגיע רעיון חדש מכיוון GD – הצעה לחברת CSC לרכישת DSD ומתן שרותי outsourcing בתשלום במקום מיזם משותף. דבר שתואם את תפיסת ההנהלה החדשה של GD ויתור על תחומים שלא מוגדרים כליבה.

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

16. החלטות outsourcing – CSC.
הנושאים המרכזיים שנבדקו ונדונו:
מהי העלות הסבירה לתשלום?
מהו הרווח הצפוי?
בכמה מנכסי GD יהיה ניתן להשתמש גם אצל לקוחות אחרים?
עד כמה תהיה CSC רגישה לשינויים בתוך GD?
אפשרויות השתלבות והייעול ב-DSD.

17. סיכום נובמבר 1991 – נחתם החוזה בין GD ל-CSC,על סך של 200 מיליון דולר.
DSD נמכרה ב-190 מיליון דולר בהפחתה של 10 מ' דולר החזר מ-GD ל-CSC.
2600 עובדי DSD עברו ל-CSC לטובת שרותי מחשוב כלליים.
800 עובדים יישאר ב-GD לצורך פיתוח מוצרים משובצי מחשב.
GD התחייבה לרכוש שירותים ל-10 שנים בעלות של 360 מ' דולר לשנה.

18. סיכום – המשך... GD נכון לכתיבת המאמר:
החברה מעסיקה יותר מ עובדים.
החב' מחולקת ל-4 חטיבות: אווירונאוטיקה,מערכות קרב,מערכות מידע טכנולוגיות,מערכות ימיות.
היקף הכנסות החברה :8.8 מיליארד דולר (נכון להיום 5 מיליארד דולר.
CSC נכון לכתיבת המאמר:
החברה מעסיקה למעלה מ-47000עובדים.
החברה מתמקדת בשלושה תחומים מרכזיים:יעוץ,מערכות מידע, outsourcing .
היקף הכנסות החברה:7.1 מיליארד דולר (נכון להיום 11.4 מיליארד דולר).

19. המלצות לפעולה: מערכות מידע אסטרטגיות חייבות להיתמך ולהתפתח בתוך החברה.
חוזה ל-10 שנים אינו ריאלי בתנאי השוק המשתנים . ל-GD היה עדיף לחתום על חוזה קצר מועד.
שמירה על תחרות – GD חייבת לשמור על רמת תחרות ראויה ע"מ לדאוג לכך ש-CSC תהיה במתח עבודה מתמיד לשיפור המערכות של GD.

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

21. גישת "תיק פקרוייקט" לפיתוח IT

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

23. חברת כרטיסי אשראי גדולה מעריכה לא נכון דרישות עיבוד נתונים ביותר מפי 10 כשהיא מעבירה את מערכת עיבוד כרטיסי האשראי שלה לספק חדש.
התוצאות:
- המערכת מתרסקת.
- 1.5 מיליון חשבונות בסיכון.
- רמות השירות צונחות.
- ה-CIO (Chief Information Officer) ואחד הכפופים לו מפוטרים.

24. חברת תעשיה מאחדת את הפעילויות שלו ביותר מ-50 מפעלים, משרדי שטח ונקודות מכירה למרכז שירות ארצי.
רק לאחר שהאיחוד כבר נימצא בביצוע מבינה החברה כי זמן ההמתנה הממוצע לאישור ההזמנות עומד על 25 שניות,כאשר הערכות הנהלת החברה הן כי זמן ההמתנה העולה על 2 שניות הופך את המערכת ללא שווה.

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

26. המקרים הנ"ל אינן בשנות ה-60 ותחילת שנות ה-70, אלא מהתקופה האחרונה.
רובן מסוף שנות ה-90 וכמה מהמאה ה-21, וזאת למרות ידע מצטבר בפרויקטי IT של 40 שנה, ימי הכישלונות לא חלפו. מדוע?
קיימים 3 פגמים עיקריים הנוגעים למנהלי IT ובכלל:
1. כישלון בהערכת סיכוני המימוש של פרויקט בזמן מימון הפרויקט.
2. אי התחשבות בסך כל הסיכונים בפרויקט.
3. חוסר הבנה שפרויקטים שונים דורשים גישות ניהול שונות.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

46. כלים לניהול פרויקט: סוג הפרויקט גודל הפרויקט אינטגרציה חיצונית
אינטגרציה פנימית
תכנון פורמאלי
כלי בקרה
מבנה גבוה-טכנולוגיה נמוכה
גדול
נמוך
בינוני
גבוה
מבנה גבוה –טכנולוגיה נמוכה
קטן
מבנה גבוה-טכנולוגיה גבוהה
מבנה גבוה - טכנולוגיה גבוהה
מבנה נמוך – טכנולוגיה נמוכה

47. סוג הפרויקט
גודל הפרויקט
אינטגרציה חיצונית
אינטגרציה פנימית
תכנון פורמאלי
כלי בקרה
מבנה נמוך - טכנולוגיה גבוהה
גדול
גבוה
נמוך
מבנה נמוך – טכנולוגיה גבוהה
קטן

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

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

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

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

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

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

54. THE END