רשימת הנושאים
ניהול-מערכתי-עסקי של פרויקט
ניהול סיכונים בפרויקט
ניהול פרויקטים על פי סון טסו
סקרי תיכון וסקרי אמצע פרוייקט
בנית תוכנית עבודה והגדרת גאנט הפרויקט
הגדרת דרישות
האתגרים בניהול זריז של פרויקטים ב- SCRUM
שיפור איכות תכנון וניהול הפרויקט
מחבילות עבודה לתכנית פעולה של הפרויקט
מה זה Base Line בתוכנית הפרויקט?
מהיא מטריצת RAM בפרויקט?
מקור המידע לחבילות עבודה WBS?

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

רשימת כותבים
גדעון קוך

שיפור איכות תכנון וניהול הפרויקט

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

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

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

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

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

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

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

תגובה לנושא
הצעה לנושא חדש


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

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

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

תכנון מלא כולל מציאת חלופות משפר את המוצר, משך הפיתוח ומוריד את עלותו.

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

למה לא עושים את זה?
מי רוצה לעשות את זה ולקבל מכולם על הראש?
תרבות השיח אינה נוחה ואף אחד לא רוצה לקבל אחריות על הכל.
על אחריות לא מתגמלים
ראש גדול אינו נחשב חברתית

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

תגובה לנושא
הצעה לנושא חדש



כל הזכויות שמורות לגדעון קוך