1. Software Project management
CS 560
Lecture 4

2. Project Management
The operating system for the IBM 360 was two years late!
Question:
How does a project get two years behind schedule?
Answer:
One day at a time!
Fred Brooks Jr., The Mythical Man Month, 1972

3. Project Management Provides activities to ensure:
Development is organized and visible.
Development agrees with the requirements.
Software is delivered on time.
Project management is needed since:
Development is subject to
Budget constraints
Schedule constraints
Personnel skills and background

4. The aim of Project Management
To complete a project:
On time
On budget
With required functionality
To the satisfaction of the client
Without exhausting the team
To provide visibility about the progress of the project.

5. Software Project Management distinctions
The product is intangible
Software can’t be seen or touched.
Progress is difficult to express by simply looking at source code.
Many software projects are “one-off” projects
New projects usually differ in some way than previous projects.
Even experienced personnel may find it difficult to anticipate problems.
Software processes are variable
Industry leaders still can’t reliably predict when a particular software process/process step is likely to lead to problems.
BUT.. They do not take an ad-hoc approach either.
Capability Maturity Model Integration (CMMI) 1

6. Capability Maturity Model Integration
2016 Data from 14,522 industry organizations. 7.7% 2.4% 71% 18.1% 0.8%

7. The Challenge of Project Management
Clients wish to know:
Will the system do what was promised?
When will it be delivered?
If late, how late?
How does the cost compare to the budget?
What resources are needed to design/build the project?
Will new resources be needed before the system is released?
What’s the current status of the project?

8. Examples of common risks
Staff turnover
Affects project
Management change
Hardware unavailability
Requirements change
Affects project and product
Task-time underestimate
Project and product
Technology change
Affects business
Product competition

9. Risk management process (documentation)
Should be a team activity
Risk identification
Identify risks associated with personnel, HW/SW, process, time, etc.
Risk analysis
Assess the likelihood and consequences of these risks
Risk planning
Define plans to avoid or minimize the effects of the risks
Risk monitoring
Define ways to monitor and log risks throughout the project

10. Risk identification (documentation)
Technology risks
Database is too slow, software components contain defects
People risks
Skillset of team members, key members unavailable at times
Organizational risks
Management personnel change, reduction in project budget
Requirements risks
Changes require major redesign
Estimation risks
Time requirements, defect repair rate underestimated, project size

11. Risk analysis (Documentation)
Assess probability and impact of each risk
Examples:
Financial problems force reductions in the project budget.
Category: External
Risk Level (based on loss): Medium
Probability: Low
Impacts (loss defined): Requirements/functionality, development time, system quality
Software tools can’t be integrated.
Category: Internal, Technical
Risk Level (based on loss): High
Probability: medium
Impacts (loss defined): Software Functionality, development time, system quality
The rate of defect repair is underestimated
Category: Internal
Impacts (loss defined): Development time, system reliability

12. Risk Planning (Documentation)
Consider each identified risk
Define measures that would decrease the probability of that risk.
Define measures that would decrease the impact of that risk.
Examples:
Staff unavailability:
Reorganize the project team so there is more task overlap.
Make sure all team members are aware of all task components.
Component performance:
Research alternative hardware/software components that may increase performance while remaining in the budget.

13. Risk Management Process (Documentation)
Project groups should organize and document
their approach to the risk management process

14. Aspects of Project Management
Planning:
Outline schedule during feasibility study (Needed for CS 560).
Fuller, more detailed schedule for each part of a project.
Each process step, iterations, sprint
Contingency planning:
Anticipation of possible problems.
Risk management
Progress tracking:
Regular comparison of progress against plan.
Weekly reports, Gantt/Activity Charts
Regular modification of the plan.
Changes of scope, etc. made jointly by client and developers.
Final analysis
Analysis of project for improvements during next project.

15. Project Management Terminology
Deliverable:
Work product that is provided to the client
Mock-up, demonstrations, prototypes, reports, presentation, documentation, source code, etc.
Release of a system or subsystem to client or users
Milestone:
Completion of a specified set of activities
Completion of a process step(s)
Submitting specified deliverables

16. Project Management Terminology
Activity:
Part of a project that takes place over time (task).
Event:
The end of a group of activities, generally includes the completed result of a required component/deliverable.
Dependency:
An activity that can’t begin until some event is reached.
Resource:
Staff time, equipment, or other limited item required by an activity

17. Standard approach to Project Management
The scope of the project is defined early in the process.
The development is divided into tasks and milestones.
Estimates are made of the time and resources needed for each task.
The estimates are combined to create a schedule and a plan.
Progress is continually reviewed against the plan, perhaps weekly.
The plan is modified by changes to scope, time, resources, etc.

