Your SlideShare is downloading. ×
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software Project Management
Software 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

Software Project Management

365

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
365
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
17
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 CS6704: Class 2 Instructor: Shawn A. Bohner Voice: (703) 538-8374 Email: sbohner @vt.edu Teaching Assistant: Yunxian Zhou Email: yxzhou@nvc.cs.vt.edu Voice: (703) 538-8381 © 2001 Shawn A. Bohner Agenda u Review Last Week’s Material l Turn in Homework l Reading Discussion l Project Plans Discussion l Review last weeks class u Chapter 1: What Makes a Good Software Manager? u Chapter 2: Four Basics that Work l Break u Software Process Management u Homework Assignment 2 1
  • 2. Fall Semester Timeline Class Begins Emerging PM Managing with PM Basics Paradigms Metrics Software Mid- Mid-Term Program Final Exam Project Exam Management Planning Aug Sept Oct Nov DEC Software Human Side Estimation of PM Risk Software Project Management Process and Portfolio Life Cycle Management 16 weeks, 13 sessions… So much to do & so little time … manage your time effectively! 3 Discussions… u Reading Discussion l What was the main idea of the paper? l Does software projects differ from other projects? If so, how? l Do you do these things in your projects? l What parts of these can be automated? u Software Project Plans Discussion l Where did you find software plan examples? l What did the software plans contain? l Was it what you expected? What was different or missing? l What there enough information in the plans to support the management decisions for projects you have seen? 4 2
  • 3. So, why is e-Engineering a project management problem? u Large, complex, distributed systems l CPU speed, memory, bandwidth l Things we’re taught to ignore u Heterogeneous platform architectures l Mainframe, desktop, laptop, palmtop … l CORBA, VXML, EJB, … languages u Mobility (Several 2000/1 IEEE Computer Issues) l One application runs on many devices across varied communications l Each device has varied resource profiles u Modeling, analysis, simulation… l Collaborative design on partial information u Development teams across the globe l Around the clock development l Decentralized ownership and control 5 Why Are Projects Late? u Unrealistic deadline established by someone outside the software development group u Changing customer requirements that are not reflected in schedule changes u Honest underestimate of the amount of effort and/or the number of resources that will be required to do the job u Predictable and/or unpredictable risks that were not considered when the project started u Technical difficulties that could not have been foreseen in advance u Human difficulties that could not have been foreseen in advance u Miscommunication among project staff that results in delays u Failure by project management to recognize that the project is falling behind schedule and a lack of action to correct the problem Which of these are unique to Software Projects? 6 3
  • 4. So, what did Capers Jones tell us here? Early On-Time Delayed Canceled Sum 1 FP 14.68% 83.16% 1.92% 0.25% 100.00% 10FP 11.08% 81.25% 5.67% 2.00% 100.00% 100FP 6.06% 74.77% 11.83% 7.33% 100.00% 1000FP 1.24% 60.76% 17.67% 20.33% 100.00% 10,000FP 0.14% 28.03% 23.83% 48.00% 100.00% 100,000FP 0.00% 13.67% 21.33% 65.00% 100.00% Average 5.53% 56.94% 13.71% 23.82% 100.00% From Capers Jones, Patterns of Software Systems Failure and Success (International Thomson Computer Press, 1996) 7 Semi-Formal Definition u Management – The activities undertaken by ??? to plan and control activities of others to ???. u Project Management – “… a ??? of procedures, practices, technologies, and know-how that provide the ?, ??, ???, ????, and ????? necessary to successfully manage an engineering project.” [Thayer 1987] 8 4
  • 5. Classic Management Activities ? ? Pll Pla g an an tin nn niin ni ec Dir gg Software Project Org fing aniz Staf ing ? ? Controlling ? 9 Prog. Mngt. Capability Maturity Model Maturity Key Process Area Strategic Effective Level Concentrations Inflection Span Point Result Value Management, Integration Enterprise/ 5 Business Continuity Planning, with Business Industry Value Procurement Management, Incorporated Outsourcing and Contract Manage- ment, PM Center of Excellence Program Process Management, Dynamic Multiple Project Integration Management, Micro-Level Business Project Performance Management, Change Units 4 Vendor Management, PM Career Path, Staff Performance Management, Managed Customer Relationship Management, Contingency Management, Communications Management PM Methodology, Skill Management, Static Macro- Multiple PM Training, Risk Management, Level Change Project 3 Change Management, Defined Staff Resource Management, Environment Resource Management, Conflict/Issue Management Planning, Estimation, Stabilize Single Tracking, Risk Identification, Performance Project 2 Schedule Management, Stable Budget/Cost Management, Scope Mgmt., Progress Reporting 1 - Initial Acquiring New PMs Risk 10 5
  • 6. What do PMs Manage? Software! u Software is part of a computer system that is ??? u Business changes and its computer systems must respond u Software is ???, not manufactured u Software is intangible u Software is complex Software is suppose to change… otherwise it would in the hardware! 11 Software Project Management must Manage to a Future (moving) Target u ??? Changes l Market shifts and investment fluctuations l Portfolio changes l Mergers and Acquisitions … u ??? Changes l Hardware, software, networks, mobile … l Fast, better, cheaper … u ??? Changes l Agility vs. quality l Business and technology … u ??? Changes l Shortages and gluts … 12 6
  • 7. Project Management Truths u You can get someone to commit to an unreasonable deadline, but you can’t l …bully him into meeting it u Experienced PM’s Motto: Projects fail l …one day at a time u Projects progress to 90% completion very rapidly… l They remain there while great sums of money and time are spent to keep them there u You can freeze specifications, l …but you can’t freeze expectations u When quoting “off the shelf,” remember l …there is no shelf u If project content is allowed to change freely, l the rate of change will soon exceed the rate of progress 13 Chapter 1: What makes a good Software Manager? u The purpose of this chapter is to examine characteristics of a good software project manager l What are the key attributes associated with successful project managers? l Which software projects management skills are essential? u Objectives l Outline key characteristics of a good software manager l Examine people, business, and process perspectives 14 7
  • 8. People Perspective u Rob Thomasett – “most projects fail because of people and PM concern rather than technical issues.” u ~80% of software project managers come from technical ranks l Some with natural abilities, others must learn l Often with predispositions about managers and how projects should be run l Most are surprised by their first project – Budgets, resources, customers, estimates, teams, meetings, decisions, and risks u Beware of the little hairy boss syndrome… 15 Some Sage Advice… u Be flexible. l Let your people perform according to their capabilities. Stretch goals are good but they have to have enough room to stretch. u Have compassion. l Deal compassionately with difficult people (often they do not know they are difficult and may be difficult because the do not understand) u Know when to lead and when to manage. l Lead people… manage process and product (by example) (systematically) u Accept the role of meetings. l Communication, not bureaucracy l Prepare and manage them 16 8
  • 9. Coach Your Team to Success [Hawkins 1994] u Yes, project management is a team sport u Success is spelled “T E A M” u Increase chances of success by l Hiring the best and brightest l Keep the teams small l Minimize distractions l Train staff for best performance l Meet as a team often but not for long periods l Know your team members l Set the example 17 Software Teams Consider the following factors when selecting a software project team structure ... u Difficulty of the problem to be solved u Size of the resultant program(s) in lines of code or function points u Time that the team will stay together u Degree to which the problem can be modularized u Required quality and reliability of the system to be built u Rigidity of the delivery date u Degree of sociability (communication) required for the project – Relationship management 18 9
  • 10. Business Perspective u Again, most software project managers did not come from the business… u Chaos Study u Creating software products to benefit the business and its customers l Who wants the software and who doesn’t? l Who are the users? What will the software do for them and the business? l When do users need (not want) the software? l Why does the business need the software? l Why is your team developing the software? u Business investment portfolio view 19 Basis for IT Portfolio Investment u Value maintenance — managing ongoing, non- IT Portfolio discretionary investments Proje in IT assets ing Initia cts/ Exist ts tives u Value enhancement — Asse ERP discretionary investments catio ns E -B i z Appli CRM in improving or growing IT Data Secu ri ices Netw ty asset base Serv U p g ork ture rade struc • • ons C u Value exploration — Infra l olid apita • • atio n an C• venture into high-risk/high- Hum • • • •• payoff IT investments • • • • • • • • 20 10
  • 11. Maintain Existing IT Asset Value u IT liability avoidance and Prevent Business Discontinuity value retention u Fund baseline costs for IT Investment Budget critical business operations, maintenance, and support u Skeleton funding based on minimum headcount and costs to keep system running Value Maintenance u Incentives to reduce baseline costs 21 Enhancing Existing IT Asset Value u Strategic priorities Invest in Existing Assets l Investments criteria According to Business Strategy l Investment process IT Investment Budget u Phased funding on projects with interim deliverables l Jump-start l Initial capability l Advanced function Value u Continued allocations Enhancement through project value and delivery commitments Value being met and Maintenance communicated 22 11
  • 12. Exploring Future IT Asset Value u Requires dynamic mindset Engage in high risk, for quick response to value high yield opportunities and market changes l Digital Planning for agility u Value Enhancement Value investment criteria plus: Exploration l Business/Market advantage Value l 2-3 year ROI/IRR projection Enhancement l Clear exit strategy u Manage using a venture Value Maintenance funding model – close and regular interactions 23 Investment Model IT Portfolio Excess Investment Value Cost to Exploration Excel Lost Value Value Leveraged Value Cost to Enhancement Conform Value Maintenance Minimum Investment Followers Leaders 24 12
  • 13. Process Perspective u Software process has matured into a vital part of software projects l Software Engineering Institute’s Capability Maturity Models l Best practices l ISO 9000, Malcolm-Baldridge, TQM… u At the heart of every project plan is an activity/task set derived largely from the process 25 Management Secrets u Avoid having team members work in isolation u Stay with your project team – they are the ones delivering the products of the project u Concentrate on Tasks – not tools u Do your homework (no this is not a subliminal message for CS6704) l Stay current on latest advancements in management and technical techniques for projects that you manage u Sounds like common sense… but it is not so common! 26 13
  • 14. Chapter 2: Four Basics that Work u The purpose of this chapter is to examine four basic software project management principles that work l What are the basic areas for successful project managers to manage? u Objectives l 1. Balance people, process, and product l 2. Promote visibility l 3. Organize using configuration management l 4. Apply standards judiciously 27 The 3 P’s u People l Critical to all projects but the most variable in the management equation l Creative, complex, capable, costly u Process l Most focused on in recent years l Manage the process through measures (next section) l Universe, world, and atomic views u Product l Software is to be change tolerant l Quality measured l Ultimate delivery 28 14
  • 15. Balancing the 3 P’s u Difficult of the product dependent on people and process capabilities l Must triangulate on Pfactors… u People Knowledge l Domain l System l Programming u Process Maturity l Levels 1-5 on the SEI-CMM scale u Product Maturity l From research prototype to packaged component 29 Visibility u Software is invisible to naked eye… l Intangible – must be measured with a computer u Software projects are largely invisible (until they complete) – managed as a cost u Project managers must bring visibility to software product and project u Two “dreaded” visibility vehicles l Documentation l Metrics u Project team vision, commitment, and group memory 30 15
  • 16. Visibility Through Modeling u Models answer questions u What questions need clarity (better visibility) – model them u Modeling tools l SADT/IDEF0, Warnier-Orr diagrams, STDs, Structure charts l CRC cards, object interaction diagrams l Mind maps, story boards, 31 How are Metrics Used for Visibility? tSolving problems — Which choice or improvement Decision? should be made? Benchmarking for performance Predevelop 10 8 improvement Project Mgmt 6 4 2 Develop 0 tGetting attention — Life Cycle Post-develop Integral (CM, V&V) What situations need to be addressed? Dashboard of indicators Goal tKeeping score — How well is it (or IT) doing? Question Scorecard on goals Metric 32 16
  • 17. Meaningful Management Visibility Executive Decision View 100 Production Delay Overhead 48 47 80 i ROI, ROM, EVA, … 46 60 i Business Impact 45 40 44 i Price/performance 20 43 0 42 i Risk/opportunity . . . Value 1st Qtr 2nd Qtr 3rd Qtr 4th Qtr 3.51362 Management View 0.35025 x x 145.600 x 0.78250 300 Exp* 300 Exp*A 0 0 Delay>Svtm Delay>Svtm a mo b max i Costs/budget a b mo max x0 49.5746 avg d u Cst Dr d u Cst Dr x0 30.0067 avg # 36.1301 min # 26.1359 min wkld 16.875 ar 16.875 wkld 16.875 12.4660 SD cv 1 3.11928 SD AltThruput i Schedule/effort/delay Tm 12 svtm 1 BaseThrupu * svtm 0.78 0.35 16.9 Workload 146 0.68 24.5 Alt.Acty Base Acty i Utilization and loading a b mo max a b mo 3 del del max 1680.46 avg 0.13 974.839 34.05 Sdel 6.76 Sdel avg Base 30 980.271 min Alt 500.412 svc s 280.077 15 svc s 25.9854 min 980.271 i Resource availability . . . Ssvc 392.198 SD 500.412 Ssvc SD Audit 293.569 SvcTmBase Audit A SvcTmAlt Operational View TL Obtain Completed Applications, Technical Loan Applications Information Loan Requests, Updates Applications 33.0 D A1 Credit • Process/activities Approval Conduct Applicant Credit Check 53.0 D A2 Technical Approval Conduct • Products/specs Technical Review 132.0 D A3 Accept/Reject Application • Policy/procedures Acceptance Loan Information Guarantee 131.0 D A4 Application • Constraints/guides . . . Correspondence Scientific/Engineering Review Team, OLTG DoD Review Team 33 Key Visibility Principles for Metrics u Clearly defined metrics, consistently applied u Metrics are only indicators, use them accordingly u Focus on leading indicators over lagging ones u Recognize indicators of problems l Lack of change l Frequent change Navigation l Slow, steady deviation from plans Software metrics are navigational instruments giving position, direction, and rate of change 34 17
  • 18. Configuration Management No matter where you are in the system life cycle, the system will change, and the desire to change it will persist throughout the life cycle. Ed Bersoff, et al, 1980 u Product dependencies can be complex l Time, use, version, … 35 Flow of SCM: Definition, Use, Archive SCM Staff Software Project Staff SCM Staff 0 Defines SCM Structures, 0 Uses SCM Library Structures, 0 Archives/Controls Standards and Procedures Standards and Procedures Baselined Software Production Library Production Library Acceptance Test Library Acceptance Test Library Key Software Baseline Versions System Testing Library System Testing Library Archives of System Software Integration Testing Library Integration Testing Library Unit Development Library Unit Development Library Emergency Fix Library Emergency Fix Library 36 18
  • 19. Standards u The wonderful thing about standards is that there are so many to choose from… l But when leveraged correctly, they simplify the process and management of a software project u Standards save time and money u Examples: l IEEE 1042 – SCM Standard l MIL-STD-498/IEEE 1498 – Software Development Life Cycle 37 Software Process u The purpose of this module is to introduce several software process models used to manage large-scale software projects l While no software process works well for every project, every project needs to conform to some systematic process u Objectives l Outline software as a process l Outline key aspects of software process l Examine how to assess software process maturity 38 19
  • 20. The Linear Model System/information engineering analysis design code test 39 Iterative Models team #3 team #2 bus s s ine m o li g de n team #1 business data modeling m e lin od g proc s e s listen business m e li g od n to build/revise modeling data modeling a lic ti n pp a o customer mock-up ge ra tio ne n e tin ts g & u v r t rno e process data modeling modeling application generation process customer modeling testing & test-drives turnover mock-up application generation Prototyping testing & turnover RAD 60 - 90 days 40 20
  • 21. The Incremental Model System/information increment 1 engineering analysis design code test delivery of 1st increment delivery of increment 2 analysis design code test 2nd increment increment 3analysis design code test delivery of 3rd increment increment 4 analysis design code test delivery of 4th increment calendar time 41 An Evolutionary (Spiral) Model Planning Risk Analysis Customer Communication Engineering Customer Evaluation Construction & Release 42 21
  • 22. Still Other Process Models u Component assembly model—the process to apply when reuse is a development objective u Concurrent process model—recognizes that different part of the project will be at different places in the process u Formal methods—the process to apply when a mathematical specification is to be developed u Cleanroom software engineering— emphasizes error detection before testing 43 SEI Process Program Background u CBA IPIs and SPAs conducted since 1987 through December 1999 and returned to the SEI by January 2000 l 1512 assessments – 1024 CBA IPIs – 488 SPAs l 1166 organizations l 309 participating companies l 283 reassessed organizations l 6168 projects *Source: Software Engineering Institute 44 22
  • 23. SEI’s Software Process Capability Maturity Model Level Focus Key Process Areas Result Continuous 5 Process Defect prevention Technology innovation Productivity Optimizing Improvement Process change management & Quality 4 Product and Process measurement and analysis Managed Process Quality Quality management Organization process focus Organization process definition 3 Engineering Peer reviews Training program Defined Process Intergroup coordination Software product engineering Integrated software management Software project planning 2 Project Software project tracking Software subcontract mgt. Repeatable Management Software quality assurance Software configuration mgt. Requirements management 1 Heroes Risk Initial *Source: Software Engineering Institute 45 Summary of the SEI/CMM Levels 1) Initial: The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort. 2) Repeatable: Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications. 3) Defined: The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software. 4) Managed: Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled. 5) Optimizing: Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies. 46 23
  • 24. Software Process Maturity Advances 90 79.8 75.3 80 72.2 70 64.4 58.1 60 48.6 50 40 23.9 30.6 30 21.7 20 15.416.9 15.1 12.4 9.712 15.6 7 8.7 3.8 0.5 0.5 1.5 10 0.7 1.4 2.3 0.8 0.5 0.6 0 Level 1 Level 2 Level 3 Level 4 Level 5 1987-91 1992 1994 1996 1998 1999 *Source: Software Engineering Institute 47 Summary Maturity Findings: Organizational Trends u Software Quality Assurance is the least frequently satisfied level 2 KPAs among organizations assessed at level 1 u Integrated Software Management, Training Program and Organization Process Definition are the least frequently satisfied level 3 KPAs among organizations assessed at level 2 u Higher maturity has been reached among those organizations reporting reassessments *Source: Software Engineering Institute 48 24
  • 25. Process Improvement Maturity Levels Defined s Process metrics focus s High predictability s Process => Success s Medium Risk Repeatable s Project metrics focus Process s Low variability/Medium predictability s PM => Success s Medium-High Risk Ad hoc Process s High variability/Low predictability s Heroes => Success s High Risk 49 More Traction at Upper levels... Optimized (Incorporated) s Value metrics s High predictability s Agility => Success s Low Risk Managed s Product and Process metrics s High predictability s Managed Process => Success s Low-Medium Risk 50 25
  • 26. Homework Assignment for 9/10/01 u Read Paper entitled, “Anchoring the Software Process” by Barry Boehm l Summarize key points of assigned reading into a short 1 page paper (~300-500 words) u Read SPMH Text Chapters 1, 2, and 3 l Homework Questions/Deliverables: 1. What are the key characteristics of an effective project manager? Please include references. 2. Outline how to balance people, process, and product for effective project management 3. What visibility techniques work best for showing project progress? Why? 4. Search web for Configuration Management Plan Template and send it to me via email. u Have a great week! 51 26

×