Presentation is loading. Please wait.

Presentation is loading. Please wait.

Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.

Similar presentations


Presentation on theme: "Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software."— Presentation transcript:

1 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com1 Applied Software Project Management Project Schedules

2 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Definition of a project A completion of work which must satisfy performance, time, cost, and scope (PCTS) a multiple constraints or requests Precise scope is a must www.standishgroup.com  Only 17% software projects meet PCTS  80 billion dollars are wasted on problematic software project per year

3 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management C=f(P,T,S) P = performance T = time S= scope C = cost S P C T S P C T

4 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management PTCS In principle of other discipline, the transformation between P (performance),T(time), C(cost) is true To software development, the transformation is not true. If you think you can add more people (more cost) and you can reduce the completion time. That is not true at all in software engineering It is the well-known man-month mythic More software engineering efforts, more true the principle

5 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management What is project planning Project planning is to answer questions  Do what?  How to do it?  Who is in charge ( 誰負責)  When to finish  At what cost  What kind of performance

6 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Using the work break down structure (WBS) A project needs to answer  When to complete  Complete what  What is the cost The only way to achieve this objective is to break down the work and then estimating Fact: estimating error is inevitable

7 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management WBS In software project, typically we break down the work from project -> subsystem -> modules When to stop? When a module is not too complicated but also not too detailed?  A general rule is: until you can precisely estimate its cost and time Have we done a good job?

8 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com8 What is a project schedule? The project schedule is a calendar that links the tasks to be done with the resources that will do them.  Before a project schedule can be created, the project manager must have a work breakdown structure (WBS) and estimates.  The schedule is part of the project plan.

9 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Scheduling Project Work Grantt chart (bar chart) 1950-1960  CPM (Critical Path Method)  PERT( Program evaluation and review techniques) – U.S. NAVY, add probability

10 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management

11 Andrew Stellman & Jennifer Greene Applied Software Project Management

12 Andrew Stellman & Jennifer Greene Applied Software Project Management Producing a workable schedule using critical path method leverage float labor, or resources  你必須先找出 critical path 然後才能知道你 有哪些人力,時間,資源,是浮動的,可以 調配

13 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management

14 Andrew Stellman & Jennifer Greene Applied Software Project Management ES = early start ( 最快開始時間) LS = late start ( 最遲開始時間) EF = early finish ( 最快完成時間) LF = late finish ( 最遲完成時間) DU= duration 作業時間

15 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management forward pass computation and backward pass computation compute ES, EF from the beginning of the network compute LS, LF from the end to beginning

16 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management

17 Andrew Stellman & Jennifer Greene Applied Software Project Management

18 Andrew Stellman & Jennifer Greene Applied Software Project Management critical task – ES=LS EF = LF critical path – the path constituted by critical task floating task – the task has a time buffer zone between EF and LF

19 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management comments a reminder: the time in the network is estimated time. Typically, we will loosen the estimated time. people assigned to tasks in critical path must be very cautious not to delay the whole project if all the tasks are critical task – allowing no room for adjustments, no flexibility

20 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management長條圖

21 Andrew Stellman & Jennifer Greene Applied Software Project Management 分配作業資源 and level resource 過渡使用資源案例

22 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management

23 Andrew Stellman & Jennifer Greene Applied Software Project Management This constraints make leveling resources impossible

24 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Leveling resources when leveling resources is impossible the only way is  get more labor resource  or change C = f (P,T,S) time critical leveling –fix time and let software find a possible leveling resource critical leveling –fix resource, allow time to be increased

25 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management

26 Andrew Stellman & Jennifer Greene Applied Software Project Management 資源有效性 (availability) 一般而言人的有效性不會超過 80 %  一天工作 8 小時大概只有 6 個小時真的有效  20 %花在 PDF P : personal 個性 F : fatigue 疲勞 D : delay 延遲,或等候下一步的訊息 80% 的有效性通常指作業員 研究顯示,腦力工作的人員比 50 %還低 了解參與專案人員的有效性十分重要,否則一 定會有大災難

27 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com27 Scheduling concepts: Effort vs. Duration Effort represents the work required to perform a task.  Effort is measured in person-hours (or person-days, person- weeks, etc.)  It represents the total number of hours that each person spent working on the task. Duration is amount of time that elapses between the time the task is started and the time it is completed.  Duration is measured in hours (or days, weeks, etc.)  It does not take into account the number of people performing the task

28 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com28 Scheduling concepts: Slack and Overhead Slack is the amount of time which any of the tasks can be delayed without causing the due date of the final task in the sequence to be delayed as well.  A tight schedule has very little slack; a delay in any task will cause a delay in the due date  Parkinson’s Law: “Work expands so as to fill the time available for its completion.” Overhead is any effort that does not go to the core activities of the task but is still required in order for the people to perform it— a sort of “real world” cost of actually doing the work.  Two people performing a task will require more effort than one person doing the same task  Assigning two people to the task requires more effort, but the task has a shorter duration