18. Estimating the Time for an activity
With experienced staff, estimating the time to carry out a single task is usually fairly accurate, but..
The smaller details are underestimated.
The time from “almost done” to “completely done” is much longer than anticipated.
“There’s just one thing that needs finishing..”
“Comments and documentation need refining..”
“I just need to integrate this last feature..”
The distractions are not planned for.
I have a test/homework in another class.
I decided to upgrade the operating system, now nothing works.
I forgot to create system backups
Total hardware/software failure
Some things will have to be done twice, or three times..

19. Team-based estimating
The team has the best understanding of what it can achieve in a single time span, or sprint. Estimated times for these activities should be documented:
Research (gather information on approach, SW languages, HW, etc.)
Communicating with client (gathering requirements, project visibility)
Requirements analysis and documentation
Creating design models and documentation
Implementation (only after requirements are clearly stated and design models have been created)
Testing (generating test cases, test data, gathering, processing, and documenting the results)
Documentation revision and updates (takes significant time)
Presentation preparation
All team members must commit to the outcome of the sprint.
The team must have an internal schedule to allocate tasks within a sprint.

20. Start-up time
On a large project, the start-up time is typically three to six months:
Personnel have to complete previous projects (fatigue), or be recruited.
Hardware and software has to be acquired and installed.
Staff have to learn new domain areas and software (slow while learning).
Clients may not be ready.
In CS 560, the start-up time is 3 weeks.
Essentially the same start-up tasks, but applied to a smaller project.
Teams need to learn organizational, communication, and domain related skills.
Teams also need to learn how to apply software engineering concepts to completing the project.

21. Project Scheduling Gantt charts, Activity charts, etc.
The group should build a work-plan from activity data.
Display the work-plan in graphical or tabular form.

22. Gantt Charts (documentation)
A chart that illustrates the start and finish dates of essential tasks needed in a project.
Steps to creating your team’s Gantt chart:
List your activities
Make a list of everything you plan to do in the project. This includes all basic steps covered in the software process model selected by your group.
Estimate the time required
For each item on your list, estimate how long it will take the group to finish that task.
Make realistic assumptions on what the group can accomplish during a given time span.
Put activities in order
What will the group do first? Second? …in parallel?
Order may be based on deadlines, dependencies, time, progression of the project, etc.
Create task chunks
Chunks, for this project, should be defined in weeks. Chunks can overlap, if the development team is working on tasks in parallel.
Draw the chart
Group activities into major headings and sub headings.
Set the time intervals to weeks.

23. Gantt Charts Example
Activities/Chunk ordering will be determined by the software process model your development team decides to use.
As the semester progresses, the Gantt chart may (will) need modifying.
The group should keep all revisions of the Gantt chart in the project documentation.
The charts can be named or versioned, v1, v2, etc.

24. Activity Graph (Documentation)
Activity Graph are used to estimate when tasks can begin, and when tasks should be completed.
Gives insight on which tasks can be completed in parallel, and which tasks must be completed sequentially.
The Activity Graph may (will) need updating as the group progresses on the project.
Accommodate for tasks finishing early
Tasks taking longer than expected
Unexpected dependencies
New and deleted tasks, etc.

25. Activity Graph (Documentation)
A group of scheduling techniques that emphasizes dependencies.
An activity (task)
A dependent
activity (dependency)
An event
A milestone

26. Example: Activity graph for a distance learning course

27. Time Estimates for Activities (Hours) (documentation)

28. Adding Descriptions to Activity Graphs and Gantt charts (documentation)
Each task should include a description:
Give a detailed description of the task
Explain who’s involved (2 system architects)
List key personnel leading the tasks
List other required resources (2 Docker containers, network socket interface, etc.)
List dependent tasks (if necessary)

29. Key Personnel: The mythical man month
In CS/SwE, not all people are equal
The best are many times more productive.
Some tasks are too difficult for everybody.
Adding more people adds complexity
Some activities need a single mind.
Sometimes, the time needed for an activity can’t be shortened by increasing personnel.
Think about this if you plan on shifting team members between tasks.
Adding more people may sometimes increase the time to complete a project.
What happens to the project if a key person is sick or quits?

30. The project manager (documentation)
Creates and maintains the schedule.
Tracks progress against the schedule.
Keeps some contingency time in the schedule (to reduce risk).
Assigns himself/herself tasks in other areas of the project team.
Continually makes adjustments:
Start activities before previous activities are complete (parallel tasks if possible).
Sub-contract activities to project group members based on background, skills, etc.
Negotiating deliverables
Keeps client(s) informed of key aspects of the project and project group.
The project manager needs the support of the entire team.
Each project group in CS 560 should designate a project manager.