Se

17
Project Management Concepts Sonali C. UDIT- SYBSc(IT) 2008-09

Transcript of Se

Page 1: Se

Project Management Concepts

Sonali C.

UDIT- SYBSc(IT)

2008-09

Page 2: Se

Assignment

Q1 What are the different project factors used to structure the s/w?

Page 3: Se

People

Senior managers: who define the business issues that often have significant influence on the project.

Project (technical) managers: who must plan, motivate, organize, and control the practitioners who do software work.

Practitioners: who deliver the technical skills that are necessary to engineer a product or application.

Customers: who specify the requirements for the software to be engineered .

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

Page 4: Se

Software Team

How to lead?

How to organize?

How to motivate?

How to collaborate?

How to create good ideas?

Page 5: Se

Team Leader/Project Manager

Provides MOI (Model Of Leadership) Motivation: The ability to encourage (by “push or

pull”) technical people to produce to their best ability.

Organization: The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product.

Ideas or innovation: The ability to encourage people to create and feel creative even when they must work within bounds established for a particular software product or application.

The Software project manager should concentrate on understanding the problem to be solved.

Page 6: Se

Characteristic of Effective Project Manager Project manager can diagnose the technical and

organizational issues and solve the problems. The project manager must let the team know that

quality counts and that it will not be compromised. The project manager must take charge of the project

and allow good technical people to follow their instincts.

A manager must reward initiative and accomplishment and demonstrate through his own actions that controlled risk taking will not be punished.

An effective manager must be able to read people; he/she must be able to understand verbal and nonverbal signals and react to the needs of people sending these signals.

The manager must remain under control in high-stress situations.

Page 7: Se

Software Team Structure The following factors must be considered when

selecting a software project team structure ...•The difficulty of the problem to be solved•The size of the resultant program(s) in lines of

code or function points•The time that the team will stay together (team

lifetime)•The degree to which the problem can be

modularized•The required quality and reliability of the system

to be built•The rigidity of the delivery date•The degree of sociability (communication)

required for the project

Page 8: Se

Organization Paradigms closed paradigm:

• structures a team along a traditional hierarchy of authority.

• Such teams can work well when producing S/W that is quite similar to past efforts, but they will be less likely to be innovative when working within the closed paradigm.

random paradigm:• structures a team loosely and depends on individual

initiative of the team members.

• When innovation or technological breakthrough is required, team following the random paradigm will excel.

• But such teams may struggle when “Orderly Performance” is required.

Page 9: Se

Organization Paradigms open paradigm:

• attempts to structure a team in a manner that achieves some of the controls associated with the closed paradigm but also much of the innovation that occurs when using the random paradigm.

• Work is performed collaboratively. Heavy communication and consensus-based decision making are the trademarks of open paradigm teams.

• Open paradigm team structure are well suited to the solution of complex problems but may not perform as efficiently as other teams.

synchronous paradigm:• relies on the natural compartmentalization of a problem

and organizes team members to work on pieces of the problem with little active communication among themselves.

Page 10: Se

Risk AnalysisAnd

Management

Page 11: Se

Project Risk

What can go wrong? What will the damage be? What can be done?

Page 12: Se

SOFTWARE RISK

Characteristic of risk:• Loss

• Uncertainty

Page 13: Se

Risk Category

Project risks• Schedule will slip and costs will increase

• Identify budge, schedule, personnel, resource, customer and requirements problems and the impact on the software project

Technical risks• Implementation becomes difficult

• Identifies design , implementation, interface , maintenance problem

Page 14: Se

Business risks• Jeopardize the project

Top 5 business risk are:• Market Risk (building a product that actually no 1 wants)

• Strategic Risk (building a product no longer fits into business strategy)

• Sales Risk (sales force do not understand how to sell)

• Management Risk (losing the support of senior management due to change in focus or change in people)

• Budge Risk (losing budgetary or personnel commitments)

Page 15: Se

Known Risk (that can be uncovered after careful evaluation of project plan)

Predictable Risk (can be predicted from past project experience)

Unpredictable Risk (they r extremely difficult to identify in advance)

Page 16: Se

Risk Identification Specify threats to project plan.

• Estimate, schedule, resource etc Method For identifying risks is to create Risk Item Check List

• Product size• Business impact• Customer characteristics• Process definition• Development environment• Technology to be built• Staff size and experience

Page 17: Se

Risk Mitigation, Monitoring, Management

mitigation—how can we avoid the risk? monitoring—what factors can we track

that will enable us to determine if the risk is becoming more or less likely?

management—what contingency plans do we have if the risk becomes a reality?