% of commercial projects fail. % of open source projects fail

60-499Project Management:Techniques & Tools

% of commercial projects fail. % of open source projects fail. % of commercial projects fail. % of open source projects fail.

Chapters 1-2


80 % of commercial projects fail. % of open source projects fail.

80 % of commercial projects fail. % of open source projects fail.


80 % of commercial projects fail.90 % of open source projects fail.80 % of commercial projects fail.90 % of open source projects fail.


80 % of commercial projects fail.90 % of open source projects fail.80 % of commercial projects fail.90 % of open source projects fail.

Why?


Course OverviewCourse Overview

What we’ll be doing this year

Project Management PhasesProject Management Phases

1. Defining 1. Defining

2. Risks 2. Risks

3. Planning & Scheduling3. Planning & Scheduling

4. Launching4. Launching

6. Closing6. Closing

5. Monitoring & Controlling5. Monitoring & Controlling


Why do projects fail?Why do projects fail?

Why do projects fail?Why do projects fail?

• We need to ask these important questions:– What kind of failure was it?

• e.g. incomplete, unreliable, off-schedule/budget

– Who was responsible?– What happened?– What did not happen?– Which process(es) broke down?– What module(s)/feature(s) failed?

Where failure can happenWhere failure can happen

1. Requirements 1. Requirements

2. Risks 2. Risks

3. Planning & Scheduling3. Planning & Scheduling

4. Launching4. Launching

6. Closing6. Closing

5. Monitoring & Controlling5. Monitoring & Controlling

Built the wrong thing

Ignored potential pitfalls

Overly optimistic schedules

Poor team dynamics

Poor development practices

No customer acceptance

Reasons for project failureReasons for project failure

• These reasons seem to blame the developers:– Poor design– Uncommitted or de-motivated developers– Weak, antagonistic, unreliable developers/contractors– Gold-plated features or documentation– Autobahn development or bug-fixing– Silver bullet syndrome– Lack of source control– Abandoned planning


• These reasons seem to blame the customer or upper management:– Feature creep– Unrealistic schedules– Unrealistic expectations– Incorrect requirements


• These reasons seem to blame the project manager:– Poor planning– Insufficient risk management– Insufficient quality assurance

• Who is really responsible for these problems?– The project manager

A project manager’s roleA project manager’s role

• A major role of a project manager (PM) is to ensure that the project succeeds– To a lesser degree, this is also a role for other stakeholders

• Therefore, the PM is responsible (if not to blame) when these problems occur

• A project manager must remain unbiased– Customers or upper management may ask for unrealistic

features and/or schedules– It is not a project manager’s role to make such schedules work,

by pushing developers harder

Project management careersProject management careers

• A PM is someone with years of experience• This is usually someone who…

– has experienced successful projects– has experienced failed projects– has excellent organizational skills– has excellent communication skills– is a strong leader

• Common project management certifications:– Project+: Entry-level certification, for aspiring project managers– PMP: Professional cert., for experienced project managers

• Project management body of knowledge (PMBOK)


Project Management Overview

Project Management Overview

Project management approachesProject management approaches

• The textbook three approaches to project management:– Traditional

• This approach has been used for IT projects, nearly unchanged, for decades

– Adaptive• This approach is one which combines some of the best

features of the traditional and extreme approaches

– Extreme• This approach is the project management approach that

goes along with eXtreme Programming (XP)

Upstream activitiesUpstream activities• Upstream activities are things that normally happen prior

to development– Defining– Planning – Architecture & design

• Traditional– Upstream activities occur for the whole project in one step

• Although changes can be made

• Extreme– Upstream activities occur for each version

• Each iteration produces a version that is closer to the ultimate goal

Traditional project management Traditional project management

Defining

PlanningLaunching

Monitoring&

Controlling

Closing

Adaptive project management Adaptive project management

Defining

PlanningLaunching

Monitoring&

Controlling

Closing

Extreme project management Extreme project management

Defining

PlanningLaunching

Monitoring&

Controlling

Closing

Next version

ProcessesProcesses

• Here are the processes of project management:– Defining– Planning– Launching– Monitoring & Controlling– Closing

DefiningDefining• We need to determine what the customer wants• We do this by identifying:

– Requirements• Goals• Deliverables• Success criteria• Scope

– Risks• Impact• Probability

PlanningPlanning

• We know what we want• Now, we figure out how to do the work required• We do this by:

– Performing architecture & design– Identifying activities: work breakdown structure (WBS)– Identifying dependencies between activities– Estimating activity duration– Estimating activity resource requirements– Scheduling activities (start date, duration)

LaunchingLaunching

• We have a detailed work plan• Now, we get the work underway• We do this by:

– Choosing participants– Making participants available for the project– Assigning work to participants– Organizing participants into team(s)– Providing resources to the team(s)– Establish constraints and freedoms for the team(s)

Monitoring & ControllingMonitoring & Controlling

• We have people working on activities• Now, we must ensure we are making adequate progress• We do this by:

– Interviewing and observing progress reports– Implementing version control software– Providing mechanisms for requesting changes– Continually updating plans (e.g. schedules)

ClosingClosing

• We have completed all activities– The result should be that

• All overall goals are satisfied

• All conditions of satisfaction are met

• All deliverables are ready for roll-out

