SOFTWARE PROJECT MANAGEMENT

CS 360

Lecture 4

PROJECT MANAGEMENTThe 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 2

PROJECT MANAGEMENTProject management is concerned with activities that ensure that software is delivered on time and in accordance with the requirements.Systematic, organized approach to software development.

Project management is needed: Software development is always subject to budget and schedule constraints.

3

THE AIM OF PROJECT MANAGEMENTTo complete a project:

On timeOn budgetWith required functionalityTo the satisfaction of the clientWithout exhausting the team

To provide visibility about the progress of the project.

4

PROJECT MANAGEMENT DISTINCTIONSThe product is intangible

Software can’t be seen or touched. Progress is difficult to express by simply looking at the software.

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 is likely to lead to development problems.

5

THE CHALLENGE OF PROJECT MANAGEMENTClients 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?

Often the project is part of a larger activity or system. If the project is to be deployed as a product, marketing and development must be combined.

If the project has to work with other systems, developments must be coordinated. 6

THE CHALLENGE OF PROJECT MANAGEMENTBut:

Every software project is different.

Most systems are not well specified, or the requirements change during development.

Estimating time and effort is full of errors, even when the system is well understood.

Implementing risk management techniques is crucial to increasing project success rate. 7

EXAMPLES OF COMMON PROJECT, PRODUCT, AND BUSINESS RISKS Staff turnover

Affects project Management change

Affects project Hardware unavailability

Affects project Requirements change

Affects project and product Task-time underestimate

Project and product Technology change

Affects business Product competition

Affects business

8

RISK MANAGEMENT PROCESS (DOCUMENTATION)Should be a team activityRisk identification

Identify project, product, and business risks

Risk analysis Assess the likelihood and consequences of these risks

Risk planning Define plans to avoid or minimise the effects of the risks

Risk monitoring Define ways to monitor and log risks throughout the project

9

RISK IDENTIFICATIONChecklist of common risks:

Technology risks Database is too slow, software components contain defects

People risks Difficult to recruit skilled personnel, key staff 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

10

RISK ANALYSISAssess probability and seriousness of each riskExamples:

Financial problems force reductions in the project budget. Probability: Low, Effects: Catastrophic

Difficult or impossible to recruit competent personnel. Probability: High, Effects: Catastrophic

Key staff are unavailable at times. Probability: Moderate, Effect: Serious

Changes are made to requirements that include major redesign. Probability: Moderate, Effect: Serious

Software tools can’t be integrated. Probability: High, Effect: Tolerable

The rate of defect repair is underestimated Probability: Moderate, Effect: Tolerable

11

RISK ANALYSISConsider each risk and develop a strategy to manage that risk

Organizational financial problems: Prepare briefing document to show how the project is making very

important contributions to the organization and why budget cuts would not be cost-effective.

Staff unavailability: Reorganize the project team so there is more task overlap.

Component performance: Research alternative hardware/software components that may increase

performance while remaining in the budget. 12

ASPECTS OF PROJECT MANAGEMENT (DOCUMENTATION) Planning:

Outline schedule during feasibility study (Needed for CS 360). Fuller 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. 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.

13

PROJECT MANAGEMENT TERMINOLOGYDeliverable:

Work product that is provided to the client Mock-up, demonstration, prototype, report, presentation, documentation, code, etc.

Release of a system or subsystem to client or users

Milestone:Completion of a specified set of activities

Delivering specified deliverables Completion of a process step 14

PROJECT MANAGEMENT TERMINOLOGYActivity:

Part of a project that takes place over time (also known as a task).

Event: The end of a group of activities, such as the agreement by all parties on the budget and plan.

Dependency: An activity that can’t begin until some event is reached.

Resource: Staff time, equipment, or other limited item required by an activity

15

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.

16

AGILE APPROACH TO PROJECT MANAGEMENT Planning is divided into high level release forecasting and low level detailed planning.

Release planning is a best guess, high level view of what can be achieved during a specific time span.

Release plans are continually modified Almost daily

Clients and developers take join control of the release plans and choice of sprints.

For each time span, the development team plans on what it can achieve. The development team may use Gantt charts

17

ESTIMATING THE TIME FOR AN ACTIVITY With experienced staff, estimating the actual 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..18

TEAM-BASED ESTIMATING

The team often has the best understanding of what it can achieve in a single time span, or sprint.

The team commits to the outcome of the sprint. The team must have an internal schedule to allocate tasks within a sprint.

The CS 360 project can be thought of as a single sprint.

19

START-UP TIME

On a big 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 360, the start-up time is three to four 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. 20

START-UP TIME

Gantt charts, Activity bar charts, etc.

The group should build a work-plan from activity data.

Display the work-plan in graphical or tabular form.

21

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:

1. List your activities Make a list of everything you plan to do in the project. This includes all code development

and documentation.

2. 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.

3. Put activities in order What will the group do first? Second? … Activities order may be based on deadlines, outside dependencies, progression of the

project, etc.

4. 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.

5. Draw the chart Group activities into major headings and sub headings. Set the time intervals to weeks.

22

GANTT CHARTS EXAMPLE

Activities/Chunk ordering will be determined by the software process model your development team decides to use.

Microsoft Excel can be used to easily create your group’s Gantt Chart.

As the semester progresses, the Gantt chart may 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.

23

ACTIVITY GRAPH (DOCUMENTATION) A group of scheduling techniques that emphasizes dependencies.

An activity (task)

A dummy activity (dependency)

An event

A milestone

24

EXAMPLE: ACTIVITY GRAPH FOR A DISTANCE LEARNING COURSE

25

TIME ESTIMATES FOR ACTIVITIES (WEEKS)

26

ACTIVITY GRAPH

The project group can use an Activity Graph to estimate when tasks can begin, and when tasks should be completed.

The Activity Graph gives the group insight on which tasks can be completed in parallel, and which tasks must be completed sequentially.

The Activity Graph may need updating as the group progresses on the project. Accommodate for tasks finishing early Tasks taking longer than expected New and deleted tasks, etc.

27

ADDING RESOURCES TO ACTIVITY GRAPHS OR GANTT CHARTS (DOCUMENTATION)Each activity can include resources:

Number of people (2 system architects) Key personnel (chief designer) Equipment (3 servers with specified hardware) facilities (research lab)

Each resource is then labelled with availability: Training of developers Equipment availability

28

KEY PERSONNEL: THE MYTHICAL MAN MONTH In CS/SwE, not all people are equal

The best are at least five 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.

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?29

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 key 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 360 should designate a project manager.

Any correspondence outside of the weekly meeting times between the client and development team will be through the project manager. 30

FEASIBILITY REPORT AND PRESENTATIONRemember, the feasibility report is due on Friday.

The report should be as detailed as possible for how your group plans on developing the project.

Feasibility presentation schedule is posted on the class website. The presentation should be 10 minutes long. Make sure to cover relevant material about your group’s project, software process, etc.

Each person should participate in the presentation.

31