Essential Software Project Management Guidelines

1. Chapter 3Project Management

2. Software project management • Concerned with activities involved in ensuring that software is delivered on time and on schedule and in accordance with the requirements of the organisations developing and procuring the software • Project management is needed because software development is always subject to budget and schedule constraints that are set by the organisation developing the software

3. Software management distinctions • The product is intangible • The product is uniquely flexible • Software engineering is not recognized as an engineering discipline with the sane status as mechanical, electrical engineering, etc. • The software development process is not standardised • Many software projects are 'one-off' projects

4. The 4 P’s • People — the most important element of a successful project • Product — the software to be built • Process — the set of framework activities and software engineering tasks to get the job done • Project — all work required to make the product a reality

5. Software Project Management • Work to be done (estimate) • Resources available • Technical personnel hours • Administrative support hours • Equipment • Software • Budget

6. Software Project Management • Resources • People • Money • Tasks • Map people to tasks • Map money to tasks • Time • Map tasks and people to a schedule • Handle constraints among task serialization • Manage milestones (intermediate deadlines)

7. Project Management Tools • Resources • Spreadsheet • Tasks • Spreadsheet • Time • Calendar • Pert-type chart • Everything • Project Management Software

8. Project Management • Project [persistent] functions • Planning • Hiring/firing/evaluations • Accounting/budgeting • Activities • Non-persistent • Comprised of tasks • Work products • Results of tasks

9. The Players • Senior Managers • Project Managers • Practitioners • Customers • End users 10

10. The Project Managers • Hardest Problem • Having the right people • On the right part of the project • At the right time • At the right price

11. Software Projects Factors that influence the end result ... • size • delivery deadline • budgets and costs • application domain • technology to be implemented • system constraints • user requirements • available resources

12. Project Management Concerns

13. Why Projects Fail? • an unrealistic deadline is established • changing customer requirements • an honest underestimate of effort • predictable and/or unpredictable risks • technical difficulties • miscommunication among project staff • failure in project management

14. Software Teams The following factors must be considered when selecting a software project team structure... • difficulty of the problem to be solved • size of resultant program(s) in LOC or FP • time the team will stay together (team lifetime) • degree to which the problem can be modularized • required quality and reliability of the system to be built • rigidity of the delivery date • degree of communication required for the project

15. Organizational Paradigms • closed paradigm—structures a team along traditional hierarchy of authority • random paradigm—structures a team loosely and depends on individual initiative of the team members • open paradigm—attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm • synchronous paradigm—relies on the natural compartment-alization of a problem and organizes team members to work on pieces of the problem with little active communication among themselves suggested by Constantine [CON93]

16. Software Team • Paradigms • Controlled (the traditional approach) • Centralized (vertical only) • Decentralized (horizontal too) • Demographic • Pairs

17. Democratic Software Team • 10 (or so) egoless programmers • No single leader • No programmer trying to get promoted to the next level • Roles are dynamics and not well-defined • Quality Circles

18. Democratic Software Team • Egoless programming • Every programmer must encourage the other members of the team to find faults • The presence of faults must not be considered something bad, but rather a normal and accepted event • The reviewer is asked for advice

19. Democratic Software Team • Leverages the diversity of the group • Two heads really are better than one • Facilitates reviews and walkthroughs, which are proven to improve fault detection • The ultimate goal is to reduce fear in the workplace. • Primary means is by sharing responsibility

20. Fallacy of Egolessness • Everybody has egos • Leaders "need" to lead • Capitalism is founded on competition • Difficult to attain group decisions that truly represent the entire group • Large number of personal interconnections required • Group dynamics suggests that structure will occur

21. Pair Programming • Match up two people • One to define requirements, another to document requirements. • Allows interaction between two people to drive out requirements. • Can have two people programming, one thinking and one keying.

22. Defining the Problem • establish scope—a narrative that bounds the problem • decomposition—establishes functional partitioning

23. Melding Problem and Process

24. To Get to the Essence of a Project • Why is the system being developed? • What will be done? By when? • Who is responsible for a function? • Where are they organizationally located? • How will the job be done technically and managerially? • How much of each resource (e.g., people, software, tools, database) will be needed? Barry Boehm

25. Critical Practices • Formal risk analysis • Empirical cost and schedule estimation • Metrics-based project management • Earned value tracking • Defect tracking against quality targets • People aware project management

26. Management activities • Proposal writing • Project planning and scheduling • Project costing • Project monitoring and reviews • Personnel selection and evaluation • Report writing and presentations

27. Project staffing • May not be possible to appoint ideal team • Budget may not allow use of high-paid staff • Staff with the appropriate experience may not be available • An organisation may wish to develop employee skills on a software project • Managers work within these constraints especially with the international shortage of skilled IT staff

28. Project planning • Probably the most time-consuming project management activity • Continuous activity from initial concept through to system delivery. Plans must be regularly revised as new information becomes available • Various different types of plan may be developed to support the main software project plan that is concerned with schedule and budget

29. Activity organization • Activities in a project should be organised to produce tangible outputs for management to judge progress • Milestones are the end-point of a process activity • Deliverables are project results delivered to customers • The waterfall process allows for the straightforward definition of progress milestones

30. Project scheduling • Split project into tasks and estimate time and resources required to complete task • Organize tasks concurrently to make optimal use of workforce • Minimize task dependencies to avoid delays caused by one task waiting for another to complete • Dependent on project managers intuition and experience

31. Scheduling problems • Estimating the difficulty of problems and hence the cost of developing a solution is hard • Productivity is not proportional to the number of people working on a task • Adding people to a late project makes it later because of communication overheads • The unexpected always happens. Always allow contingency in planning

32. Bar charts and activity networks • Graphical notations used to illustrate the project schedule • Show project breakdown into tasks. Tasks should not be too small. They should take about a week or two • Activity charts show task dependencies and the the critical path • Bar charts show schedule against calendar time

33. Pert Charts • Program Evaluation Review Techniques • US Navy, 1957 • Systematic method of estimating project length • Based on a systematic serialization algorithm based on: • Dependencies • Resource availability • Adds administrative oversight to critical paths • Critical path: Sequence of tasks such that if any task on the CP is delayed, so is the whole project 22

34. Activity network - PERT T 6 M 3 s t a r t T 7 T 2 M 2 M 7 T 5 T 4 T 1 0 M 5 F i n i s h 1 5 d a y s 1 4 / 7 / 9 9 1 5 d a y s M 1 T 3 8 d a y s T 9 T 1 5 d a y s 4 / 8 / 9 9 2 5 / 8 / 9 9 2 5 / 7 / 9 9 M 4 M 6 4 / 7 / 9 9 7 d a y s 2 0 d a y s 1 5 d a y s T 1 1 5 / 9 / 9 9 2 5 / 7 / 9 9 1 1 / 8 / 9 9 1 0 d a y s 1 0 d a y s M 8 1 5 d a y s 1 0 d a y s 1 8 / 7 / 9 9 T 1 2 2 5 d a y s T 8 1 9 / 9 / 9 9

35. Activity timeline - Gantt