Project management l.jpg
This presentation is the property of its rightful owner.
Sponsored Links
1 / 18

Project Management PowerPoint PPT Presentation


  • 118 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Project Management

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 l.jpg

Project Management

Instructor: Dr. Jerry Gao


Project management2 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

People - The Software Team

DD:

group

CC:

Team leader

DC:

Team leader

secondary team leader

communication

group

group


Slide10 l.jpg

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 l.jpg

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 TypeDDCDCC

DifficultyHighLowLow

SizeSmallLargeLarge

Team Life TimeLongShortShort

ModularityLowHighHigh

ReliabilityHighHighLow

Delivery dateLaxLaxStrict

SociabilityHighLowLow


Slide12 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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.


  • Login