Published on

Published in: Business, Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Se

    1. 1. Project Management Concepts Sonali C. UDIT- SYBSc(IT) 2008-09
    2. 2. Assignment <ul><li>Q1 What are the different project factors used to structure the s/w? </li></ul>
    3. 3. People <ul><li>Senior managers : who define the business issues that often have significant influence on the project. </li></ul><ul><li>Project (technical) managers: who must plan, motivate, organize, and control the practitioners who do software work. </li></ul><ul><li>Practitioners: who deliver the technical skills that are necessary to engineer a product or application. </li></ul><ul><li>Customers: who specify the requirements for the software to be engineered . </li></ul><ul><li>End-users: who interact with the software once it is released for production use. </li></ul>
    4. 4. Software Team How to lead? How to organize? How to motivate? How to collaborate? How to create good ideas?
    5. 5. Team Leader/Project Manager <ul><li>Provides MOI (Model Of Leadership) </li></ul><ul><li>Motivation : The ability to encourage (by “push or pull”) technical people to produce to their best ability. </li></ul><ul><li>Organization : The ability to mold existing processes (or invent new ones) that will enable the initial concept to be translated into a final product. </li></ul><ul><li>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. </li></ul><ul><li>The Software project manager should concentrate on understanding the problem to be solved. </li></ul>
    6. 6. Characteristic of Effective Project Manager <ul><li>Project manager can diagnose the technical and organizational issues and solve the problems. </li></ul><ul><li>The project manager must let the team know that quality counts and that it will not be compromised. </li></ul><ul><li>The project manager must take charge of the project and allow good technical people to follow their instincts. </li></ul><ul><li>A manager must reward initiative and accomplishment and demonstrate through his own actions that controlled risk taking will not be punished. </li></ul><ul><li>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. </li></ul><ul><li>The manager must remain under control in high-stress situations. </li></ul>
    7. 7. Software Team Structure <ul><li>The following factors must be considered when selecting a software project team structure ... </li></ul><ul><ul><li>The difficulty of the problem to be solved </li></ul></ul><ul><ul><li>The size of the resultant program(s) in lines of code or function points </li></ul></ul><ul><ul><li>The time that the team will stay together (team lifetime) </li></ul></ul><ul><ul><li>The degree to which the problem can be modularized </li></ul></ul><ul><ul><li>The required quality and reliability of the system to be built </li></ul></ul><ul><ul><li>The rigidity of the delivery date </li></ul></ul><ul><ul><li>The degree of sociability (communication) required for the project </li></ul></ul>
    8. 8. Organization Paradigms <ul><li>closed paradigm: </li></ul><ul><ul><li>structures a team along a traditional hierarchy of authority. </li></ul></ul><ul><ul><li>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. </li></ul></ul><ul><li>random paradigm: </li></ul><ul><ul><li>structures a team loosely and depends on individual initiative of the team members. </li></ul></ul><ul><ul><li>When innovation or technological breakthrough is required, team following the random paradigm will excel. </li></ul></ul><ul><ul><li>But such teams may struggle when “Orderly Performance” is required. </li></ul></ul>
    9. 9. Organization Paradigms <ul><li>open paradigm: </li></ul><ul><ul><li>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. </li></ul></ul><ul><ul><li>Work is performed collaboratively. Heavy communication and consensus-based decision making are the trademarks of open paradigm teams. </li></ul></ul><ul><ul><li>Open paradigm team structure are well suited to the solution of complex problems but may not perform as efficiently as other teams. </li></ul></ul><ul><li>synchronous paradigm : </li></ul><ul><ul><li>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. </li></ul></ul>
    10. 10. Risk Analysis And Management
    11. 11. Project Risk <ul><li>What can go wrong? </li></ul><ul><li>What will the damage be? </li></ul><ul><li>What can be done? </li></ul>
    12. 12. SOFTWARE RISK <ul><li>Characteristic of risk: </li></ul><ul><ul><li>Loss </li></ul></ul><ul><ul><li>Uncertainty </li></ul></ul>
    13. 13. Risk Category <ul><li>Project risks </li></ul><ul><ul><li>Schedule will slip and costs will increase </li></ul></ul><ul><ul><li>Identify budge, schedule, personnel, resource, customer and requirements problems and the impact on the software project </li></ul></ul><ul><li>Technical risks </li></ul><ul><ul><li>Implementation becomes difficult </li></ul></ul><ul><ul><li>Identifies design , implementation, interface , maintenance problem </li></ul></ul>
    14. 14. <ul><li>Business risks </li></ul><ul><ul><li>Jeopardize the project </li></ul></ul><ul><li>Top 5 business risk are: </li></ul><ul><ul><li>Market Risk (building a product that actually no 1 wants) </li></ul></ul><ul><ul><li>Strategic Risk (building a product no longer fits into business strategy) </li></ul></ul><ul><ul><li>Sales Risk (sales force do not understand how to sell) </li></ul></ul><ul><ul><li>Management Risk (losing the support of senior management due to change in focus or change in people) </li></ul></ul><ul><ul><li>Budge Risk (losing budgetary or personnel commitments) </li></ul></ul>
    15. 15. <ul><li>Known Risk (that can be uncovered after careful evaluation of project plan) </li></ul><ul><li>Predictable Risk (can be predicted from past project experience) </li></ul><ul><li>Unpredictable Risk (they r extremely difficult to identify in advance) </li></ul>
    16. 16. Risk Identification <ul><li>Specify threats to project plan. </li></ul><ul><ul><li>Estimate, schedule, resource etc </li></ul></ul><ul><li>Method For identifying risks is to create Risk Item Check List </li></ul><ul><ul><li>Product size </li></ul></ul><ul><ul><li>Business impact </li></ul></ul><ul><ul><li>Customer characteristics </li></ul></ul><ul><ul><li>Process definition </li></ul></ul><ul><ul><li>Development environment </li></ul></ul><ul><ul><li>Technology to be built </li></ul></ul><ul><ul><li>Staff size and experience </li></ul></ul>
    17. 17. Risk Mitigation, Monitoring, Management <ul><li>mitigation—how can we avoid the risk? </li></ul><ul><li>monitoring—what factors can we track that will enable us to determine if the risk is becoming more or less likely? </li></ul><ul><li>management—what contingency plans do we have if the risk becomes a reality? </li></ul>