Your SlideShare is downloading. ×
0
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Project Management
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Project Management

294

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
294
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
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
  • Sources of Risk In identifying the sources of project risk , you can first include all of the sources of uncertainty mentioned earlier in this chapter, such as misapprehension of scope and changes in requirements. Some of these can’t properly be laid to rest until they are actually attempted, but crucial parts can be attacked early on. For example, with persistent communication, the core of the customer’s scope expectations can be discerned at this point. The figure lists several sources of risk. One of these is tools such as design automation. Tool vendors can go out of business, discontinue support for the tool versions etc. (Indeed, this is one reason that computer-aided software engineering tools did not catch on in the 1980’s.) The mobility of software personnel is another source of risk.
  • Transcript

    • 1. PROJECT MANAGEMENT (Pass 1) GA Tech CS 3300 AY 2002 Spring 2002
    • 2. Software Engineering Roadmap: Development process - when to do what phase - document Management structure - hierarchical, peer,... Risk identification & retirement Plan project Integrate & test system Analyze requirements Design Maintain Test units Implement Corporate practices Development phases Schedule Cost estimate SPMP Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 3. Learning Goals
      • Understand the term “project management”
      • Organize teams
      • Specify project management plans
      • Define and retire risks
      • Estimate costs very early in the life cycle
      • Create high level projects schedules
      • Write a Software Project Management Plan
      Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 4. The Variables of Project Management
      • Can somewhat vary the following factors.
      • 1. The total cost of the project,
        • e.g., increase expenditures
      • 2. The capabilities of the product,
        • e.g., subtract from a list of features
      • 3. The quality of the product,
        • e.g., increase the mean time between failure
      • 4. The date on which the job is completed.
        • e.g., reduce the schedule by 20%
        • e.g., postpone project's completion date one month
      Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 5. Bullseye Figure for Project Variables cost capability duration defect density Target : $70K Target : 30 wks Target : 4 defects/Kloc Target : 100% Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 6. Bullseye Figure for Project Variables cost capability duration defect density Target : $70K Actual : 100% Target : 30 wks Target : 4 defects/Kloc this project Actual : 1 defect/Kloc Actual : 20 wks Actual : $90K Target : 100% Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 7. RoadMap for Project Management 1. Understand project content, scope, & time frame 2. Identify development process ( methods, tools, languages, documentation and support ) -- section 4 of chapter 1 3. Determine organizational structure (organizational elements involved) -- see section 3 4. Identify managerial process (responsibilities of the participants) - - see section 3 of case study 1 at end of chapter 6. Develop staffing plan -- see section 3.5 of case study 1 5. Develop schedule ( times at which the work portions are to be performed ) -- see section 6 7. Begin risk management -- see section 4 8. Identify documents to be produced -- see SQAP 4.2 9. Begin process itself -- described in chapters 3-10 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 8.
      • 1.* Distribute start time, end time, and agenda with approximate times
        • list important items first
      • 2.* Ensure “strawman” items prepared
      • 3. Start on time
      • 4. Have someone record action items ‡
      • 5. Have someone track time & prompt members
      • 6. Get agreement on the agenda and timing
      • 7. Watch timing throughout, and end on time
        • allow exceptions for important discussion
        • stop excessive discussion; take off line
      • 8. Keep discussion on the subject
      • 9.** E-mail action items & decision summary.
      Plan and Execute Meetings One way to ... * in advance of meeting ‡ actions members must perform ** after meeting Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 9. Specify Agendas
      • 1. Get agreement on agenda & time allocation
      • 2. Get volunteers to … :
        • … record decisions taken and action items
        • … watch time and prompt members (see figure tbd)
      • 3. Report progress on project schedule -- 10 mins
      • 4. Discuss strawman artifact(s) -- x mins
      • 5. Discuss risk retirement -- 10 mins
      • <MORE ITEMS>
        • metrics and process improvement?
      • n. Review action items -- 5 mins
      One way to ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 10. Optimal Size for Interaction (Approximate) Number of people with whom developer must frequently interact Developer communicates regularly with eleven people. Communication time outweighs benefits of interaction Developer communicates regularly with no one. No communication time lost, but developer is too isolated and has no help. Key: = engineer Approximate optimal range 3 7 Effectiveness per developer Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 11. Hierarchical Project Management Organizations Larger Projects: Smaller Projects: No separate Marketing? No separate QA organization?
      • Subdivide QA into testing, …?
      • Subdivide Engineering into
        • system engineering, …?
      Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 12. Gaming Industries Consolidated President VP Engineering VP Marketing . . . IV&V Encounter Game 123 . . . SQA Game Lab . . . Software Engineering Labs Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 13. Horizontal Project Management Organizations Gil Warner Team leader Ian Corliss Team member Nel Tremont Team member Fran Smith Team member Team facilitator? Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 14. Organize a Team
      • 1. Select team leader: responsibilities:
        • ensure all project aspects active
        • fill all gaps
      • 3. Designate leader roles & document responsibilities
        • team leader: proposes and maintains… SPMP
        • configuration management leader: ... SCMP
        • quality assurance leader: ... SQAP, STP
        • requirements management leader: ... SRS
        • design leader: ... SDD
        • implementation leader: ... code base
      • 2. Leaders’ responsibilities:
        • propose a strawman artifact (e.g. SRS, design)
        • seek team enhancement & acceptance
        • ensure designated artifact maintained & observed
        • maintain corresponding metrics if applicable
      • 4. Designate a backup for each leader as per
      One way to ... One way to ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 15. Peer Organizations for Larger Projects Team of leaders Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 16. Table 2.1 Matrixed organization    Table 2.1 Matrixed organization   Project Airline reserv. project Bank accountg. project Molecular analysis project Fluid mechanics project Func- tional Unit Project manage-ment dpt Al Pruitt Full time Quinn Parker Half time Ruth Pella Full time Fred Parsons Full time Marketing dpt Oscar Mart Full time Pete Merrill Full time Sue More Half time Elton Marston Full time Engineer-ing dpt Hal Egberts ...... Ben Ehrlich ...... Mary Ericson ..... Len Engels .....
    • 17. Table 2.11 Encounter Staffing Plan Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Name Team Leader CM Leader. QA Leader Requ. Mngmnt Leader Design Leader Implemen- tation Leader Ed Braun X         X Al Pruitt   X         Fern Tryfill     X       Hal Furnass       X     Karen Peters         X   Liaison with VP Eng.     Marketing Soft. Eng. Lab  
    • 18. Program Monitoring & Control Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 19. The Four Risk Activities
      • (1) Identification
      • Mindset: try to continually identify risks
      • (2) Retirement planning
      • (3) Prioritization
      • (4) Retirement or mitigation
      Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 20. Risk Sources Ordered by Importance ( Keil, Cule, Lyytinen, Schmidt)
      • 1. Lack of top management commitment
      • 2. Failure to gain user commitment
      • 3. Misunderstanding of requirements
      • 4. Inadequate user involvement
      • 5. Failure to manage end-user expectations
      • 6. Changing scope and/or objectives
      • 7. ….
    • 21. The Risk Management Mindset Project finish Project start Identification Retirement 2. “Java skills not high enough.” 1. “May not be possible to superimpose images adequately.” 1. Retirement by conquest: Demonstrate image super- imposition Risk 1 Risk 2 Risk 1 Project finish Risk 2 2. Retirement by avoidance: Use C++ Project start Graphics reproduced with permission from Corel. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 22. Table 2.2 A way to compute risk priorities Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.   Likelihood 1-10   1 = least likely Impact 1-10   1 = least impact Retire-ment cost 1-10 1 = lowest retirement cost Priority computation Resulting priority   Lowest number handled first The highest priority risk 10 (most likely) 10 (most impact) 1 (lowest retirement cost) (11- 10 ) *(11- 10 ) * 1 1 The lowest priority risk 1 (least likely) 1 (least impact) 10 (highest retirement cost) (11- 1 ) *(11- 1 ) * 10 1000
    • 23. Table 2.3  Sample Risk Analysis for Encounter Case Study Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. #  Risk title (details given above) Like-lihood 1-10   1=least likely Im-pact 1-10   1=least impact Retire-ment cost 1-10 1=lowest retirement cost Pri-ority   lowest number handled first Retirement / mitigation plan Respon-sible engineer Target com-pletion date                   1 Super-imposing images 3 10 1 8 Experiment with Java images. P. R. 2/1/99   2 Deficient Java skills 9 6 8 80 H.T., K.M., V.I. and L.D. to attend training course beginning 1/5/99 at Ultra Training Corp, obtain Java level 2 certification by 3/1/99 and level 3 certification by 4/15/99 H. L. 4/15/99 3 Alan Gray may be pulled off this project 3 7 9 288 Susan Ferris to inspect all of Alan's work S.F. Contin-ual .. ... ... ... ... ... ... ... ...
    • 24. Identify and Retire Risks
      • 1.* Each team member spends 10 mins. exploring his or her greatest fears for the project’s success
      • 2.* Each member specifies these risks in concrete language, weights them, writes retirement plans, (see format above) & e-mails to the team leader
      • 3.* Team leader integrates and prioritizes results
      • 4. M Group spends 10 mins. seeking additional risks
      • 5. M Team spends 10 mins. finalizing the risk table
        • Designates responsible risk retirement engineers
      • 6.** Responsible engineers do risk retirement work
      • 7. M Team reviews risks for 10 mins. at weekly meetings
        • responsible engineers report progress
        • team discusses newly perceived risks and adds them
      *:in advance of first meeting M : at meeting **: between meetings One way to ...
    • 25. Table 2.4 Example of method for deciding language choice Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Factor Weight  (1-10) Benefit of Language 1 1 to 10=best Benefit of Language 2 1 to 10=best Internet-friendly 3 8 2 Familiarity to development team 8 3 9 Compilation speed 5 2 8 Runtime speed on processor p 1 7 3 Score   3 *8 + 8 *3 + 5 *2 + 1 *7 = 65 3 *2 + 8 *9 + 5 *8 + 1 *3 = 121
    • 26. Create an Initial Schedule
      • 1. Indicate the milestones your must observe
        • usually includes delivery date
      • 2. Back these up to introduce the milestones you need
        • e.g., begin system testing well before delivery
      • 3. Designate a time at which all requirements frozen
      • The remaining steps depend on the process used. We will assume an iterative process.
      • 4. Show first iteration: establishes minimal capability
        • usually: keep it very modest, even trivial, in capability
        • benefit: exercises the development process itself
      • 5. Show task of identifying & retiring risks
        • starting from project inception
      • 6. Show unassigned time (e.g., week) near middle?
      • 7. Complete the schedule
      One way to ... Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 27. High Level Task Chart with Fixed Delivery Date: Order of Completion Month 1 1 2 3 4 Month 2 1 2 3 4 Month 3 1 2 3 4 Month 4 1 2 3 4 Month 5 1 2 3 4 Milestones (1 * ) Delivery Begin system testing Iteration 1 Iteration 2 (6) (4) (3) Freeze requirements Risk identification & retirement (5) * Indicated the order in which the parts of this table were built SCMP complete SQAP complete SPMP rel. 1 complete (2) Prep. for maintenance Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 28. Work Breakdown Structure Excluding Secretarial Month 1 1 2 3 4 Month 2 1 2 3 4 Month 3 1 2 3 4 Month 4 1 2 3 4 Month 5 1 2 3 4 Milestones Delivery Complete testing Iteration 1 Iteration 2 Freeze requirements Risk I&R SCMP SQAP SPMP rel. 1 E. Braude 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 J. Pruitt 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 F. Tryfill 1 1 1 1 1 1 1 1 1 1 1 1 1 H. Furnass 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 K. Peters 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Tasks TOTAL 5.5 5.5 5.5 5.5 5.5 5.5 5.5 5.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 4.5 3.5 3.5 F. Smith (tech support) .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 .5 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 29. Level Labor Allocation for Fixed Labor Total Month 1 1 2 3 4 Month 2 1 2 3 4 Month 3 1 2 3 4 Month 4 1 2 3 4 Month 5 1 2 3 4 Milestones Release to production Complete testing Iteration 1 Iteration 2 Freeze requirements Risk ID & retire 2 2 2 3 2 2 3 2 2 2 1 1 1 4 4 4 3 3 4 4 4 4 4 4 3 3 4 4 4 4 3 3 4 4 4 4 4 4 4 4 4 4 4 4 4 Given team size: To be assigned 4 Hal vacation Karen vacation Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
    • 30. Summary
      • Project management: “silver bullet”?
      • “ People” aspects co-equal technical
      • Specify SPMP
      • Define and retire risks
      • Estimate costs with several methods
        • expect to revisit and refine
        • use ranges at this stage
      • Schedule project with appropriate detail
      • Maintain a balance among cost, schedule, quality and functionality
      Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Graphics reproduced with permission from Corel.

    ×