Download presentation
Presentation is loading. Please wait.
1
מחזור החיים של פרויקט מערכות מידע
ניהול פרויקטי IT IT Project Management אמנון אלבי ניהול פרויקטים 2005
2
Sample size: 365 companies
31% 53% 16% Successful Exceeded Budget Cancelled Sample size: 365 companies גורמי הצלחה של פרויקט
3
כישלונות של פרויקטי טכנולוגיות מידע
אחוז גבוה של פרוייקטי IT נכשלים (כשני שלישים) קשיים: כל ה"מכונות" המשתתפות בתהליך הייצור הן אנושיות הערכת תכולה ומשאבים נדרשים שינויים בסביבה במהלך הפיתוח ייצוב דרישות המשתמשים מדידת התקדמות מדידת איכות התוצרים 2 סיבות עיקריות לכישלונות : האחד הגורם הראשי הוא אנושי . השני הוא ה SETUP . המטרה היא לגרום לכמה שפחות סטאפים. ובכל סוג וסוג יש סטאפ אחר. הכוונון הוא קשה מאוד . לדוגמא:לפני פסח רוצים לייצר כשל"פ רק הכמות שתיצרך בפסח ,כי אחרי פסח האנשים לא ירצו לקנות את השיריים של הכשל"פ כי זה ישן ופחות טעים. גורמי הצלחה של פרויקט
4
הצורך במערכת מידע חדשה (ייזום)
שינויים בסביבה (רגולאטור, מתחרים, ספקים, לקוחות וכו') שינוי כיוון אסטרטגי של הארגון (מוצרים, שירותים או פעילויות חדשים) התפתחויות טכנולוגיות גידול בפעילות שינויים במערכות קשורות שינויים בצפיות המשתמשים עלות מול תועלת של תחזוקת המערכת הקיימת בשלב הייזום. השקעה מחזירה את עצמה בזמן סביר, מוכח בצורה פשוטה, השקעה סבירה לפירמה . הסיכון נמוך. וקלות למשתמש. מנהלים חוששים מהרפתקה ולא רוצים לקחת סיכון מיותר . עושים עים המנהל ניהול סיכונים. גורמי הצלחה של פרויקט
5
דרכי פעולה אפשריות רכישה פיתוח ללא התאמה התאמה מיקור חוץ עצמי
צורך במערכת חדשה רכישה פיתוח ללא התאמה התאמה מיקור חוץ עצמי גורמי הצלחה של פרויקט
6
מחזור החיים של מערכת מידע
ייזום חקר מצב קיים אפיון ראשוני חקר ישימות ניתוח עיצוב הקמה יישום תפעול ואחזקה מה ההבדל ניתוח מצב קיים – מתארים את המצב הקיים אצל הלקוח שלנו כרגע , כל המצב הקיים לא רק מבחינת מערכות מידע מסמך איפיון/מסמך ניתוח – הצעת המערכת החדשה איך היא באה לפתור את הבעיות במצב הקיים חקר יישימות- מבצעים עבודת בדיקה לראות האם שווה כל התכנון וכל הפתרון. האם אנו ממשיכים לכיוון הפתרון או שזה לא שווה כבר. ניתוח – המשתמשים (המנהלים) הם המאשרים את המצב הקיים , המבנה והבעיות הקיימים בחברה בארגון. מהם תהליכי העבודה וכיצד אנו מציעים לפותרה עיצוב- מסמך העיצוב לוקח את מסמך האפיון- הניתוח , ובונה את כל המבנה של המערכת לכל חלקיו ופרטיו.קשריו , יישויות ,תכונות דאטה בייס, מסמך טכני מאוד. לוקחים תמיד את מסמך האיפיון וממנו אנחנו יוצאים. ובמבחני הקבלה לוקחים את מסמך האיפיון שלפיו המתכנתינים עבדו , ובודקים כל פרק ופרק , מרכיבים לו ארוע עם נתונים בדוקים מראש ותומאה בדוקה מראש ע"מ לראות האם התוכנית עובדת כדבעי. יש לצקת נתונים לא פחות מדי ולא יותר מדי לתוך המערכת. אך יש לבדוק עוד 2 דברים. 1: אריטמטית עובדת נכון כשמזינים ערכים נכונים 2. ערכים אבסורדים כמו חלוקה ב0 וכפל ב0, שתומיא הודעת שגיאה וקבלת נתון מחדש בכל שינוי בפרוייקט במהלך הפרוייקט צריכים לתת לו עדכון במסמך האיפיון. ולתעד את השינוי ולגזור את מה שצריך בהתאם. ניהול תצורה- עדכון מסמכי האיפיון. מסמך האיפיון הוא מסמך בין מאות עמודים ואם לא נוודא שהלקוח קרא כל פרט בו ואישר כל פרט בו , נתקע עימו אח"כ, וכנ"ל לתקן פרוייקט לאחר שהוא כבר רץ זה עולה הרבה יותר כסף מתיקון בשלב המקדמי. מכאן לשקף 10 גורמי הצלחה של פרויקט
7
Discover, develop, and deploy assets
Source: IBM Software Group Discover, develop, and deploy assets Prioritize Plan Manage Measure Business Discover business & technology assets Develop at the speed of business Deploy to closed-loop environments Last updated: 12/10/04 Operations Optimize Iterate גורמי הצלחה של פרויקט
8
The business-driven development lifecycle
Source: IBM Software Group The business-driven development lifecycle Prioritize Plan Manage Measure Business End User Model the Business Define Requirements Analyze & Design Implement Test Deploy Manage Optimize Executive Analyst Operations Manager Govern Architect Application Support Project Manager Manage change & assets Developer Deployment Manager Tester Operations Development Optimize Iterate גורמי הצלחה של פרויקט
9
Follow a common process Manage and measure projects and portfolios
Source: IBM Software Group Analyst Architect Developer Tester Deployment Manager Model, simulate, assemble, and monitor processes Rapidly construct, transform, integrate and generate code Provision, configure, tune and troubleshoot applications Design, create, and execute tests Visually model applications and data Follow a common process Manage and measure projects and portfolios Manage requirements Manage change and assets Manage quality Project Manager Last updated: 10/12/04 Let’s see how the IBM SDP supports all the roles of the typical development team.... The IBM Rational Software Development Platform is not a single product, but an integrated set of products that lets you choose what's right for your team and technology environment. It provides capabilities that are optimized for each role on the development team: business analysts, developers, testers, and so on. At the same time, the IBM Rational Software Development Platform enables high degree of team cohesion through shared access to common requirements, test results, software assets, and workflow and process guidance. Combined, these capabilities improve both individual and team productivity. Align investments with business objectives Analyze and monitor project portfolios Executive גורמי הצלחה של פרויקט
10
איכות תוכנה שלב הניתוח – 50% מהבעיות שלב העיצוב – 30% מהבעיות
מקור בעיות בתוכנה: שלב הניתוח – 50% מהבעיות שלב העיצוב – 30% מהבעיות שלב התכנות – 20% מהבעיות עלות תיקון הבעיות: Req Design Coding Int. test Sys. test Operation רב הבעיות נוצרות בשלב הניתוח. לכן יש לשוחח לא רק עם המנהל אלא גם עם כל אנשי המשרד וכלל העובדים. בדיון אין מנהל ועובדים אלא לכולם אותו ערך ושווי. הפתרון הוא שיקוף- היזון חוזר "מה הבנתי מדבריך". Review מכאן קפצנו לשקופית 13 גורמי הצלחה של פרויקט
11
Source: IBM Software Group
Unmanaged requirements cause unmanageable budgets: Primary reason for excessive rework, delays, and poor quality 200 Time not spent in requirements is time spent in rework (at cost x200) 50 20 Relative Cost to Repair 10 5 Why spend time managing requirements when your deadlines are always around the corner. Requirements management is really a risk mitigation strategy. By managing requirements you decrease your risk to deliver the wrong thing to your customers. Studies show that requirements errors are the most common and most pervasive problem throughout the software lifecycle (primary reason for excessive rework, delays and poor software quality). Requirement errors are also the most expensive to fix IF they’re not caught early. The numbers on the chart are cost-to-repair factors If you find and fix a requirement error at the coding stage<POINT>, it costs 5 to 10 times more than if had found that error in the early phase. If you find a requirement error during the maintenance phase <POINT>, it can cost 100 to 200 times more than if you had caught it in the reqt phase. Clearly, there is a huge return on investment from managing requirements early on in the software lifecycle. Business Analysts are on point to communicate clearly what to build, what to test and what to document. By giving them the time they need to come up with the right requirements, you save yourself time spent at the end of the project reworking the software because it does not provide value to its users. 1-2 Analysis Design Coding Unit Test Acceptance Test Maintenance Stage in which Requirements Error Is Discovered גורמי הצלחה של פרויקט
12
Does this sound familiar?
Source: IBM Software Group Does this sound familiar? We don’t have time to do requirements – we have to start building the system today! Have you ever heard anybody say this? Have you ever said it? This has interesting implications about the maturity of an organization. גורמי הצלחה של פרויקט
13
אבטחת איכות תוכנה בקרת איכות ניתוח הדרישות – Requirement Review
אוסף פעילויות שיש לנקוט במהלך הפרוייקט כדי לצמצם את כמות וקריטיות הבעיות שיתגלו עם השלמת תהליך הפיתוח (בבדיקות ו/או ביישום אצל הלקוח) הכנת תכנית אבטחת איכות כוללת לפרוייקט: בקרת איכות ניתוח הדרישות – Requirement Review בקרת איכות עיצוב המערכת והפתרונות הטכניים המוצעים – Design Review קביעת אבני דרך ברורות, אישור תוצר של אבן דרך לפני מעבר לשלב הבא תכנון בדיקות, בדיקת כל תוצר בשלב מוקדם ככל האפשר ניתוח וניהול סיכונים ניהול שינויים ובקרת קונפיגורציה כל יצרן אומר שבמוצר הנמכר אין תקלות ואם יש אחליפנו במקום. לכך יש אחריות . במערכות המידע לעולם לא נגיד משפטים מעין אלו , אדרבה נאמר שעשינו את כל ההשתדלות , ויש תקלות והאחריות היא לתקן ברגע שיהיו. לא נבטיח הגנה מנזקים , ונאמר מראש שיש תקלות . עיין ערך גוגל שעד לאחרונה היה שם כיתוב של "גוגל ביטא"- הגירסה אצל הלקוח. ואלפה זה כבר לשיווק סופי . רק לאחרונה הביטא ירד לחלוטין. ולמעשה לגוגל אין אחריות ושירות . א"כ התהליך של אבטחת האיכות בא להבטיח , שאנו עובדים לפי תקן ונהלים מסויימים כמו ISO כמו שהצהרנו מראש . וכל שלב נולד מקודמו. אחריות לנהלים . אהטחה לגבי הנהלים שאני קבעתי ואני מפרסמם . יש אחידות בפיתוח של התוכנה לכל אורך הדרך כמו ההצהרה הראשונה. גורמי הצלחה של פרויקט
14
נוהל מפת"ח מגדיר כיצד יש לבצע תהליכי עבודה בשתי רמות: רמת הפרויקט – מה הם הנהלים בניהול ופיתוח של פרויקט הקמת מערכת מידע רמת הארגון – מה הם הנהלים בטיפול בתחום מערכות מידע בארגון מתייחס לשני מימדים בפרויקט פיתוח: עץ מערכת – מציע פרוק של המערכת לרכיבים ותת- רכיבים מחזור החיים – מתייחס לשלבים השונים בפרויקט הפיתוח גורמי הצלחה של פרויקט
15
כלי CASE (Computer Aided Software Engineering)
כלים ממוחשבים שמטרתם לסייע בתהליך פיתוח מערכת סיווג לפי אופי התוצרים: Upper CASE – כלים שמיועדים לשלבים הראשוניים של תהליך הפיתוח – ייזום, חקר מצב קיים, אפיון ראשוני Middle CASE – כלים שמיועדים לשלבים האמצעיים של תהליך הפיתוח – הניתוח ועיצוב Lower CASE – כלים שמיועדים לחלקים האחרונים של תהליך הפיתוח – הקמה ואחזקה יתרונות בשימוש בכלי CASE: האצת תהליך הפיתוח, מחשוב התהליכים, סטנדרטיזציה, שילוב בדיקות תוכנה, תיעוד בשלבי בפיתוח והתחזוקה גורמי הצלחה של פרויקט
16
ניתוח סיכונים סיכונים מתודולוגים – שימוש במתודולוגיות וסטנדרטים חדשים
סיכונים טכנולוגיים – טכנולוגיות לא בשלות, אינטגרציה בין טכנולוגיות, מורכבות, חוסר ידע טכנולוגי בצוות סיכונים ניהוליים – חוסר ניסיון ניהולי, תלות באנשי מפתח, מוטת שליטה, ביזור ותחלופת כ"א סיכונים הנובעים מהלקוח או מהמשתמש – חוסר ייצוב הדרישות, חוסר/יתר מעורבות סיכונים סביבתיים – מוצר תחליפי/מתחרה, מימון סיכונים חוקתיים גורמי הצלחה של פרויקט
17
ניתוח וניהול סיכונים מזהים את הסיכונים (לפי תחומים)
מעריכים את ההסתברות להתרחשות ואת דרגת החומרה, אשר קובעים את רמת הסיכון קובעים פעולות מצמצמות/מונעות לכל סיכון מתכננים תכנית מעקב וניהול של כל סיכון (אחראי, לו"ז, שיטת בקרה) מנהלים מעקב תקופתי אחר הסיכונים בכל מהלך הפרוייקט, מעדכנים במידת הצורך גורמי הצלחה של פרויקט
18
רמת הסיכון = סיכוי X דרגת חומרה
הערכת סיכונים חומרה – נזק אפשרי שיגרם כתוצאה מהתממשות הסיכון סיכוי – הסיכוי שהנזק אכן יתרחש רמת הסיכון = סיכוי X דרגת חומרה גורמי הצלחה של פרויקט
19
ניתוח סיכונים גורמי הצלחה של פרויקט
20
גופים ארגוניים המעורבים בפיתוח
ועדת מערכות מידע ועדת ההיגוי צוות הפיתוח צוות היישום גורמי הצלחה של פרויקט
21
גורמי הצלחה קריטיים מעורבות הנהלה בכירה ייצוב הדרישות
בהירות תפקידים בצוות הפרוייקט הערכה נכונה של סיבוכיות ציפיות ריאליות של נציגי המשתמשים תקשורת אפקטיביות בתוך צוות הפרוייקט ועם נציגי המשתמשים גורמי הצלחה של פרויקט
22
בעיות תקשורת גורמי הצלחה של פרויקט
23
מחזור החיים של הפרויקט - שלב הייזום
אמנון אלבי גורמי הצלחה של פרויקט
24
מחזור החיים של הפרויקט מינהלה – ניהול לקוחות/משתמשים/ספקים
מהלך הייזום מינהלה – ניהול לקוחות/משתמשים/ספקים תכנון מהלך הפרויקט ביצוע סגירה גורמי הצלחה של פרויקט
25
בעלי העניין בפרויקט הלקוח המשלם הדרג האסטרטגי המשתמש המומחה הדרג הטקטי
הלקוח: הלקוח המשלם הדרג האסטרטגי המשתמש המומחה הדרג הטקטי העושה במלאכה הדרג הלבלרי הצופים מן הצד המינהלה: הנה"ח... ספקים/קבלני משנה מתחרים לקוחות עתידיים המנהלים/המבקרים שלנו, מנהלי הפרויקט גורמי הצלחה של פרויקט
26
בעלי עניין בפרוייקט מוטיבציה לשיתוף פעולה משתמש סופי צוות הפרוייקט
גבוהה מחלקת רכש הנהלה נמוכה מתחרים לקוח ספקים נמוך גבוה היקף מעורבות גורמי הצלחה של פרויקט
27
- מספר "טיפים" לספק המגיש -
ייזום פירושו מכירה - מספר "טיפים" לספק המגיש - זיהוי של הלקוח איתור הבעיה ← להפוך את הבעיה לצורך/תועלת עסקית אבחון של הפתרון + הגדרה של מבחן הקבלה בחינה של חלופות תהליך בחירה ← כלכלי TCO , IRR, NPV, ROI לפי תועלות עץ או טבלת החלטה החלטה לפי עלות/תועלת גורמי הצלחה של פרויקט
28
נוהל מפת"ח הסדר המחייב של הפרקים: פרק 1 - מטרות או יעדים פרק 2 - יישום
פרק 0 - "כללי המשחק", המינהלה של המכרז פרק 1 - מטרות או יעדים פרק 2 - יישום פרק 3 - טכנולוגיה פרק 4 - מימוש פרק 5 - עלות סעיפים בכל פרק: 90-1, תוספות ספק: מעל 90 גורמי הצלחה של פרויקט
29
נוהל מפת"ח רמות התייחסות (לכל פרק/סעיף): (I) - Informative only
(G) – General (S) - Specified (M) - Must גורמי הצלחה של פרויקט
30
טכניקת העבודה ← הקביעה של הזוכה
RFI – request For Information/Intentions RFP – Request For Proposals ההכנה קביעה של אוכלוסיית הספקים + הפצה המפ"ל – מסמך פנימי להערכה יחס של מחיר/עלות שקלול הסעיפים כנס הספקים מיון ראשוני Best & Final ההסכם גורמי הצלחה של פרויקט
31
שקלול חלופות - דוגמה שרות (משקל=15%) ציון שרות במקום האתר 100
שרות (משקל=15%) ציון שרות במקום האתר זמן תגובה עד 4 שעות זמן תגובה עד יום 60 זמן תגובה עד שבוע תיעוד למשתמש (משקל=10%) תיעוד מלא עברית/אנגלית תיעוד מלא אנגלית 70 תיעוד חלקי אנגלית 50 אין תיעוד גורמי הצלחה של פרויקט
32
דוגמא להשוואת חלופות קריטריון משקל הצעה א' הצעה ב'
קריטריון משקל הצעה א' הצעה ב' ציון משוקלל ציון משוקלל התאמה לצורך % התאמה לאסטרטגיה % תפעול % משך ביצוע % סיכון % קלות הטמעה % סה”כ גורמי הצלחה של פרויקט
33
דוגמא לניתוח עלות/תועלת
קריטריון משקל הצעה א' הצעה ב' ציון משוקלל ציון משוקלל התאמה לצורך % התאמה לאסטרטגיה 25% תפעול 15% משך ביצוע 10% סיכון 10% קלות הטמעה 10% סה”כ תועלת עלות פרויקט 50, ,000 יחס (עלות/תועלת) גורמי הצלחה של פרויקט
34
תכולת העבודה WBS – Work Breakdown Structure אבני הדרך/תוצרים
SOW – Scope/Statement Of Work WBS – Work Breakdown Structure אבני הדרך/תוצרים תאריך הסכם תאריך אילוץ גורמי הצלחה של פרויקט
35
ההסכם הצעה וקבלה מילון המונחים, להלן: עקרון המדידה האחריות ערבויות
הצדדים להסכם הצעה וקבלה מילון המונחים, להלן: עקרון המדידה האחריות ערבויות נספחים גורמי הצלחה של פרויקט
36
ניהול פרויקט לפי תורת PMI
ניהול לפי תשעה תחומים + אחד חדש של גופי הידע BOK: 1 אינטגרציה Integration 2 תכולה Scope 3 זמן Time 4 עלויות ותקציב Cost & Budget 5 איכות Quality 6 משאבי אנוש Human Resources 7 תקשורת Communication 8 סיכונים Risk 9 רכש Procurement 10 אתיקה Ethics גורמי הצלחה של פרויקט
37
ניהול פרויקט לפי תורת PMI
ניהול כול תחום ידע 1 אינטגרציה Integration 1.1 פיתוח תוכנית הפרויקט Pr. Integration development 1.2 ביצוע תוכנית הפרויקט Pr. Plan execution 1.3 בקרת שינויים אינטגרטיבית Integrated change control 2 תכולה Scope 2.1 פירוק למרכיבים WBS - Work breakdown Structure 2.2 אישור התכולה Scope verification 2.3 בקרת שינויי תכולה Scope change control גורמי הצלחה של פרויקט
38
ניהול פרויקט לפי תורת PMI
ניהול כול תחום ידע 3 זמן Time 3.1 הגדרת פעילויות Activity definition 3.2 סדר הביצוע של הפעולות Activity sequencing 3.3 הערכת משך Activity duration estimation 3.4 פיתוח לוח זמנים Schedule development 3.5 בקרת לו"ז Schedule control גורמי הצלחה של פרויקט
39
ניהול פרויקט לפי תורת PMI
ניהול כול תחום ידע 4 עלות Cost 4.1 תכנון משאבים Resource planning 4.2 הערכת עלויות Cost estimation 4.3 תקצוב העלויות Cost budgeting (baseline) 4.4 בקרת עלויות Cost control 5 איכות Quality 5.1 תכנון איכות Quality planning 5.2 הבטחת איכות (התהליך, שיקוף) Quality assurance 5.3 בקרת איכות Quality control גורמי הצלחה של פרויקט
40
ניהול פרויקט לפי תורת PMI
ניהול כול תחום ידע 6 משאבי אנוש Human Resources 6.1 תכנון ארגוני, תקן Organizational planning 6.2 השמת עובדים Staff acquisition 6.3 פיתוח צוות/מצבה (טיוב, תגמול) Team development 7 תקשורת Communication 7.1 תכנון התקשורת Communication planning 7.2 הפצת המידע Information distribution 7.3 דיווח וניתוח ביצועים Performance reporting & control 7.4 סגירה מינהלית = מסירה Administrative closing גורמי הצלחה של פרויקט
41
ניהול פרויקט לפי תורת PMI
ניהול כול תחום ידע 8 סיכונים Risk 8.1 הכנת תוכנית Risk management plan 8.2 זיהוי סיכונים Risk identification 8.3 ניתוח איכותי של הסיכונים Qualitative risk analysis 8.4 ניתוח כמותי של הסיכונים Quanitative risk analysis 8.5 תכנון תגובה לסיכונים Risk response pkanning 8.6 מדידה ובקרת סיכונים Risk monitoring & control חזרה לשלב 8.2 ↑ גורמי הצלחה של פרויקט
42
ניהול פרויקט לפי תורת PMI
ניהול כול תחום ידע 9 רכש Procurement 9.1 תכנון רכש Procurement planning 9.2 תכנון פנייה לקבלת הצעות Solicitation planning 9.3 קבלת הצעות Solicitation 9.4 בחירה של מקור/ספק Source selection 9.5 ניהול חוזים Contract administration 9.6 סגירת חוזים Contract closeout גורמי הצלחה של פרויקט
43
ניהול פרויקט לפי תורת PMI
ניהול כול תחום ידע 10 אתיקה Ethics גורמי הצלחה של פרויקט
44
מחזור החיים של הפרויקט - שלב האפיון
- ההיבטים המעשיים של ביצוע האפיון - גורמי הצלחה של פרויקט
45
מסמך האפיון כתוב בשפה חד משמעית ברור באותו האופן ללקוח ולספק
מיועד עבור הלקוח כתוב בשפה חד משמעית ברור באותו האופן ללקוח ולספק התאמה של המתודולוגיה אל הפרויקט כתיבה טכנית: מבנה קשיח ואחיד לאורך כל המסמך מלים שמורות (על פי מילון המונחים) גורמי הצלחה של פרויקט
46
ביצוע האפיון זיהוי של דרגות החופש ההשוואה מול תהליכים תקניים
קבוצות דיון BRAINSTORMING קביעה של תבנית: קלט - איזה, ממי, מתי הערך המוסף פלט - איזה, אל מי, מתי זיהוי של דרגות החופש ההשוואה מול תהליכים תקניים "מתחת לפני השטח": המורכבות הבלתי נראית - הדמיון המודרך הכוונה הנסתרת מאחורי הדברים גורמי הצלחה של פרויקט
47
מחזור החיים של הפרויקט - שלב המימוש
גורמי הצלחה של פרויקט
48
People Ware הקידום הפיטרי של מנהל הפרויקט ההיבט הסוציולוגי
ניהול המשתמשים גורמי הצלחה של פרויקט
49
CSF - Critical Success Factors
מדדי הצלחה - CSF - Critical Success Factors מבחן הקבלה ההסכם ניהול המשתמשים בהתאם למדרג הניהול: הלקוח המשלם הדרג האסטרטגי הלקוח המומחה - הדרג הטקטי הלקוח העושה במלאכה - הדרג הלבלרי הלקוח הצופה מן הצד - המינהלה גורמי הצלחה של פרויקט
50
ההסכם - הצדדים להסכם - הצעה וקיבול/קבלה - מילון המונחים ("להלן:") - עקרון המדידה - האחריות - ערבויות - נספחים גורמי הצלחה של פרויקט
51
היערכות מינהלתית ועדת היגוי מינהלת דיווחים: סיכומי דיון + הדיווח הישיר
היערכות מינהלתית ועדת היגוי מינהלת דיווחים: סיכומי דיון + הדיווח הישיר Design Review Performance Review Trend analysis Earned Value ניהול שינויים ניהול תצורה תיעוד גורמי הצלחה של פרויקט
52
המדידה של המופשט ניהול התצורה מדדי הבקרה ניהול משתמשים ניהול סיכונים
א/הבטחת איכות ניהול התצורה מדדי הבקרה ניהול משתמשים ניהול סיכונים גורמי הצלחה של פרויקט
53
סגירה של הפרויקט ההיערכות ב"יום פקודה" משוב: מול הלקוח מול הצוות
יום הקרב ההיערכות ב"יום פקודה" משוב: מול הלקוח מול הצוות גורמי הצלחה של פרויקט
54
הערך המזוכה The Earned Value
גורמי הצלחה של פרויקט
55
Earned Value שיטת מדידה של ביצוע פעילויות לתאריך הדיווח:
הביצוע + העלות בפועל של הביצוע בהשוואה לתכנון התקציבי לאותו מועד הביצוע גורמי הצלחה של פרויקט
56
שיטת ה EARNED VALUE- BCWS - Budgeted Cost of Work Scheduled
BCWP - Budgeted Cost of Work Performed ACWP - Actual Cost of Work Performed גורמי הצלחה של פרויקט
57
דוגמא לבקרה בשיטת ה EV- (1)
תקציב לשבוע תקציב משך משימה 2 , 000 10 , 000 5 A 3 , 000 12 , 000 4 B 2 , 200 6 , 600 3 E 1 , 200 6 , 000 5 G 1 , 500 3 , 000 2 K 1 , 500 1 , 500 1 M 11 , 400 כ תקציב לשבוע " סה גורמי הצלחה של פרויקט
58
דוגמא לבקרה בשיטת ה EV- (2)
משימות לאחר שלושה שבועות: A B E G K M 1 2 3 4 5 6 7 שבועות גורמי הצלחה של פרויקט
59
דוגמא לבקרה בשיטת ה EV- (3)
ביצוע בפועל מתוך התקציב דיווח אובייקטיבי ע"פ תכנון הזמן out of Pocket money BCWP BCWS ACWP % ביצוע משימה 2,000 6,000 3,000 20% A 12,000 9,000 11,000 100% B - 6,600 500 E 2,400 3,600 2,500 40% G 3,000 3,000 3,000 100% K 1,500 1,500 1,200 100% M 20,900 29,700 21,200 גורמי הצלחה של פרויקט
60
דוגמא לבקרה בשיטת ה EV- (4)
מדדי בקרה: SV Scheduled Variance SV=BCWP-BCWS SV < 0, the task or project is behind schedule SV > 0, the task or project is ahead of schedule CV Cost Variance CV=BCWP-ACWP CV < 0, the task is over budget CV > 0, the task is under budget גורמי הצלחה של פרויקט
61
דוגמא לבקרה בשיטת ה EV- (5)
משימה ביצוע % ACWP BCWS BCWP SV CV A 20% 3,000 6,000 2,000 (4,000) (1,000) B 100% 11,000 9,000 12,000 1,000 E 500 6,600 - (6,600) (500) G 40% 2,500 3,600 2,400 (1,200) (100) K M 1,200 1,500 300 21,200 29,700 20,900 (8,800) (300) גורמי הצלחה של פרויקט
62
שאלות ? גורמי הצלחה של פרויקט
Similar presentations
![[ תפקידי רוחב בצוות ]. Features סיפוריםחבר צוות אחראי הערכת זמן ( בשעות ) זמן בפועל ( בשעות ) הושלם ( כן \ לא )](/15/4788833/big_thumb.jpg "[ תפקידי רוחב בצוות ]. Features סיפוריםחבר צוות אחראי הערכת זמן ( בשעות ) זמן בפועל ( בשעות ) הושלם ( כן \ לא )>")
![הוספת מנשק משתמש ל - [ תפקידי רוחב בצוות ]. Features סיפוריםחבר צוות אחראי הערכת זמן ( בשעות ) זמן בפועל ( בשעות ) הושלם ( כן \ לא )](/16/4922212/big_thumb.jpg "הוספת מנשק משתמש ל - [ תפקידי רוחב בצוות ]. Features סיפוריםחבר צוות אחראי הערכת זמן ( בשעות ) זמן בפועל ( בשעות ) הושלם ( כן \ לא )>")
