software project management n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Software Project Management PowerPoint Presentation
Download Presentation
Software Project Management

Loading in 2 Seconds...

play fullscreen
1 / 58
ulric-chen

Software Project Management - PowerPoint PPT Presentation

92 Views
Download Presentation
Software Project Management
An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Software Project Management Review INFO 638 Glenn Booker Lecture #10

  2. Project Limits • Projects are limited in scope, as defined by one of these: • A functional specification • A Software Requirements Specification • Use cases and their documentation • A Statement of Work (SOW) • A Mission Needs Statement (MNS) (government term) Lecture #10

  3. The Triangle • Projects generally get stuck facing a triangle • Cost • Time (schedule) • Features and/or quality • At most, two of these points can be controlled • Which one can you tolerate flexibility? Lecture #10

  4. TPM Life Cycle • Wysocki has five major phases in the TPM life cycle • Scope the project • Develop the project plan • Launch the plan • Monitor/control project progress • Close out the project Lecture #10

  5. Risk Management Guide • Need to create a list of possible risks • Describe each risk briefly • Estimate the probability of the risk happening • Should be between 0 and 100% • Estimate the loss if the risk occurs • How much effort will it take to recover from the risk? Lecture #10

  6. Risk Management Guide • Multiply probability times loss to get the impact of each risk • Impact = probability * loss • Sort risks in descending order of impact; keep the top 10 (typically) • This is prioritizing the risks • For each significant risk, assign a risk owner to look for the risk occurring Lecture #10

  7. Procurement Management • Procurement has its own life cycle, which runs parallel to part or all of the project life cycle • Solicit RFI (optional; and not in text) • Solicit RFPs • Get responses • Select Vendors • Manage contracts • Close out contracts Lecture #10

  8. Role of the POS • The POS is a communications tool among the project manager, their development team, the customer, and the project manager’s boss (upper or senior management) • The POS is a concise statement of the project, and a summary of its justification to continue Lecture #10

  9. Parts of a POS • The POS has five major sections • Problem/opportunity • Goal • Objectives • Success criteria • Assumptions, risks, obstacles • Each is typically a few paragraphs long Lecture #10

  10. Work Breakdown Structure (WBS) • The WBS gives structure to the set of activities in a project • It expands on the POS by describing activities in more and more detail, until you get down to the smallest level of task you need to define for your project • The WBS is a really big ‘to-do’ list Lecture #10

  11. WBS Approaches • There are three major approaches to structuring a WBS • Noun-type approaches (subsystems) • Verb-type approaches (life cycle phases) • Organizational approaches (who or where performs work) Lecture #10

  12. WBS Numbering • Tasks and activities are often given unique identification numbers to help do cost accounting and generate status summaries • In Microsoft Project, you can add a column called WBS which will automatically follow this numbering Lecture #10

  13. After the WBS • Once the rough scope of tasks has been defined in the WBS, we need to estimate each task in terms of duration and effort • From effort we’ll get the cost of each task, and eventually the project • After estimation, can start to organize the project schedule Lecture #10

  14. Creating a Good Estimate • There are six techniques for estimating the duration and effort of a task • Similar activities • Historical data • Expert advice • Delphi technique • Three-point technique • Wide-band Delphi technique Lecture #10

  15. Estimating Resources • While ‘resources’ often refers to people on a project, it may refer to • People • Facilities • Equipment • Money • Materials Lecture #10

  16. Organization Chart • Since we need to define the types of staff needed to perform each task, this feeds into developing the organization chart of the project • The roles needed for performing tasks should all appear on the org chart • It’s called a Resource Breakdown Structure in the text (p. 108) Lecture #10

  17. Project Network Diagram • Can present the project schedule in three major forms • Gantt chart, showing bars for each task under a timeline • Pert chart, with activity on arrow (AOA) notation • CPM chart, with activity on node (AON) notation • The latter two can show critical path Lecture #10

  18. Critical Path • A key output is the critical path, which can be defined as • The longest duration path in the network diagram, or • The series of tasks whose early and late schedules are the same dates, or • The set of activities with zero slack Lecture #10

  19. Management Reserve • At the project level, try to keep a little reserve of time (padding) to allow for likely schedule slips • Don’t do this on individual tasks – tends to bloat the schedule • 5-10% is a good schedule reserve • So a 6-month project might try to finish 6-13 work days early • 6 months = 26 weeks = 130 work days Lecture #10

  20. Leveling Resources • Then need to add up the planned resources and look for potential problems • Over committing people • Resources inconsistent with project priorities • Lack of management to monitor the project resources • Lack of accounting for employee turnover Lecture #10

  21. Work Packages • Earlier we defined a project as having activities, which are broken into tasks • A way to describe and manage the tasks within an activity are work packages • The work package describes the tasks to be accomplished, relevant dates, and who will do the work Lecture #10

  22. Critical chain vs. critical path • The critical path is the longest duration through the project • Doesn’t consider the resources needed for tasks along the critical path • Critical chain is the longest path through the project, considering both task dependencies and resource constraints Lecture #10

  23. Joint Project Planning • Joint Project Planning (JPP) uses a goldfish-bowl approach to conducting early analysis of a project • Its scope is typically to define the POS and/or PDS • For software, this might include defining the system scope and key requirements, and/or developing high level system design Lecture #10

  24. JPP • All significant stakeholders in a project need to attend JPP • JPP sessions are typically held off-site to avoid distractions • JPP follows a specific agenda to reach specific goals for the session, e.g. develop a POS, describe the WBS, etc. Lecture #10

  25. Monitoring Progress • By now you have been able to create a detailed project plan, including task definitions, estimates of duration, & assignment and leveling of resources • Then the project actually starts • Now you need to monitor what really happens, and control the future of the project Lecture #10

  26. Control and Risk • Controlling a project is closely linked to risk management • You want to minimize the risk that the project won’t finish successfully • Successfully generally means “on time and within budget” • To do so, you need measurements to help decide if the project is on track Lecture #10

  27. Controls • Without good controls, a project will wander like a 6-year-old on summer vacation • Controls allow us to • Track progress – what has been accomplished? • Detect variance – have we departed from the plan? • Take corrective action – fix it! Lecture #10

  28. Progress Reporting System • Some form of progress reporting system needs to be established • Want timely, complete, clear, and accurate status reported • Avoid adding too much to overhead to create the status reports • Results are readily available • Warns of problems with time to fix them Lecture #10

  29. Variances • Variances are the difference between actual events and the project plan • Positive variances are often good • They mean you are ahead of schedule or under budget • But could mean the schedule has slipped, and little has been accomplished Lecture #10

  30. Displaying Status • There are three major ways to display the status of a project graphically • Gantt chart • Milestone trend chart • Cost schedule control chart Lecture #10

  31. Cost Schedule Control • Cost schedule control refers to the system used by the many agencies called earned value or C/SCSC • We have already defined a project plan with tasks and resources • Each task therefore has some defined dollar value (its resources times their hourly rate) Lecture #10

  32. Cost Schedule Control • To use Cost Schedule Control, we need to define when we get ‘credit’ for accomplishing each task • Only when the task is done • Half at the task start, and half at finish • Etc. • The total planned value of work done on the project typically forms a long S curve over time Lecture #10

  33. Change Control • A change control process is needed to manage changes to the scope of a project • Describes the activities needed to analyze a problem, estimate how much work it is to resolve, determine its priority, fix it, and incorporate it into a system change with other problem fixes • The names of the organizations which perform each of the steps may vary Lecture #10

  34. Escalation • Escalation here means how a problem can be resolved • Little problems might be resolved by the project manager • Bigger problems might be resolved by getting additional resources from your organization • Huge problems might need cooperation from your customer to resolve Lecture #10

  35. Motivation • Key for a good manager to recognize is that different things motivate different people • And what motivates one person might change over time • One person might be thrilled to get an award for their contribution to a project, another might prefer a check, and a third might want an extra two days vacation Lecture #10

  36. Motivation • The big motivational factors for most people are: • Opportunity for achievement • Opportunity for advancement • Might include technical supervision • Recognition • Increased responsibility • The work itself Lecture #10

  37. Management and Motivation • Many of the motivational factors can’t be controlled by a first line manager • Key for managers to focus on are • Provide challenging work • Recognize your people’s work • Design their job to provide a variety of skills needed, clearly identifiable and significant tasks, allow autonomy, and provide feedback Lecture #10

  38. Contract Issues • Many management issues involve contractual concerns • A good resource with more detail is • On Time Within Budget, E.M. Bennatan, 3rd ed., ISBN 0-471-37644-2, Wiley, 2000. • The key contractual vehicles are RFI, RFP, and RFQ • For zillions of examples, go to www.firstgov.gov and search on those acronyms Lecture #10

  39. Contract Terms • The terms of payment are clearly defined in any contract • Often payments are based on meeting specific milestones in the project • Rules for handling contract early termination, and normal closeout of the contract are also defined Lecture #10

  40. Team Rules • Any team needs some rules to function effectively • How will decisions be made? • How do you solve problems? • How do you resolve conflicts? • How & when does the team meet? • How does the team interact with other projects? The customer? • Who defines the answers to these? Lecture #10

  41. Closeout • Normal closeout of a project typically involves six steps • Get client acceptance • Ensure system installed • Ensure documentation delivered • Get client signoff • Post-implementation Audit • Party! Lecture #10

  42. Adaptive Project Framework • Adaptive Project Framework (APF) uses selected portions of traditional project management (TPM) • Focus is on planning just-in-time, rather than planning the entire project from the start • APF is client-focused, and expects constant change Lecture #10

  43. APF Structure • APF uses five phases • Version Scope • Cycle Plan • Cycle Build • Client Checkpoint • Post-Version Review • Planning is based on functionality, and is kept high level until each cycle Lecture #10

  44. APF Core Values • APF is based on six core values, which help define how APF thinks • Client-focused • Client-driven • Incremental results • Continuous questioning • Change is progress • Don’t speculate Lecture #10

  45. Version Scope • This phase sets the stage for the project • Prepare the POS, much like done in TPM • Define the vision of what the product will be • Define the overall budget and schedule (timebox) of the project • Define the WBS to the 2nd or 3rd level Lecture #10

  46. Number of Cycles • Once we have a handle on the project objectives and scope, need to establish the preliminary number of time boxes, and how long they are • Try fixed duration for all time boxes; may tweak later • Might use development time of the most complex cycle to set the time box size • Consider client attention span too Lecture #10

  47. Cycle Objectives • Finally, prepare objective statements for the first few cycles • Tell customer what they should expect from each cycle (deliverables) • Keep focus on business functions and value to the customer Lecture #10

  48. Cycle Planning • Cycle planning is performed like in traditional project management (TPM), but there are key differences • In APF, the planning is done in detail only for the next cycle – not the entire project at once • APF planning may or may not use project software; it could be done with more informal tools Lecture #10

  49. Cycle Build • It is assumed that Cycle Plan is done by one person or part of the team • Cycle Build requires the whole team’s presence to refine the schedule if needed • Identify specific resources for each task, and ensure conflicts are resolved and workload is balanced Lecture #10

  50. Build Cycle Functionality • Start building the functionality promised for this cycle, following the plan just developed • During the cycle, daily stand-up meetings are used for status • Stand up so it doesn’t drag on forever • Monitor the system scope & their priorities, and issues identified Lecture #10