project management
Download
Skip this Video
Download Presentation
Project Management

Loading in 2 Seconds...

play fullscreen
1 / 18

Project Management - PowerPoint PPT Presentation


  • 171 Views
  • Uploaded on

Project Management. Instructor: Dr. Jerry Gao. Project Management. - The Management Spectrum - People - The Players - Team Leaders - The Software Team - Coordination and Communication Issues - The Problem - Software Scope - Problem Decomposition - The Process

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Project Management' - denis


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
project management
Project Management

Instructor: Dr. Jerry Gao

project management2
Project Management

- The Management Spectrum

- People

- The Players

- Team Leaders

- The Software Team

- Coordination and Communication Issues

- The Problem

- Software Scope

- Problem Decomposition

- The Process

- Melding the Problem and the Process

- Process Decomposition

- The Project (the 90-90 rule)

Jerry Gao, Ph.D. Jan. 1999

slide3
The Management Spectrum - People

- Three P’s:

Effective software project management focuses on the three P’s:

(1) people, (2) problem, and (3) process

- People:

Software engineering work is an intensely human endeavor.

A people management capability maturity model (PM-CMM)

--> key practice areas for software people:

- recruiting, selection, performance, management,

training, compensation, career development,

organization and work design, and team/culture development

The most important contributor to a successful software project

--> having smart people with good skills

Organizations with high levels of maturity in the people management

---> implementing effective software engineering practice

slide4
The Management Spectrum - The Problem

- Three P’s:

Effective software project management focuses on the three P’s:

(1) people, (2) problem, and (3) process

- Problem (related to a project):

Before starting a project, we need to define and identify its

- Objectives and scope

- Alternative solutions

- Technical and management constraints

Considering other factors:

delivery deadlines, budgetary restrictions, personnel availability

technical interfaces, and so on.

Without these information, it is impossible

- To define reasonable estimates of the cost

- To conduct an effective assessment of risk

- To do realistic breakdown of project tasks

- To come out a manageable project schedule

slide5
The Management Spectrum - The Process

- Three P’s:

Effective software project management focuses on the three P’s:

(1) people, (2) problem, and (3) process

- Process:

A software process provides the framework -->

a comprehensive plan for software development

A number of different tasks sets applicable to all software projects: - tasks, milestones, deliverables, and quality assurance points

Umbrella activities -> occurs throughout the process:

- software quality assurance

- software configuration management

- measurement

slide6
People - The Players

- In a software process, there are five types of players:

- Senior managers, who defines the business issues.

(strong influence on the project)

- Practitioners, who deliver the technical skills for engineering software

- Project (technical) managers, who must plan. Motivate, organize

and control the practitioners.

- Customers, who specify the requirements for the software.

- End users, who interact with the software once it is released for use.

slide7
People - Team Leaders

- Project management is a people-intensive activity.

How to select a good team manager?

MOI model of leadership suggested by Jerry Weinberg [WEi86]:

- Motivation - the ability to encourage technical people.

- Organization - the ability to mold existing processes that will enable initial concept to be translated into a final product.

- Ideas or innovation - the ability to encourage people to create and feel creative.

Software managers should concentrate on

- understanding the problem to be solved,

- managing the flow of ideas,

- letting everyone on the team know that quality counts.

Four important key traits to be an effective project manager:

- Problem solving

- Managerial identity

- Achievement

- Influence and team building

slide8
People - The Software Team

Mantei [MAN81] suggests three generic team organizations:

- Democratic decentralized (DD):

- the software engineering team has no permanent leader.

- decision is made by group consensus.

- communication among team members is horizontal.

- Controlled decentralized (CD):

- has a leader -> coordinates specific tasks and secondary leaders.

- secondary leaders have responsibility for subtasks.

- horizontal communications among subgroups and individuals.

- vertical communication in the control structure

- decision is made by leaders.

- Controlled centralized (CC):

- team leader manages top-level problem solving and internal team

coordination.

- communication between the leader and team members is vertical.

slide9
People - The Software Team

DD:

group

CC:

Team leader

DC:

Team leader

secondary team leader

communication

group

group

slide10
People - The Software Team

Functional tasks

FT1

FTm

X

P1

X

X

X

X

Pn

X

Project manager + n engineers + m tasks

team

engineer

FT1

FTm

T1

Tm

X

X

P1

P1

X

X

Pn

X

X

X

Pn

X

Project manager + team leaders

Project manager+ informal teams with coordinator

slide11
People - The Software Team

Mantie’s seven project factors related to project team structure:

- the difficulty of the problem to be solved.

- the size of the resultant programs

- the modularity of problem

- the reliability of the software

- the team life time

- the rigidity of the delivery date

