Software Project Management Intro to Project Management INFO 638 Glenn Booker INFO 638 Lecture #1 Syllabus  Course covers essential project management  Traditional Project Management  Adaptive Project Framework 

Download Report

Transcript Software Project Management Intro to Project Management INFO 638 Glenn Booker INFO 638 Lecture #1 Syllabus  Course covers essential project management  Traditional Project Management  Adaptive Project Framework 

Software Project Management

Intro to Project Management INFO 638 INFO 638 Glenn Booker Lecture #1 1

Syllabus

 

Course covers essential project management

  Traditional Project Management Adaptive Project Framework

Text complies with (PMBOK) PMI ’s Project Management Body of Knowledge

 We add software-specific concepts INFO 638 Lecture #1 2

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 INFO 638 Lecture #1 3

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 INFO 638 Lecture #1 4

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.

INFO 638 Lecture #1 5

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 INFO 638 Lecture #1 6

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 INFO 638 Lecture #1 7

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 INFO 638 Lecture #1 8

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 INFO 638 Lecture #1 9

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) INFO 638 Lecture #1 10

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.

INFO 638 Lecture #1 11

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?

INFO 638 Lecture #1 12

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) INFO 638 Lecture #1 13

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 INFO 638 Lecture #1 14

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 small, low risk projects have been developed to speed development for INFO 638 Lecture #1 15

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 INFO 638 Lecture #1 16

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 INFO 638 Lecture #1 17

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 INFO 638 Lecture #1 18

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 INFO 638 Lecture #1 19

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 INFO 638 Lecture #1 20

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 INFO 638 Lecture #1 21

Support Activities

 Ongoing activities throughout a project typically include  Project management (or you don’t have a job!)   Quality management Risk management  Procurement management INFO 638 Lecture #1 22

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 INFO 638 Lecture #1 23

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 INFO 638 Lecture #1 24

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 INFO 638 Lecture #1 25

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 INFO 638 Lecture #1 26

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?

INFO 638 Lecture #1 27

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 INFO 638 Lecture #1 28

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 INFO 638 Lecture #1 29

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 INFO 638 Lecture #1 30

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) INFO 638 Lecture #1 31

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?

INFO 638 Lecture #1 32

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 INFO 638 Lecture #1 33

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 INFO 638 Lecture #1 34

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 INFO 638 Lecture #1 35

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 INFO 638 Lecture #1 36

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 INFO 638 Lecture #1 37

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 INFO 638 Lecture #1 38

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 INFO 638 Lecture #1 39