Your SlideShare is downloading. ×

Class #1

332

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
332
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×