Project Management

Why do projects fail?

Technical Reasons
 inexperience with language/environment
 last minute efforts
 lack of standards
 fantasy factor
 lack of configuration control
 failure to follow review/inspection processes
Reasons for Failed Projects continued

Personal Factors
 motivation
 heavy load
 failure to admit need for assistance (ego)
 opinionated individuals (ego)

Management Factors
 poor team selection
 lack of team growth
 poor coordination of team meetings
 struggles for leadership (ego)
 poor communication
Project Management Concepts: 4 P’s

People
 Recruitment, training, organization, team
development

Product
 Define project scope and design of product

Process
 Establish framework for software development

Project
 Understand complexities of project development
Process Management

Select process model
 provides framework for activities

Process decomposition
 Task sets - scheduling, milestones, deliverables,
QA points

Umbrella activities
 Software QA
 SW Configuration management
 Measure
People Management

People work in groups
 Want a good balance of skills, experience and
personalities
 Group is a team not just collection of individuals
• Group standards, work closely, egoless
People Management

Team Building
 clear purpose and commitment
 open communication and support, shared
leadership, and constructive feedback
 focus on behaviors and not personalities

Stages of Team Development
 forming (awareness)
 storming (conflict)
 norming (cooperation)
 performing (accomplishing)
» PeopleMgmt.ppt
People Management

Team Empowerment
 self-governing
 decision-making latitude: leader decides “what” is
to be done, team sets intermediate deadlines,
team determines own organizational structure
 leader “hands-off” until needed

Self-Evaluation of Team
 schedule slips, causal analysis of team difficulties,
done as a team and individually
People Management

Project Managers
 Solve technical and non-technical problems using
people on their teams
 Motivate people
• Satisfy Needs: social, esteem, self-realization
 Plan and organize their work
 Ensure work is being done properly
3 Team Organizations

DD - democratic, decentralized
 task coordinators, group consensus

CD - controlled, decentralized
 defined leader, problem solving group

CC - controlled, centralized
 Top-level problem solving and communication
between leader and team members
3 Team Organizations






Centralized (CD or CC) – simple problems
Decentralized (DD) – more and better
solutions for difficult problems
CC or CD - very large problems when
subgrouping easily accommodated (to reduce
communication paths)
DD – problems with low modularity when
higher volume of communication necessary
DD – high morale and job satisfaction (long
team life)
CC and CD – produce fewer defects
Two Examples

Chief Programmer Team Concept (CD)
 senior engineer (design, implementation, install),
backup engineer(validation), tech staff, librarian
(configuration mgmt and finalizing documentation),
support (clerical/tech writers), specialists
 Risks?

Structure Open Team (DD)
 project is a joint effort
 egoless programming
 thorough reviews
 side-by side work
 Risks?
Problem Management

Problem:
 objectives and scope must be defined
 alternative solutions explored
 technical and management constraints (deadlines,
budge, personnel) identified
 with information define cost estimates, assess
risks, breakdown tasks, and create schedule
Problem Management Activities (1-4)
1.
2.
Define scope/objectives, alternative
solutions, constraints
Metrics:
 collect information to define cost estimates,
assess risks, breakdown tasks, and create
schedule
 measure product to assure quality
3.
Cost Estimation:
 provides info for remaining activities (manpower,
project duration, $)
4.
Risk analysis:
 identify, assess, prioritize, management, resolve
and monitor
Problem Management Activities (5-6)
5.
Scheduling:
 evolve or plan in advance, establish milestones,
determine task dependencies, assign resources
6.
Tracking and Control
 note each task in schedule, assess impact of
delayed task, redirect resources, modify delivery
commitments
Determining Software Scope






Function tasks and performance
Quantitative data stated explicitly (#users,
size of list, response time)
constraints and/or limitations noted
mitigating factors described
interfaces
reliability issues
Task Network

Graphic, shows task sequences and
dependencies
Design
Coding
Integration
Testing
Analysis/Specs
Tests
Developed

REFINE
Unit
Testing
Scheduling Methods and Tools


PERT (program evaluation and review
technique)
Uses
 effort estimates, decomposition of product
function, process model, project type, task set,
task network
 determine critical paths, time estimates, boundary
times (earliest and latest start times, earliest and
latest end times, float times)
 produce a timeline or GANTT chart
 should also allocate resources

Microsoft Project : PERT and GANTT charts
Project Tracking and Control

Tracking
 conduct periodic status meetings: report progress
and problems
 evaluate results of all reviews
 milestones accomplished by scheduled date?
 Compare dates
 informal meetings on subjective assessments

Control
 light if everything going well
 if not: diagnose problem, reassign resources,
redefine schedule
Project Plan


IS A DELIVERABLE
TURN IN TO ME!