1/41 Project Management for Modern Software Development Timothy Korson Sothern Adventist University

2/41 Software Project Management Direct

3/41 Recommended Reading Addison Wesley ISBN For an excellent compilation of information on general project management see the Project Management Body of Knowledge published by the Project Management Institute. Information on it can be found at

4/41 Management Activities Planning the work Measure the project Manage risk Resource planning Foster reuse Ensure quality Communicate with stakeholders Manage the project team

5/41 What Do Project Managers Do?  Team Management  Plan, Schedule, Track  Resource Allocation  Project Direction  Politics  Remove Project Obstacles Direct

6/41 Team Management  Manage the people on the team  Motivation  Conflict resolution  Evaluation, promotion  Recruitment, retention  Career development  Task assignment Direct

7/41 Scheduling  Plan and Track the project  Detailed planning and scheduling  Per person planning and tracking  Iterations  Increments  Testing, Deployment, Support  Big Picture  Functionality Time Tradeoffs  Delivery dates Direct

8/41 Management  The basic questions:  Where are we?  Are we making progress?  When will we be finished?  How much will it cost?  What is the quality? Question

9/41 Resource Allocation  Staffing  Software development tools  Software components  Computer resources  External resources  Space  Etc. Direct

10/ Direction  Keep the project direction aligned with the stakeholders vision  Quality vs. Functionality vs. Cost tradeoffs Direct

11/41 Politics  Project interface and team buffer  Manage stakeholder relationships  Protect the team from the whims of exterior forces  Negotiate with upper level management and project stakeholders  Manage interaction with other teams, such as testing and quality assurance  Fight for resources Direct

12/41 Remove Project Obstacles  Daily Project Meeting Identifies  Bottlenecks  Needed resources  Issues that need resolving  Conflicts between stakeholders  Differences between plans and actualities  Processes that need improvement

13/41 How Does The Use of Agile Processes Affect These Management Tasks?  Team Management  Less Assigning of Tasks  More mentoring  Plan, Schedule, Track  Less detailed plans  More Stakeholder Education  Different Style of Contracts  Different Use of Plans  Resource Allocation  Project Direction  Alignment of Stakeholder Values  Politics Direct

14/41 Stakeholders  A stakeholder is any individual who affects or is affected by the application being built:  Client (those who are paying)  User (those who interact with the application)  Define

15/41 Stakeholders “Involve real users [stakeholders] throughout the software development process; their presence is a constant reminder why and for whom the software is being crafted.” [Booch]

16/41 Project Management  Project management is the application of knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations from a project.  Meeting or exceeding stakeholder needs and expectations involves balancing competing demands:  Scope, time, cost, and quality  Differing needs and expectations among stakeholders  Identified requirements vs. unidentified requirements Define

17/41 Why Do Software Projects Fail?  We fail to properly manage risks  We don’t build the right thing  We are blindsided by technology Notice the “We”. As project managers, we develop idealistic plans, we set unrealistic schedules, we deceive ourselves and others, and we refuse to face reality. These projects eventually enter “free fall” with no one taking responsibility and everyone waiting for the crash (while sending out resumes). Question

18/41 Fail To Properly Manage Risks  “Management must actively attack a project’s risks, otherwise they will actively attack you.” [Gilb]  The first step in managing risks is to identify them  people  technology  environment  dependenciies

19/41 Don’t Build The Right Thing  Incorrect focus on requirements rather than on business goals and objectives.  Examples:  Inventory  NASA  Road

20/41 Blindsided By Technology  Concepts are more difficult than they seem, tools don’t scale up or they introduce errors, suppliers don’t deliver promised functionality or performance. Interactions are more complex that understood. (Engine Control Unit)

21/41  Effective project management actively works to minimize these problems by:  Explicitly identifying and creating written mitigation and contingency plans for project risks  Continuous demonstration and early and frequent deployment of the product being built  Continuous validation of the technologies for use on the project Project Management To The Rescue

22/41 Two Types of Risk  Project and Process Risk  What could go wrong with this project?  Product or Requirements Risk  Which faults would be most damaging to the stakeholders? Define

23/41 Managing Project Risk  Risk Dimensions  Uncertainty – An event may or may not happen. What is the probability of its occurrence?  Damage – What are the implications to the project if the risk occurs?  Problem  A risk that has occurred.

24/41 Managing Risk  The most serious risk factors that affect development projects are: 1)Requirements Problems Incorrect, incomplete, misunderstood, or creeping 2)Management Malpractice 2.1Excessive cost or schedule pressure 2.2Failure to plan, track or control within the framework of a modern development process -- inaccurate resource estimation -- denial 2.3Poor Team Management 3)Poor Quality Software Engineering …inadequate technical expertise 4)Technology Failure

25/41 Managing Project Risk  Acceptance – The level of risk is deemed to be within acceptable limits.  Mitigation – Take steps to minimize the loss.  Prevention – Take steps to minimize the probability. Define

26/41 Managing Product Risk  Establish risk criteria:  Operational Profile (Frequency of Use)  Consequence of Failure  Probability of failure  Use risk analysis to allocate:  analysis resources  architectural resources  testing resources  management resources