- the degree of sociability (communication overhead)

Team Type DD CD CC

Difficulty High Low Low

Size Small Large Large

Team Life Time Long Short Short

Modularity Low High High

Reliability High High Low

Delivery date Lax Lax Strict

Sociability High Low Low

slide12
People - The Software Team

Constantine [CON’93] suggests four “organization paradigms”

for software engineering teams:

- A closed paradigm:

a team with a traditional hierarchy of authority (like CC)

- The random paradigm:

a team loosely and depends on individual initiative of the team members

- The open paradigm:

heavy communication + control structure like CC

- The synchronous paradigm:

relies on the nature compartmentalization of a problem + little active communications

Chief programmer team (by Harlan Mills described in Baker’s [BAK72]) :

a senior engineer (1), technical staff (2-5), a backup engineer,

support staff (e.g. technical writers), software librarian (1).

Book “Peopleware” by DeMarco and Lister discussed “jelled team”:

A jelled team is a group of people so strongly knit that the whole is

greater than the sum of the parts… They don’t need managed in a

traditional way, they don’t need to be motivated. They got momentum.

slide13
People - Coordination and Communication Issues

Many failure causes of a software project. Here are some of them related

to communications and coordination of a project:

- The large scale of development efforts

--> complexity, confusion, and significant difficulties in coordination of teams.

- Uncertainty is common due to the changes of requirements and team status

- Interoperability --> interoperations among systems

Good and effective formal and informal communication mechanisms:

- Formal impersonal approaches

documents, deliverables, memos, project milestones,

schedules, project control tools, change requests, and

related documents, error tracking reports and data.

- Formal, interpersonal procedures

quality assurance activities (code & design inspection, review meeting)

- Informal, interpersonal procedures

informal group meeting (such as meeting with customers and users)

- Electronic communication (email, web sites, video-based conference)

- Interpersonal network

slide14
Problem - Software Scope

A software project manager is confronted with a dilemma at the beginning

of a software engineering project.

- Software scope:

(a) Context:

- How does the software to be built fit into a large system, product, or business?

- What constraints are imposed as a result of the context?

(b) Information objectives:

- What customer-visible data objects are produced as output from the software?

- What data objects are required for input?

( c) Function and performance:

- What function does the software perform to transform input data into output?

- Are any special performance characteristics to be addressed?

slide15
Problem Decomposition

Problem decomposition --> problem partitioning.

Problem decomposition --> two areas:

- the functionality of the delivery software system

- the process that will be used to deliver the system

- Functional decomposition:

- Identify and define the functional scope of the system

in terms of functional features and/or sub-functional systems.

- Apply decomposition method on each feature.

An example of the function features for a word processing system:

- spell checking

- sentence grammar checking

- reference checking for large documents

- section and chapter reference validation for large documents.

slide16
Process - Melding the Problem and the Process

Each function to be engineered by the software team must pass through the set of framework activities:

- customer communication

- tasks to establish effective communications with customers.

- planning - tasks to define resources, timelines, an so on.

- risk analysis - tasks to assess both technical and management risks.

- engineering - tasks to build the application system

- construction and release - installation, release control, and customer support.

- customer evaluation - task to obtain customer feedback and evaluation result.

Process decomposition: - Select a software process model for the project.

- Define a preliminary project plan based on the set of common

process framework activities.

- Partition the software process based on the tasks and activities

common process framework (CPF)

slide17
Process - Process Decomposition

Each function to be engineered by the software team must pass through the set of framework activities:

- customer communication

- tasks to establish effective communications with customers.

- planning - tasks to define resources, timelines, an so on.

- risk analysis - tasks to assess both technical and management risks.

- engineering - tasks to build the application system

- construction and release - installation, release control, and customer support.

- customer evaluation - task to obtain customer feedback and evaluation result.

Process decomposition: - Select a software process model for the project.

- Define a preliminary project plan based on the set of common

process framework activities.

- Partition the software process based on the tasks and activities

common process framework (CPF)

slide18
Process - Process Decomposition

A small project may require the following work tasks:

- Develop list of clarification issues.

- Meet with customer to address clarification issues.

- Jointly develop a statement of scope.

- Review the state of scope with all concerned.

- Modify the statement of scope as required.

A complex project may require the following work tasks:

- Review the customer request.

- Plan and schedule a formal, facilitated meeting with the customer.

- Conduct research to define proposed solutions and existing approaches.

- Prepare a “working document” and an agenda for the formal meeting.

- Conduct the meeting.

- Jointly develop mini-spec for correctness, consistency, and lack of ambiguity.

- Assemble the min-specs into a scoping document.

- Review the scoping document with all concerned.

- Modify the scoping document as required.

ad