Class #1


Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Class #1

  1. 1. Software Project Management Intro to Project Management INFO 638 Glenn Booker
  2. 2. Syllabus <ul><li>Course covers essential project management </li></ul><ul><ul><li>Traditional Project Management </li></ul></ul><ul><ul><li>Adaptive Project Framework </li></ul></ul><ul><li>Text complies with PMI ’s Project Management Body of Knowledge (PMBOK) </li></ul><ul><ul><li>We add software-specific concepts </li></ul></ul>
  3. 3. Syllabus <ul><li>Class focuses on application of project definition and management principles to a project of your choosing </li></ul><ul><li>Text is Wysocki’s Effective Project Management , 3e </li></ul>
  4. 4. My Background <ul><li>Systems Engineering approach </li></ul><ul><li>Mostly work with long-lived systems </li></ul><ul><li>Industry experience includes thirteen years of Dept. of Defense (DoD) work, and five for the FAA – mostly in large scale system design, development, and testing </li></ul>
  5. 5. References <ul><li>See web site </li></ul><ul><li>In particular, note the SEI, SPMN and STSC resources on the Reference Materials page </li></ul><ul><ul><li>The SEI document index is particularly recommended, and the SPMN identifies a lot of classic mistakes to avoid. </li></ul></ul>
  6. 6. Defining a Project <ul><li>A project is a series of complex, connected activities with a common purpose </li></ul><ul><ul><li>Our most common context is a project to develop or refine an information system, but most principles of project management apply to any project </li></ul></ul>
  7. 7. Activities = Sets of Tasks <ul><li>A key difference in project management is to start thinking of a project as a series of interrelated tasks which need to be accomplished </li></ul><ul><ul><li>Most other courses focus on how to perform a single complex task, such as developing an ERD, or designing a good interface – here we focus on defining the tasks needed to complete the project </li></ul></ul>
  8. 8. Project Limitations <ul><li>Projects also have limits on the amount of time and money available to them </li></ul><ul><ul><li>There may be changes to these limits negotiated, but there are always limits </li></ul></ul><ul><li>Projects need some form of specification to describe what needs to be accomplished </li></ul><ul><ul><li>Here, they are system requirements </li></ul></ul>
  9. 9. Program versus Project <ul><li>Often program and project are used interchangeably, but nominally, a program is a larger concept than a project </li></ul><ul><ul><li>A program is a set of related projects </li></ul></ul><ul><ul><ul><li>The Space Shuttle program consists of many flights which are each separately managed projects </li></ul></ul></ul><ul><ul><li>Here we focus mainly on projects </li></ul></ul>
  10. 10. Project Limits <ul><li>Projects are limited in scope, as defined by one of these: </li></ul><ul><ul><li>A functional specification </li></ul></ul><ul><ul><li>A Software Requirements Specification </li></ul></ul><ul><ul><li>Use cases and their documentation </li></ul></ul><ul><ul><li>A Statement of Work (SOW) </li></ul></ul><ul><ul><li>A Mission Needs Statement (MNS) (government term) </li></ul></ul>
  11. 11. Project Limits <ul><li>Projects are limited by their product quality and process quality requirements </li></ul><ul><ul><li>Cost – mostly the labor cost, but also hardware, software, training, etc. </li></ul></ul><ul><ul><li>Calendar time </li></ul></ul><ul><ul><li>And other resources – people, facilities, equipment, etc. </li></ul></ul>
  12. 12. The Triangle <ul><li>Projects generally get stuck facing a triangle </li></ul><ul><ul><li>Cost </li></ul></ul><ul><ul><li>Time (schedule) </li></ul></ul><ul><ul><li>Features and/or quality </li></ul></ul><ul><li>At most, two of these points can be controlled </li></ul><ul><ul><li>Which one can you tolerate flexibility? </li></ul></ul>
  13. 13. Project Classification <ul><li>Projects are often classified by their approximate size and complexity </li></ul><ul><ul><li>Risk, business value, duration, cost, etc. can be used to determine categories </li></ul></ul><ul><ul><li>The categories are often used to determine the extent of documentation needed (e.g. page 14), and may affect approval processes (bigger projects need higher level approval) </li></ul></ul>
  14. 14. Traditional Project Management <ul><li>Traditional Project Management (TPM) refers to commonly accepted management practices </li></ul><ul><li>In software development, it implies that some variation of the waterfall life cycle model is used </li></ul><ul><ul><li>DOD-STD-2167a (1988) is the classic description of the waterfall life cycle; others will be discussed with the WBS </li></ul></ul>
  15. 15. Traditional Project Management <ul><li>Also note that TPM is typically regarded as the most time consuming way to run a project </li></ul><ul><ul><li>In software, extreme programming (XP) and other agile methods have been developed to speed development for small, low risk projects </li></ul></ul>
  16. 16. TPM Life Cycle <ul><li>Wysocki has five major phases in the TPM life cycle </li></ul><ul><ul><li>Scope the project </li></ul></ul><ul><ul><li>Develop the project plan </li></ul></ul><ul><ul><li>Launch the plan </li></ul></ul><ul><ul><li>Monitor/control project progress </li></ul></ul><ul><ul><li>Close out the project </li></ul></ul>
  17. 17. Scope the project <ul><li>This phase includes: </li></ul><ul><ul><li>Define problems (with existing information system) and opportunities (for new features and/or use of new technologies) </li></ul></ul><ul><ul><li>Define project objectives in terms of business value – quantify improvements compared to current system </li></ul></ul><ul><ul><li>Identify project success criteria, risks, and constraints </li></ul></ul>
  18. 18. Develop the project plan <ul><li>Identify the project activities </li></ul><ul><ul><li>May divide activities into support activities (which are done throughout project) and specific life cycle phases (per the life cycle model chosen) </li></ul></ul><ul><ul><li>Estimate duration and resources for each activity </li></ul></ul><ul><ul><li>Create project schedule or network </li></ul></ul><ul><ul><li>Put all this into a project proposal </li></ul></ul>
  19. 19. Launch the plan <ul><li>Select and recruit project team members </li></ul><ul><li>Level resources needed across the plan </li></ul><ul><li>Schedule and document work packages </li></ul><ul><ul><li>A work package is the detailed set of tasks needed to perform a given activity </li></ul></ul>
  20. 20. Monitor/control project progress <ul><li>Determine how project progress will be measured </li></ul><ul><li>Establish change control tools and processes, including an escalation process </li></ul><ul><li>Monitor actual progress vs. the plan </li></ul><ul><li>Go back to “Develop the project plan” if major changes are needed </li></ul>
  21. 21. Close out the project <ul><li>When the project is completed </li></ul><ul><ul><li>Get customer approval of final product </li></ul></ul><ul><ul><li>Install final product </li></ul></ul><ul><ul><li>Deliver promised documentation </li></ul></ul><ul><ul><li>Make sure everything’s happy </li></ul></ul><ul><ul><li>Write up final project report </li></ul></ul>
  22. 22. Support Activities <ul><li>Ongoing activities throughout a project typically include </li></ul><ul><ul><li>Project management (or you don’t have a job!) </li></ul></ul><ul><ul><li>Quality management </li></ul></ul><ul><ul><li>Risk management </li></ul></ul><ul><ul><li>Procurement management </li></ul></ul>
  23. 23. Project Management <ul><li>Project management should include all five phases of the TPM life cycle </li></ul><ul><li>Many organizations omit one or more of the phases, most often the last ones, producing less-than-optimal results </li></ul>
  24. 24. Quality Management <ul><li>There are zillions of books on various aspects of quality management </li></ul><ul><li>Most focus on two major aspects </li></ul><ul><ul><li>Quality of the product you are creating </li></ul></ul><ul><ul><li>Quality or maturity of the processes you use to create that product </li></ul></ul><ul><ul><ul><li>Mature processes produce more consistent and predictable results </li></ul></ul></ul>
  25. 25. Quality Management <ul><li>There are many guides to quality – Six Sigma , CMMI , TQM , ISO 9000 , Malcolm Baldridge , etc. </li></ul><ul><li>Organizations with mature processes often use statistical process control methods to track quality and quantify improvements </li></ul>
  26. 26. Risk Management <ul><li>Deliberate management of risks is critical to good project management </li></ul><ul><li>American culture would rather shoot the messenger than deal with risks openly – this has to change </li></ul><ul><li>Risks include any event, which hasn’t happened yet, which could delay the successful completion of a project </li></ul>
  27. 27. Risk Management Guide <ul><li>Need to create a list of possible risks </li></ul><ul><li>Describe each risk briefly </li></ul><ul><li>Estimate the probability of the risk happening </li></ul><ul><ul><li>Should be between 0 and 100% </li></ul></ul><ul><li>Estimate the loss if the risk occurs </li></ul><ul><ul><li>How much effort will it take to recover from the risk? </li></ul></ul>
  28. 28. Risk Management Guide <ul><li>Multiply probability times loss to get the impact of each risk </li></ul><ul><ul><li>Impact = probability * loss </li></ul></ul><ul><li>Sort risks in descending order of impact; keep the top 10 (typically) </li></ul><ul><ul><li>This is prioritizing the risks </li></ul></ul><ul><li>For each significant risk, assign a risk owner to look for the risk occurring </li></ul>
  29. 29. Risk Management Guide <ul><li>Quantify what has to occur for the risk to have happened (detection) </li></ul><ul><ul><li>“If we are more than 10% over budget, the risk for Exceed Budget has occurred” </li></ul></ul><ul><ul><li>Must quantify each risk, or they’ll never occur </li></ul></ul><ul><li>Determine how to prevent the risk, if possible, or look for alternative approaches to make the risk go away </li></ul>
  30. 30. Risk Management Guide <ul><li>Plan a mitigation strategy to reduce the risk’s impact on your project </li></ul><ul><li>Once the project starts, keep reviewing the risks (e.g. weekly) to see if any risks have occurred, or if new risks have been identified </li></ul>
  31. 31. Risk Management = Security <ul><li>Risk management looks like security analysis, such as for an airline </li></ul><ul><ul><li>Prevent a risk from happening (e.g. a hijacker getting onboard) </li></ul></ul><ul><ul><li>Detect when the risk has occurred (they make their presence known) </li></ul></ul><ul><ul><li>Mitigate the damage they can do (get the plane on the ground safely) </li></ul></ul>
  32. 32. Procurement Management <ul><li>All information systems involve some commercial hardware, software, and networking equipment </li></ul><ul><ul><li>Selection and procurement of these components is a key activity </li></ul></ul><ul><li>Start with the buy-versus-make decision </li></ul><ul><ul><li>For each system component, will you make it yourself, or buy something off-the-shelf? </li></ul></ul>
  33. 33. Procurement Management <ul><li>Procurement has its own life cycle, which runs parallel to part or all of the project life cycle </li></ul><ul><ul><li>Solicit RFI (optional; and not in text) </li></ul></ul><ul><ul><li>Solicit RFPs </li></ul></ul><ul><ul><li>Get responses </li></ul></ul><ul><ul><li>Select Vendors </li></ul></ul><ul><ul><li>Manage contracts </li></ul></ul><ul><ul><li>Close out contracts </li></ul></ul>
  34. 34. Solicit RFI <ul><li>If you want to create a shorter list of candidate vendors, a Request For Information (RFI) can be used </li></ul><ul><ul><li>The RFI is a tool to screen out poorly qualified candidate vendors </li></ul></ul><ul><ul><li>An RFI mainly seeks proof that they understand the type of requirements to be addressed, and have suitable relevant experience </li></ul></ul>
  35. 35. Solicit RFPs <ul><li>A Request For Proposal (RFP) is used to get proposals from candidate vendors </li></ul><ul><ul><li> posts RFPs for government work over $25,000 </li></ul></ul><ul><li>The RFP states your requirements; each candidate vendor decides how to meet your needs </li></ul>
  36. 36. Get responses <ul><li>Candidate vendors may ask questions to clarify the RFP; answers are made available to all vendors </li></ul><ul><li>Vendors prepare a proposal to respond to the RFP </li></ul><ul><li>RFPs often have very strict time deadlines (30-90 days) and specific page and format limits </li></ul>
  37. 37. Select Vendors <ul><li>A proposal often has different volumes, e.g. Business, Technical, Cost, etc. which are reviewed by different experts </li></ul><ul><ul><li>Each volume is scored or rated according to guidance (grading criteria) stated in the RFP </li></ul></ul><ul><ul><li>The proposal with the highest score generally wins </li></ul></ul>
  38. 38. Manage contracts <ul><li>Once the vendor is selected, contract personnel write the details of the contract </li></ul><ul><ul><li>The contract specifies what will be delivered, when, where, and often in what format </li></ul></ul><ul><ul><li>A Statement of Work details the require-ments to be fulfilled by the vendor </li></ul></ul><ul><ul><li>The schedule for payments to the vendor is also stated </li></ul></ul>
  39. 39. Close out contracts <ul><li>When the final deliverable products and/or services are provided by the vendor, the contract is closed out </li></ul><ul><ul><li>The contract generally specifies what happens to equipment, informal documentation, and other work products resulting from the contract </li></ul></ul><ul><ul><li>Final payment is made to the vendor </li></ul></ul>