27/41 Early Risk Resolution  80% of the engineering is consumed by 20% of the requirements.  80% of the software cost is consumed by 20% of the components.  80% of the errors are caused by 20% of the components.  80% of software scrap and rework is caused by 20% of the changes.  80% of the resource consumption (execution time, disk space, memory) is consumed by 20% of the components.  80% of the engineering is accomplished by 20% of the tools.  80% of the progress is made by 20% of the people. Royce

28/41 Risk profile of a typical modern project across its life cycle. High Low Project Risk Exposure Project Life Cycle InceptionElaborationConstruction--Transition Risk ExplorationRisk ResolutionPeriod Modern Project Risk Profile Conventional Project Risk Profile Controlled Risk Management Period Royce

29/41 7 (±2) Habits Of Successful Projects  A ruthless focus on developing a system that provides a set of essential but minimal characteristics.  A culture that is centered on results, encourages communication, and yet is not afraid to fail.  The application of a well-managed iterative and incremental development life cycle.  Creating and communicating a strong, coherent, and resilient architectural vision.  Effective use of object-oriented modeling.  A management team that is obsessed with quality through adherence to the fundamental principles of software development

30/41 Top 10 Principles of Modern Software Management 1.Base the process on an architecture first approach. 2.Establish an iterative lifecycle process that confronts risk early. 3.Transition design methods to emphasize component-based development. 4.Establish a change management environment. 5.Enhance change freedom through tools that support round-trip engineering. 6.Capture design artifact in rigorous, model-based notation. 7.Instrument the process for objective quality control and progress assessment. 8.Use a demonstration-based approach to assess intermediate artifacts. 9.Plan intermediate releases in groups of usage scenarios with evolving levels of detail. 10.Establish a configurable process that is economically scalable. Royce Direct

31/41 Software Management Best Practices  Formal risk management - using an iterative process.  Agreement on interfaces - same intent as architecture-first principle.  Formal inspections  Metric-based scheduling and management - directly related to model-based notation and objective quality control principles.  Binary quality gates at the inch-pebble level - evolving levels of detail principle.  Programwide visibility of progress versus plan.  Defect tracking against quality targets - directly related to architecture-first and objective quality control principles.  Configuration management - same reasoning behind the change management principle.  People-aware management accountability. Software Acquisition Best Practices Initiative Airlis Software Council Direct

32/41 Top 30 Principles of Conventional Software Engineering 1.Make quality #1. Depends what one means by quality 2.High–quality software is possible. Agreed, but bug free software is next to impossible 3.Give products to customers early. Yes, but 4.Determine the problem before writing the requirements. Domain analysis before detailed use cases Develop the requirements incrementally ISBN: McGraw Hill

33/41 Top 30 Principles of Software Engineering cont. 5)Evaluate design alternatives. Make sure to to test the design against the business goals 6)Use an appropriate process model. Configure yes, but don’t neglect the fundamentals 7)Use different languages for different phases. Use cases, class diagrams, … 8)Minimize intellectual distance. Absolutely

34/41 9)Put techniques before tools. The good old days are long gone…. 10)Get it right before you make it faster. Yes, but 11)Inspect code. Not in the top 30 12)Good management is more important than good technology. Let me explain... Top 30 Principles of Software Engineering cont.

35/41 Top 30 Principles of Software Engineering cont. 13)People are the key to success. Should be in the top 5 14)Follow with care. Good advice 15)Take responsibility. Your parents should have taught you this 16)Understand the customer’s priorities. Change customer to stakeholder. 17)The more they see, the more they need. True, but don’t let that stop you

36/41 18)Plan to throw one away. Too waterfall... 19)Design for change Absolutely, but formally define the scope of anticipated change 20)Design without documentation is not design. False 21)Use tools, but be realistic. Also be realistic about what will happen if you don’t use tools! 22)Avoid tricks. How about: “document your tricks” Top 30 Principles of Software Engineering cont.

37/41 Top 30 Principles of Software Engineering cont. 23)Encapsulate. Move this to the top 10 24)Use coupling and cohesion. A bit simplistic 25)Use the McCabe complexity measure. If you suspect the quality of your software engineers... 26)Don’t test your own software. Don’t be the only one to test...

38/41 27)Analyze causes for errors. A principle of process improvement 28)Realize that software’s entropy increases. Only if you let it 29)People and time are not interchangeable. But they are linked 30)Expect Excellence. And you may get it Top 30 Principles of Software Engineering cont.

39/41 What Do Project Managers Do?  Team Management  Plan, Schedule, Track  Resource Allocation  Project Direction  Politics  Remove Project Obstacles Direct

40/41 Management  Management is more than the ability to estimate, plan and track  Good managers understand the fundamentals of good software engineering, and build an environment and culture that reward quality. Direct

41/41 Don’t Confuse Activity with Accomplishment!  Do what you have to do  Team Management  Plan, Schedule, Track  Resource Allocation  Project Direction  Politics  But don’t neglect achieving your primary responsibility  Value to the stakeholders Direct