29 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com29 Building the project schedule Allocate resources  For each task in the WBS, one or more resources must be assigned  Choose person or people for each task based on qualifications, familiarity and availability  Take overhead into account when calculating the duration of each task

30 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com30 Building the project schedule Identify dependencies  A task has a dependency if it involves an activity, resource or work product which is subsequently required by another task  Tasks may have dependencies because they require the same resource

31 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com31 Building the project schedule Identify dependencies (continued)  Every dependency has a predecessor, or a task that must be begun, in progress, or completed, for another task to begin  Identify the type of predecessor for each dependency

32 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com32 Building the project schedule Create the schedule  Most project schedules are represented using a Gantt chart  The Gantt chart shows tasks, dependencies and milestones using different shapes

33 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com33 Building the project schedule Reconcile the schedule with the organization’s needs  Once resources are allocated to each task, a final date can be calculated  If this date is unacceptable, the project plan must change  Either additional resources must be allocated to the project or the scope must be cut down  Brooks’ Law: “Nine women cannot have a baby in one month.” In other words, some tasks can only be done by one person, no matter how critical they are.

34 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com34 Building the project schedule Add review meetings to the schedule  Progress reviews are meetings held regularly to check the progress of a project versus it's scheduled progress.  Milestone reviews are meetings which the project manager schedules in advance to coincide with project events. The most common way for project managers to handle milestone reviews is to schedule them to occur after the last task in a project phase (such as the end of design or programming).

35 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com35 Building the project schedule Step 4: Optimize the schedule  The critical path is the sequence of tasks that represent the minimum time required to complete the project. If a task is only on the critical path when delaying that task will delay the project. Allocating resources to tasks on the critical path will reduce the project schedule; allocating them to other tasks will have less effect.  A resource is over-allocated if more than 100% allocated to multiple tasks simultaneously If any resource is over-allocated, it means that there is a dependency between two tasks which was not discovered. When this happens, the schedule is guaranteed to be inaccurate. Find and fix over-allocated resources.

36 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com36 Don’t abuse buffers A buffer is a task added to the schedule with no specific purpose except to account for unexpected delays.  This practice involves either adding extra tasks or padding existing tasks at strategic points in the schedule where overruns are “expected”.  Buffers can be useful: On a year-long project, every programmer will take two weeks of vacation Buffers can be used to account for this known delay  Buffers are often abused The idea that overruns are expected means that there is an implicit assumption that the estimate is incorrect. Buffers should not be used to add time to compensate for an inaccurate estimate.

37 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com37 Project metrics The baseline is the version of the schedule that has been approved  The schedule will change based on the actual work done by the project team.  When the deadline of the revised schedule is later than that of the baseline, the project has slipped. Variance is the difference between the estimated effort in the baseline and the actual effort performed by the team.

38 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com38 Project metrics Earned value management tracks the project by considering effort “earned” against a budget only after it has actually been performed  The budgeted cost for work scheduled (BCWS) is the estimated effort of the actual tasks that appear on the schedule to date.  The actual cost of work performed (ACWP) is the effort spent on the tasks in the schedule that have actually been completed by the development team members.  Variance = BCWS – ACWP

39 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management http://www.stellman-greene.com39 Project metrics The cost performance index is used to compare projects with each other or to compare phases within a project  CPI is calculated by dividing BCWS / ACWP (budgeted cost for work scheduled/actual cost for work performed) and multiplying by 100 to express it as a percentage.  A CPI of 100% means that the estimated cost was exactly right and the project came in exactly on budget.  A CPI under 100%, the work cost less effort than planned; a CPI greater than 100% means that the estimate was not adequate for the work involved. For example, if the programming tasks took twice as long as estimated but every other type of task in the project took less time than estimated, the total variance for the project might still be low. However, the problem can still be pinpointed by calculating the CPI for each phase of development.

40 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Real Project Evaluation When a project is finished, it is important to evaluate the project If a schedule does not run as planned, the problem could be  Programmer’s skill does not meet the expectation  PM has problem in create and analyze a WBS which make schedule impossible to achieve  Some real technical difficulties do occurs http://www.stellman-greene.com40

41 Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Dig the truth and story As a higher-level PM, you just need to dig the story when a schedule does not work as planned. Be aware that it becomes a 批鬥大會 Some of these findings can be collected and improved in your next project. http://www.stellman-greene.com41


Download ppt "Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software."

Similar presentations


Ads by Google