Project Management Concepts Sonali C. UDIT- SYBSc(IT) 2008-09
Assignment Q1 What are the different project factors used to structure the s/w?
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.
Software Team How to lead? How to organize? How to motivate? How to collaborate? How to create good ideas?
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.
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.
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
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.
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.
Risk Analysis And Management
Project Risk What can go wrong? What will the damage be? What can be done?
SOFTWARE RISK Characteristic of risk: Loss  Uncertainty
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
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)
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)
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
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?

Se

  • 1.
    Project Management ConceptsSonali C. UDIT- SYBSc(IT) 2008-09
  • 2.
    Assignment Q1 Whatare the different project factors used to structure the s/w?
  • 3.
    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.
  • 4.
    Software Team Howto lead? How to organize? How to motivate? How to collaborate? How to create good ideas?
  • 5.
    Team Leader/Project ManagerProvides 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.
  • 6.
    Characteristic of EffectiveProject 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.
  • 7.
    Software Team StructureThe 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
  • 8.
    Organization Paradigms closedparadigm: 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.
  • 9.
    Organization Paradigms openparadigm: 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.
  • 10.
  • 11.
    Project Risk Whatcan go wrong? What will the damage be? What can be done?
  • 12.
    SOFTWARE RISK Characteristicof risk: Loss Uncertainty
  • 13.
    Risk Category Projectrisks 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
  • 14.
    Business risks Jeopardizethe 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)
  • 15.
    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)
  • 16.
    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
  • 17.
    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?