1 / 58

Software Project Management

Software Project Management. Review INFO 638 Glenn Booker. 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)

ken
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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related