• Now, we need to complete hand-over• We do this by:

– Obtaining client acceptance– Deploying deliverables

• e.g. media disks, printed manuals, online deployment/downloads

– Performing a post-mortem analysis• How did we do?


Explanation of TermsExplanation of Terms

GoalsGoals

• A goal is normally a solution to a problem• When defining goals, answer the following questions:

– What problem will we solve?• e.g. Accounting department has 2 month turnaround for budget

requests, which is too long.

– In what sense will we solve the problem?• e.g. Our accounting software will streamline the process of budget

re-work.

• We often have one overall goal– This may be made up of several smaller sub-goals (objectives)

• e.g. The software will look in volatile financial areas first, allowing the accounting department to quickly find the resources.

Success CriteriaSuccess Criteria

• Success criteria define what must be true in order for the project to be considered a success– These are related to the goals– However, they are attributes that can be measured

• e.g. The accounting department’s time to approve a budget is reduced by at least 50%.

– We can measure after the project’s completion and test for success

DeliverablesDeliverables

• Deliverables are the actual artifacts created by the project team for the customer

• These typically include:– Binary packages– Source packages (in open source projects)– Documentation & tutorials– Version history– Utilities– Installation software

ScopeScope

• The project’s scope defines its boundaries– This could include specific statements

• These are called requirements

• Often, a project manager will work with customers to decide which requirements are necessary, and which are not

– This could also include general statements• These could be used to determine whether or not a feature request

(change) is appropriate later

• Thus, scope deals with both requirements and changes

RisksRisks

• Risks are things that could cause the project to:– Fail– Be delayed– Require additional budget– Require additional personnel

• A project manager should identify:– Impact: What is the expected negative impact should it occur?– Probability: How likely is it to occur?

ActivitiesActivities

• An activity is something a participant may undertake– This could be:

• Designing a module

• Updating documentation

• Optimizing the search code

• Installing the binaries in a web server

• Writing a lookup method

• Activities can be:– Estimated for time & resource requirements– Assigned to team member(s)

ScheduleSchedule

• A schedule is a time-plan for activities• The schedule must:

– Include all activities– Show dependencies between activities

• e.g. What must occur before this activity can start?

– Show estimated durations for activities– Show starting points for activities– Show combined activity duration as project duration– Show estimated resources for activities– Show combined activity resource requirements as project

resource requirements

TeamTeam

• A team is a group of participants with shared objectives– However, teams do not have to have the same skills and

experience

• Team effectiveness is impacted by:– Individual participant effectiveness– Social dynamics within the team– Motivation– Team leadership


Project MilestonesProject Milestones

Project MilestonesProject Milestones• The various processes may overlap, but they should

eventually produce these results:– Project charter– Project scope statement– Risk document– Work breakdown structure (WBS)– Project plan (project proposal in the textbook)– Architecture & design– Deliverables– Post-mortem analysis

Project CharterProject Charter

• The project charter defines– The business justification– The overall goals of the project– The stakeholders of the project– The desired costs and duration of the project

• The project charter is often produced by the project sponsor or customer

• This should be the first page in your book of project management documentation

Project Scope StatementProject Scope Statement

• The project scope statement defines:– The project’s requirements

• Goals

• Success criteria

• Deliverables

– The project’s boundaries• What should be part of the project

• What should not be part of the project

Risk DocumentRisk Document

• The risk document:– Identifies and describes risks– Describes what conditions make it happen– Describes the probability of it happening– Describes the impact of it happening– Describes a plan for how to (try to) avoid it happening– Describes a plan for what to do if it happens

• This is only done if the probability and/or impact necessitate such a plan

Work Breakdown StructureWork Breakdown Structure

• The WBS:– Defines all activities

• Each system function is defined as a high-level activity

• Each activity is broken down into smaller activities

• This process repeats until activities are small and manageable

– Shows hierarchical relationships between activities• A WBS can be represented with a tree diagram

Project PlanProject Plan

• The project plan defines:– Dependencies between activities

• e.g. IVG module test design must be complete before development can begin

– Schedule• Including an estimate of each activity’s duration

– Initial activity assignment• Activities are assigned to fictitious team members

Architecture & DesignArchitecture & Design

• Architecture refers to the overall structure of the application– In short, an architecture defines the modules– Each module has a set of common responsibilities

• Often, these responsibilities are related– e.g. The DAL module is responsible for maintaining consistency

between customer objects and the database of customer data

• Design refers to the structure of the module itself– This often involves creating classes (in OOD) and assigning

responsibilities (functions or data) to them

Post-Mortem AnalysisPost-Mortem Analysis• A post-mortem involves analyzing the project upon

completion– This is not to be confused with QA, which analyzes the

deliverables

• A post-mortem is a critical step, that many project managers miss– This is a project manager’s chance

• Perhaps they can more accurately estimate activities after the experience

• Perhaps they can identify mistakes made, to avoid making them again

• Perhaps they can recognize personal achievements

SummarySummary• Project management’s job is to ensure that projects do

not fail– We must identify what the customer wants– We must identify potential pitfalls– We must list what needs to be done– We must make detailed plans– We must prepare for changes– We must ensure that our plans are being followed– We must ensure that our plans are working

• If not, we must update them or take another corrective action


Questions?Questions?

% of commercial projects fail. % of open source projects fail

Documents