Chapter 4


Published on

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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Planning: Hierarchy, top dictates the ones below it. Vision: How you differentiate activity from progress? (Beltway Activity Report- 400 miles, goal is to get to LA, failed) What are you trying to accomplish? You should have a vision for yourself? Your company? More than one page? Go do it again Ex: Eisenhower mission statement in the 2 nd world war: 1) Invade the continent of Europe 2) Defeat the German Army 3) Occupy the German Heartland A ton of details– got up every morning knowing his job. Pharmaceuticals--- Can’t have a vision that makes pharmaceuticals succeed. Has to be a pharmaceutical vision that American health succeed. Strategies: What do I have to do to make this Vision real. If you do all these things--- would you acocmplishyour vision Projects: Building blocks… they are the thing that makes the strategies real. (next page) Project: definition-- definable delegatable achievement. Process– Cooking Everytime you have an activity, define the results, not the activity. Monkey theory of management--- Every problem is a monkey. The goal of the meeting is to make sure everyone else has the monkey. Someone has to feed the monkey. Really good managers review who has what monkeys at the end of the day. Connie: You get what you inspect no what you accept. Tasks: What you do every day. Newt learns and he teaches. If you think about what you can do , you can get better at it. Typing and the Internet, etc. Retrain yourself--- this ask Answer phone, send emails, make speeches, practice getting better at and gives you an efficiency that busy you time and an effectiveness that allows you to get more things done. Hierarchy: You can do alone You can’t implement it yourself– you have to get people bought in Leadership Model The leading comes last Listening: People know more than you. Learn: Americans cheat: 1) glazed over– patients 2) Meeting, make your presentation, transitionally shut up, cheating: transactionally– shut up, developing your argument Appreciate Understanding: Why they are saving what they are saying and why it makes sense to them. Don’t need to sympathize and don’t need to agree. ( Ben Laden, good to know, and we’re still going to kill you) Helped: Land L leads to help: Feel better: Ventilate Asked Good questions New Info and facts, Prestige, Resource, Power and Authority that can help them If you LLH they will ask you to lead When they ask you, go back up This is my vision, these are my projects, these are my tasks, What do you think? You listen to them and then modified This is very hard…. Your first job is to listen You don’t tell them until they tell you Application: Secret: Shuttle diplomacy=== never get all the people in a room until their ready to move. Each person tells you what they think and then you WE used this model to voluntary get 375? Candidates to say YES not just as a platform but a CONTRACT, I will vote on this in the next 100 days. First time legislative body PROMISED to do 10 specific things. Example: Listen to the Goverrnors--- I need money. They want you or they want money--- you needed to deflect info. Litigation or Federal Govt. Your industry is not relevant to my problem Marketing vs. Selling article
  • Chapter 4

    1. 1. CIS 302 Introduction to Systems Analysis and Design Managing the Information Systems Project 2.3
    2. 2. Learning Objectives <ul><li>Discuss skills required to be an effective project manager </li></ul><ul><li>Describe skills and activities of a project manager during project initiation, planning, execution and closedown </li></ul><ul><li>Explain Gantt and Pert charts </li></ul><ul><li>Review commercial project management software packages </li></ul>2.4
    3. 3. Managing the Information Systems Project <ul><li>Focus of project management </li></ul><ul><ul><li>To ensure that information system projects meet customer expectations </li></ul></ul><ul><ul><ul><li>Delivered in a timely manner </li></ul></ul></ul><ul><ul><ul><li>Meet constraints and requirements </li></ul></ul></ul>2.5
    4. 4. <ul><li>Project Manager </li></ul><ul><ul><li>Systems Analyst responsible for </li></ul></ul><ul><ul><ul><li>Project initiation </li></ul></ul></ul><ul><ul><ul><li>Planning </li></ul></ul></ul><ul><ul><ul><li>Execution </li></ul></ul></ul><ul><ul><ul><li>Closing down </li></ul></ul></ul><ul><ul><li>Requires diverse set of skills </li></ul></ul><ul><ul><ul><li>Management </li></ul></ul></ul><ul><ul><ul><li>Leadership </li></ul></ul></ul><ul><ul><ul><li>Technical </li></ul></ul></ul><ul><ul><ul><li>Conflict management </li></ul></ul></ul><ul><ul><ul><li>Customer relations </li></ul></ul></ul>Managing the Information Systems Project 2.6
    5. 5. Project Management Process <ul><li>Project </li></ul><ul><ul><li>Planned undertaking of related activities to reach an objective that has a beginning and an end </li></ul></ul><ul><li>Four Phases </li></ul><ul><ul><li>Initiation </li></ul></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Execution </li></ul></ul><ul><ul><li>Closing down </li></ul></ul>2.7
    6. 6. Initiating the Project <ul><li>Establish project initiation team </li></ul><ul><li>Establish relationship with customer </li></ul><ul><li>Establish project initiation plan </li></ul><ul><li>Establish management procedures </li></ul><ul><li>Establish project management environment and workbook </li></ul>2.8
    7. 7. Planning the Project <ul><li>Describe project scope, alternatives and feasibility </li></ul><ul><ul><li>Scope and Feasibility </li></ul></ul><ul><ul><ul><li>Understand the project </li></ul></ul></ul><ul><ul><ul><li>What problem is addressed </li></ul></ul></ul><ul><ul><ul><li>What results are to be achieved </li></ul></ul></ul><ul><ul><ul><li>Measures of success </li></ul></ul></ul><ul><ul><ul><li>Completion criteria </li></ul></ul></ul>2.9
    8. 8. Planning the Project <ul><li>Divide the project into manageable tasks </li></ul><ul><ul><ul><li>Work breakdown structure </li></ul></ul></ul><ul><ul><ul><li>Gantt chart </li></ul></ul></ul><ul><li>Estimate resources and create a resource plan. </li></ul><ul><li>Develop a preliminary schedule </li></ul><ul><ul><ul><li>Utilize Gantt and PERT charts </li></ul></ul></ul>2.10
    9. 9. Planning the Project <ul><li>Develop a communication plan </li></ul><ul><ul><li>Outline communication processes among customers, team members and management </li></ul></ul><ul><ul><li>Types of reports </li></ul></ul><ul><ul><li>Frequency of reports </li></ul></ul><ul><li>Determine project standards and procedures </li></ul><ul><ul><li>Specify how deliverables are tested and produced </li></ul></ul>2.11
    10. 10. Planning the Project <ul><li>Identify and assess risk </li></ul><ul><ul><li>Identify sources of risk </li></ul></ul><ul><ul><li>Estimate consequences of risk </li></ul></ul><ul><li>Create a preliminary budget </li></ul><ul><li>Develop a statement of work </li></ul><ul><ul><li>Describe what the project will deliver </li></ul></ul><ul><li>Set a baseline project plan </li></ul><ul><ul><li>Estimate of project’s tasks and resources </li></ul></ul>2.12
    11. 11. Executing the Project <ul><li>Execute baseline project plan </li></ul><ul><ul><li>Acquire and assign resources </li></ul></ul><ul><ul><li>Train new team members </li></ul></ul><ul><ul><li>Keep project on schedule </li></ul></ul><ul><li>Monitor project progress </li></ul><ul><ul><li>Adjust resources, budget and/or activities </li></ul></ul>2.13
    12. 12. Executing the Project <ul><li>Manage changes to baseline project plan </li></ul><ul><ul><li>Slipped completion dates </li></ul></ul><ul><ul><li>Changes in personnel </li></ul></ul><ul><ul><li>New activities </li></ul></ul><ul><li>Maintain project workbook </li></ul><ul><li>Communicate project status </li></ul>2.14
    13. 13. Closing Down the Project <ul><li>Termination </li></ul><ul><ul><li>Types of termination </li></ul></ul><ul><ul><ul><li>Natural </li></ul></ul></ul><ul><ul><ul><ul><li>Requirements have been met </li></ul></ul></ul></ul><ul><ul><ul><li>Unnatural </li></ul></ul></ul><ul><ul><ul><ul><li>Project stopped </li></ul></ul></ul></ul><ul><ul><li>Documentation </li></ul></ul><ul><ul><li>Personnel Appraisal </li></ul></ul>2.15
    14. 14. Closing Down the Project <ul><li>Conduct post-project reviews </li></ul><ul><ul><li>Determine strengths and weaknesses of </li></ul></ul><ul><ul><ul><li>Project deliverables </li></ul></ul></ul><ul><ul><ul><li>Project management process </li></ul></ul></ul><ul><ul><ul><li>Development process </li></ul></ul></ul><ul><li>Close customer contract </li></ul>2.16
    15. 15. Representing and Scheduling Project Plans <ul><li>Gantt Charts </li></ul><ul><ul><li>Useful for depicting simple projects or parts of large projects </li></ul></ul><ul><ul><li>Show start and completion dates for individual tasks </li></ul></ul><ul><li>PERT Charts </li></ul><ul><ul><li>Show order of activities </li></ul></ul>2.17
    16. 16. Comparison of Gantt and PERT Charts <ul><li>Gantt </li></ul><ul><ul><li>Visually shows duration of tasks </li></ul></ul><ul><ul><li>Visually shows time overlap between tasks </li></ul></ul><ul><ul><li>Visually shows slack time </li></ul></ul><ul><li>PERT </li></ul><ul><ul><li>Visually shows dependencies between tasks </li></ul></ul><ul><ul><li>Visually shows which tasks can be done in parallel </li></ul></ul><ul><ul><li>Shows slack time by data in rectangles </li></ul></ul>2.19
    17. 17. Gantt and PERT Charts -- How to Proceed <ul><li>Steps </li></ul><ul><ul><li>Identify each activity </li></ul></ul><ul><ul><ul><li>Requirements Collection </li></ul></ul></ul><ul><ul><ul><li>Screen Design </li></ul></ul></ul><ul><ul><ul><li>Report Design </li></ul></ul></ul><ul><ul><ul><li>Database Design </li></ul></ul></ul><ul><ul><ul><li>User documentation </li></ul></ul></ul><ul><ul><ul><li>Software programming </li></ul></ul></ul><ul><ul><ul><li>Installation and testing </li></ul></ul></ul>2.20
    18. 18. Gantt and PERT Charts -- Continued <ul><ul><li>Determine time estimates and expected completion times for each activity. </li></ul></ul><ul><ul><li>Determine sequence of activities </li></ul></ul><ul><ul><li>Determine critical path </li></ul></ul><ul><ul><ul><li>Sequence of events that will affect the final project delivery date </li></ul></ul></ul>2.21
    19. 19. Commercial Project Management Software <ul><li>Many systems are available </li></ul><ul><li>Three activities required to use: </li></ul><ul><ul><li>Establish project start or end date </li></ul></ul><ul><ul><li>Enter tasks and assign task relationships </li></ul></ul><ul><ul><li>Select scheduling method to review project reports </li></ul></ul>2.22
    20. 20. Summary <ul><li>Skills of an effective project manager </li></ul><ul><li>Activities of project manager </li></ul><ul><ul><li>Initiation </li></ul></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Execution </li></ul></ul><ul><ul><li>Closedown </li></ul></ul><ul><li>Gantt and PERT Charts </li></ul><ul><li>Commercial PM Software </li></ul>2.23
    21. 21. Project Management: An Overview Managing Operations
    22. 22. Agenda <ul><ul><li>Focus </li></ul></ul><ul><ul><li>What is a Project? </li></ul></ul><ul><ul><li>What is Project Management? </li></ul></ul><ul><ul><li>Project Management Skills </li></ul></ul><ul><ul><li>Why is Project Management Needed? </li></ul></ul><ul><ul><li>Checklist for a Doomed Project </li></ul></ul><ul><ul><li>Leading Contributors to Project Success </li></ul></ul><ul><ul><li>The Cost of Failure: An Example </li></ul></ul>
    23. 23. Objectives <ul><li>Define a project. </li></ul><ul><li>Describe the phases of a project. </li></ul><ul><li>Define project management. </li></ul><ul><li>List project management skills. </li></ul><ul><li>Recognize the need for good project management. </li></ul><ul><li>Identify various reasons for project success and failure. </li></ul>
    24. 24. Course Focus <ul><li>We will focus on: </li></ul><ul><ul><li>IT project management, </li></ul></ul><ul><ul><li>Skills needed to succeed and, </li></ul></ul><ul><ul><li>The use of those skills for you career enhancement skills </li></ul></ul><ul><li>As a program Manager, technical or business skills alone will not carry the day. You must have a combination of knowledge to be successful in this endeavor. This course will continue to expand and enhance your existing skills in those areas. </li></ul>
    25. 25. Why Businesses Exist. <ul><li>First and foremost, businesses exist to maximize the value of their owners equity. </li></ul><ul><ul><li>Non-profits may have a definition of “value” that is not based on monetary worth, but they do what they do to increase that value. </li></ul></ul><ul><li>Successful businesses never loose this focus nor deviate from it in the development and execution of their business plans. </li></ul><ul><li>Methodologies may vary but the goal is constant. </li></ul><ul><li>DO NOT FORGET THIS! </li></ul>
    26. 26. Vision and Strategies <ul><li>Executives are tasked to develop Vision </li></ul><ul><ul><li>The Project manager is the tool to implement that Vision. </li></ul></ul><ul><ul><li>What is the goal? </li></ul></ul><ul><ul><li>Is it a strategic business goal or tactical objective? </li></ul></ul><ul><li>Strategic considerations for the creation of Vision are many. </li></ul><ul><li>The project manager must be given clear directions as to what that Vision is and a clear understanding of what the end result is. </li></ul><ul><ul><li>The Project(s) must be defined. </li></ul></ul>
    27. 27. So what makes a Project? <ul><li>Specific objectives – defines concisely what you are trying to do and what you will deliver….in detail. This will be to solve some problem. </li></ul><ul><li>Schedule – define specifically the duration of the effort </li></ul><ul><li>Budget – Identify what will be your budget and all variables and what you can and cannot control. </li></ul><ul><li>Resources – Identify who will do the work and commitments that those resources will be available. </li></ul>
    28. 28. So what makes a Project? <ul><li>One-time series of efforts rather than ongoing. </li></ul><ul><ul><li>To build a web site is usually considered a project that consists of multiple tasks. </li></ul></ul><ul><ul><li>Sample Tasks requiring business leadership </li></ul></ul><ul><ul><ul><li>Mission statement, Marketing plan, User thread definition, Finance, Business case analysis, others. </li></ul></ul></ul><ul><ul><li>Sample Tasks requiring technical leadership </li></ul></ul><ul><ul><ul><li>Content creation, page design, software selection, hardware selection, labor estimating, others. </li></ul></ul></ul>
    29. 29. Characteristics of a Project <ul><li>Sequence or phases of activities </li></ul><ul><li>Unique (Non-repetitive) </li></ul><ul><li>Simple and/or Complex </li></ul><ul><li>Inter-related activities </li></ul><ul><li>Specific Goal </li></ul><ul><li>Specific Time-frame </li></ul><ul><li>Specified Budget </li></ul><ul><li>Defined Specifications </li></ul>
    30. 30. Project Stages Scope Definition Scope Definition – Requirements & Business Analysis Planning Planning – Involves creating detailed, step by step plans Execution Execution – Execute the plan and only the plan. Closure Closure – Project review with a detailed lessons learned. Feedback Feedback Feedback Loops – During the Execution, as problems come up, take the issues back to the scope and planning stages as needed.
    31. 31. Who are the Project Players? <ul><li>The Sponsor – The individual who has requested that the project be undertaken. They usually get or provide the funding and face the executives. </li></ul><ul><ul><li>(Remember the golden rule: he who has the gold, rules) </li></ul></ul><ul><li>The Stakeholders – Those who are affected by the project and its implementation, </li></ul><ul><li>The Project Manager – The individual responsible for the management of the project. </li></ul><ul><li>Project Team – The grunts. Individuals tasked to perform the work identified in the project plan. </li></ul>
    32. 32. Why is Project Management Needed? <ul><li>To avoid </li></ul><ul><ul><li>High Failure rates and High Costs to the Enterprise. </li></ul></ul><ul><ul><li>30% of IT projects never reach fruitful conclusion </li></ul></ul><ul><ul><li>Waste – $75 billion annually </li></ul></ul><ul><ul><li>51% exceed budget by 189% and deliver only 74% functionality </li></ul></ul><ul><li>The Project Manager is tasked to avoid these problems. </li></ul><ul><li>On time, on budget, to specification </li></ul>
    33. 33. Leading Contributors to Project Success <ul><li>Effective Project Management </li></ul><ul><li>Formal guidelines </li></ul><ul><li>Accountable sponsors </li></ul><ul><li>Project management skills </li></ul><ul><li>Measurement systems </li></ul><ul><li>Formal priorities </li></ul><ul><li>Regular communication </li></ul><ul><li>Clear tracking </li></ul><ul><li>Automated tools </li></ul>
    34. 34. Why Projects Fail <ul><li>Lack of Scope Control </li></ul><ul><li>Poor requirements Definition </li></ul><ul><li>Schedule/Cost overruns </li></ul>
    35. 35. Leading Contributors to Project Failure <ul><li>Undisciplined project management </li></ul><ul><li>Poor requirements gathering in the initial stages of a project. </li></ul><ul><li>Poor communications between the IT and business side leading to different expectations. </li></ul><ul><li>Uncontrolled changes in project scope…. scope creep. </li></ul>
    36. 36. The Project Manager <ul><li>As a project manager, your execution of corporate strategy is accomplished by the efficient execution of individual projects. </li></ul><ul><li>There are tactical and political issues with each project. You will need to face them and overcome those challenges. </li></ul><ul><li>The primary skill that you will use is communications to those above you and those below you. </li></ul><ul><li>Communication requires that you listen as well as speak. </li></ul>
    37. 37. The Project Manager <ul><li>The key difference between a Program Manager and a Project Manager is usually a matter of scope and duration, depending on the corporation. </li></ul><ul><ul><li>A Program Manager usually has duties that are more comprehensive than managing, building and delivering a single or integrated solution. </li></ul></ul><ul><ul><li>Program Management often entails managing and transitioning a series of projects from inception to operational support and management. This could cover all aspects of a product line or service, from marketing to ILS and everything in between. </li></ul></ul>
    38. 38. The Project Manager <ul><li>A Project Manager is usually tasked with a more limited scope of work with a more finite duration. </li></ul><ul><ul><li>That duration is scheduled and not necessarily subject to market forces as is the case with a complete product line or program. </li></ul></ul><ul><ul><li>The following slides discuss Project Management though references will be made to Program Management in this context. </li></ul></ul>
    39. 39. Project Management Functions <ul><li>Staffing & Planning - A primary function of the Project Manager is to perform: </li></ul><ul><ul><li>staffing analysis, staffing acquisition (via HR or subcontracts) and/or requirements analysis and; </li></ul></ul><ul><ul><li>plan the performance and execution of the project. </li></ul></ul><ul><li>Organizing & Scheduling – Once the staffing and planning functions are identified, it is the project managers responsibility to organize those individuals into teams and schedule their work. This includes coordinating their work assignments with other Project and managers. </li></ul>
    40. 40. Project Management Functions <ul><li>Directing & Controlling –day to day operational direction is usually needed and required. </li></ul><ul><ul><li>As the project evolves, these skills become increasingly important. </li></ul></ul><ul><li>Tools and techniques- The organization, scheduling and controlling, as well as performance capturing and knowledge management functions are the responsibility of the Project Manager. </li></ul><ul><li>Providing feed back to executive management is key to the overall strategic implementation process. </li></ul>
    41. 41. Planning & Leadership Model VISION STRATEGIES TASKS Listen > Learn > Help > Lead PROJECTS A project is a definable delegatable achievement and the key to entrepreneurial rather than bureaucratic behavior. Appreciative understanding Leadership Model Feedback for Improvement
    42. 42. Staffing and Planning <ul><li>Develop a Plan </li></ul><ul><ul><li>Base the plan on System Development/Life Cycle (SDLC) and other process Activities </li></ul></ul><ul><ul><li>Solicit Resources to Deliver System </li></ul></ul><ul><li>Planning Considerations: </li></ul><ul><ul><li>What is required? </li></ul></ul><ul><ul><li>What resources are needed? </li></ul></ul><ul><ul><li>What is the duration? </li></ul></ul><ul><ul><li>What are the dependencies? </li></ul></ul>
    43. 43. Organizing and Scheduling <ul><li>Identify the Roles and Responsibilities. </li></ul><ul><li>Communicate with the Project Team - must understand tasks & dependencies. </li></ul><ul><li>Identify the Deliverables. </li></ul><ul><li>Prepare a Schedule to Match the Deadlines . </li></ul><ul><ul><li>Add resources </li></ul></ul><ul><ul><li>Move deadlines </li></ul></ul><ul><ul><li>Adjust scope </li></ul></ul>
    44. 44. Directing and Controlling <ul><li>PM acts as a Director or Leader </li></ul><ul><li>Makes Key Decisions </li></ul><ul><li>Motivates, Rewards - Traits of a Leader </li></ul><ul><li>Advises, Coordinates, Delegates & Appraises </li></ul><ul><li>Controls the Project...from Orientation to termination </li></ul>
    45. 45. Directing and Controlling <ul><li>Manage the Project </li></ul><ul><li>Status reports and reviews - project walk-through </li></ul><ul><li>Assess skills needed </li></ul><ul><li>Lead the Project Team </li></ul><ul><li>Involve team in planning </li></ul><ul><li>Track project using formal and informal methods </li></ul><ul><li>Set performance objectives and develop staff </li></ul>
    46. 46. The Project Manager Skills <ul><li>A Project Manager is usually associated with having the following skills: </li></ul><ul><ul><li>Detail Oriented. </li></ul></ul><ul><ul><li>Methodical. </li></ul></ul><ul><ul><li>Able to multi-task </li></ul></ul><ul><ul><li>Able to understand technical, business and financial issues. </li></ul></ul><ul><ul><li>Cognizant of political realities of the project. </li></ul></ul>
    47. 47. Project Management for Information Systems <ul><li>So, what is a project? </li></ul><ul><ul><li>A project has specific objectives, start and end dates, and a budget; requires resources; and has a definite life cycle. </li></ul></ul><ul><li>Who is a project manager? </li></ul><ul><ul><li>Someone who manages the project, ideally, from conception to completion. </li></ul></ul><ul><li>Common project management software tool include. </li></ul><ul><ul><li>Microsoft Project [] </li></ul></ul><ul><ul><li>Primavera [] </li></ul></ul><ul><ul><li>Others </li></ul></ul>
    48. 48. Project Management Certification Testing <ul><li>As a word of caution . For those who plan to eventually get certified as a project manager, there are some differences in what the answer the certifiers want on a test and the realities of the working world. </li></ul><ul><li>PMI and Gartner think that companies always have the project manager engaged during the first phases of a project (Requirements gathering). </li></ul><ul><li>Don’t bet on it. Requirements gathered and requirement realities my be two different things entirely. Don’t be complacent. </li></ul>
    49. 49. Project Management for Information Systems <ul><li>An IT project is different from non-IT project management because of the following: </li></ul><ul><ul><li>the work is harder to specify, </li></ul></ul><ul><ul><li>Requirements are more difficult to gather and, </li></ul></ul><ul><ul><li>designers are often the implementers. </li></ul></ul><ul><li>The two key factors that can make a project successful are; </li></ul><ul><ul><li>Regular communication with all participants and sponsors and, </li></ul></ul><ul><ul><li>Tracking resources and their tasks </li></ul></ul>
    50. 50. Most Projects Fail <ul><li>30% of IT projects never reach fruitful conclusion. </li></ul><ul><li>$75 billion is wasted annually. </li></ul><ul><li>51% of projects exceed budget by 189% and deliver only 74% functionality. </li></ul><ul><li>Reasons for this include: </li></ul><ul><ul><li>Undisciplined project management. </li></ul></ul><ul><ul><li>Poor communication between IT and business side. </li></ul></ul><ul><ul><li>Other reasons? </li></ul></ul>
    51. 51. Don’t Forget <ul><li>E-business isn’t just technology! </li></ul><ul><li>Simply having a working site doesn’t mean the project was a success. </li></ul><ul><li>Need to consider: </li></ul><ul><ul><li>Market reaction. </li></ul></ul><ul><ul><li>Response to customer needs. </li></ul></ul><ul><ul><li>On-time delivery, within budget and quality objectives. </li></ul></ul><ul><ul><li>Other ideas? </li></ul></ul>
    52. 52. Summary <ul><li>Program management </li></ul><ul><li>Components of a project </li></ul><ul><li>The interrelation of tasks </li></ul>
    53. 53. Break
    54. 54. Project Management <ul><li>Scope Management </li></ul>
    55. 55. Week 4 - Learning Objectives Scope Management <ul><li>You should be able to: </li></ul><ul><li>Discuss the relationship between scope and project failure </li></ul><ul><li>Explain how projects are initiated and selected </li></ul><ul><li>Define activities, inputs, and outputs of scope initiation, planning, definition, verification </li></ul><ul><li>Prepare a project charter </li></ul><ul><li>Prepare a WBS </li></ul>
    56. 56. Scope Management <ul><li>Processes needed to ensure that: </li></ul><ul><ul><li>project includes all required work </li></ul></ul><ul><ul><li>project includes only required work </li></ul></ul><ul><li>Product scope </li></ul><ul><ul><li>features and functions of product deliverables </li></ul></ul><ul><ul><li>measured against product requirements </li></ul></ul><ul><li>Project scope </li></ul><ul><ul><li>work that must be done to deliver them </li></ul></ul><ul><ul><li>measured against project plan </li></ul></ul>
    57. 57. Scope Management Processes <ul><li>Project Initiation </li></ul><ul><ul><li>commitment to next phase </li></ul></ul><ul><li>Scope Planning </li></ul><ul><ul><li>written scope statement </li></ul></ul><ul><li>Scope Definition: WBS </li></ul><ul><li>Scope Verification: formal acceptance </li></ul><ul><li>Scope Change Control </li></ul>
    58. 58. Scope Initiation <ul><li>New project, or, commitment to next phase of existing project </li></ul><ul><li>Inputs : </li></ul><ul><ul><li>product description/business need </li></ul></ul><ul><ul><li>strategic plan/goals </li></ul></ul><ul><ul><li>project selection criteria & methods </li></ul></ul><ul><ul><li>expert judgment, historical information </li></ul></ul>
    59. 59. Strategic Planning, Leading to Project Selection <ul><li>Business strategy and goals </li></ul><ul><li>IT systems help companies compete </li></ul><ul><li>Identify and prioritize opportunities </li></ul>Business Goals Selected Projects PotentialProjects Business Needs
    60. 60. Methods for Project Selection <ul><li>Organizational Need Perspective </li></ul><ul><ul><li>Perceived need? </li></ul></ul><ul><ul><li>Likelihood of funding? </li></ul></ul><ul><ul><li>Willingness to support? </li></ul></ul><ul><li>Source, time, impact, priority </li></ul><ul><ul><li>problem </li></ul></ul><ul><ul><li>opportunity </li></ul></ul><ul><ul><li>directive </li></ul></ul><ul><li>Financial Perspective </li></ul>
    61. 61. Financial Perspective <ul><li>Cost/benefit analysis </li></ul><ul><ul><li>NPV - net present value </li></ul></ul><ul><ul><li>ROI - return on investment </li></ul></ul><ul><ul><li>Payback analysis </li></ul></ul><ul><li>Limitations: difficulty of estimating </li></ul><ul><li>Weighted scoring model </li></ul><ul><ul><li>incorporates multiple criteria </li></ul></ul>
    62. 62. Weighted Scoring Model <ul><li>Determine criteria </li></ul><ul><li>Weight criteria by importance </li></ul><ul><li>Score each project on each criterion </li></ul><ul><li>Multiply scores by weights </li></ul><ul><li>Get overall score for each project </li></ul><ul><li>Select project with highest score </li></ul><ul><li>“ What-if” analysis may be helpful </li></ul>
    63. 63. Scope Initiation Outputs <ul><li>Project Charter </li></ul><ul><ul><li>Conceptual baseline </li></ul></ul><ul><li>Project Manager selected </li></ul><ul><li>Constraints </li></ul><ul><ul><li>factors that will limit the team’s options </li></ul></ul><ul><ul><li>e.g., fixed budget </li></ul></ul><ul><ul><li>e.g., contractual provisions </li></ul></ul><ul><li>Assumptions </li></ul>
    64. 64. Project Charter <ul><li>Formalizes existence of project </li></ul><ul><li>Provides direction on objectives </li></ul><ul><li>Signoff by key project stakeholders </li></ul><ul><li>Charter Components: </li></ul><ul><li>title, date </li></ul><ul><li>project manager </li></ul><ul><li>scope statement </li></ul><ul><li>summary of approach </li></ul><ul><li>roles and responsibilities matrix </li></ul><ul><li>sign-off </li></ul><ul><li>comments (assumptions, constraints) </li></ul>
    65. 65. Scope Planning <ul><li>Inputs to planning = outputs of initiation </li></ul><ul><ul><li>description and charter </li></ul></ul><ul><ul><li>constraints and assumptions </li></ul></ul><ul><ul><li>product description and analysis </li></ul></ul><ul><ul><li>cost/benefit analysis </li></ul></ul>
    66. 66. Scope Planning Outputs <ul><li>Written Scope Statement </li></ul><ul><ul><li>justification: business need </li></ul></ul><ul><ul><li>product description </li></ul></ul><ul><ul><li>project deliverables </li></ul></ul><ul><ul><li>quantifiable criteria for success </li></ul></ul><ul><li>Common understanding of project </li></ul>
    67. 67. Scope Definition <ul><li>Decomposition of project into more manageable components </li></ul><ul><ul><li>sufficiently detailed for tasks, estimation </li></ul></ul><ul><li>Helps improve estimation accuracy </li></ul><ul><li>Defines a baseline for measurement and control </li></ul><ul><li>Clarifies responsibilities </li></ul>
    68. 68. Work Breakdown Structure <ul><li>Analysis of work needed to complete project </li></ul><ul><li>Hierarchical breakdown of tasks </li></ul><ul><li>Provides basis for planning and change control </li></ul><ul><li>Can be organized around products or phases </li></ul><ul><li>Work package is lowest, detailed level </li></ul><ul><li>Requires involvement of project team and customers </li></ul><ul><li>Helps identify needed coordination </li></ul>
    69. 69. Approaches to Preparing a WBS <ul><li>Use formal templates if available </li></ul><ul><li>Use previous similar projects’ WBS </li></ul><ul><li>Top-down </li></ul><ul><ul><li>iteratively add levels of detail </li></ul></ul><ul><li>Bottom-up </li></ul><ul><ul><li>team members identify detailed tasks </li></ul></ul><ul><ul><li>tasks are aggregated and summarized </li></ul></ul><ul><ul><li>creates buy-in by project team </li></ul></ul><ul><li>Combination </li></ul>
    70. 70. WBS Principles <ul><li>A unit of work appears only once </li></ul><ul><li>Each unit of work responsibility is assigned to one person </li></ul><ul><li>Clear scope of each unit of work </li></ul><ul><li>WBS reflects how work will be done </li></ul><ul><ul><li>serves project team first </li></ul></ul><ul><li>Must be flexible to accommodate changes </li></ul>
    71. 71. Scope Verification <ul><li>Formal acceptance by stakeholders </li></ul><ul><li>Inputs : </li></ul><ul><ul><li>Work results from execution of project plan </li></ul></ul><ul><ul><li>Product documentation </li></ul></ul><ul><li>Inspection </li></ul><ul><li>Outputs : </li></ul><ul><ul><li>documented level of completion </li></ul></ul><ul><ul><li>documented acceptance </li></ul></ul>
    72. 72. Scope Control and Project Failure <ul><li>Project failure often due to scope getting out of control </li></ul><ul><ul><li>Did not understand requirements </li></ul></ul><ul><ul><li>Or, allowed requirements to grow </li></ul></ul><ul><li>On average, project scope increases 4-fold </li></ul><ul><li>“ Requirements (scope) creep” </li></ul><ul><ul><li>users see potential for automation, ask for more </li></ul></ul><ul><ul><li>users want new system for current jobs </li></ul></ul>
    73. 73. Reducing IT Project Scope Creep <ul><li>User involvement </li></ul><ul><ul><li>project selection: ensure sponsor </li></ul></ul><ul><ul><li>easy access to project information </li></ul></ul><ul><ul><li>users as member(s) of project team </li></ul></ul><ul><ul><li>regular meetings with users </li></ul></ul><ul><ul><li>co-location with users </li></ul></ul><ul><ul><li>focus on completion dates </li></ul></ul><ul><ul><li>prototyping, use cases, JAD, CASE </li></ul></ul>
    74. 74. Project Considerations <ul><li>Is infrastructure setup part of your project? </li></ul><ul><li>Assumptions </li></ul><ul><ul><li>What are you counting on? </li></ul></ul><ul><ul><li>These can be critical to identify </li></ul></ul><ul><ul><li>Resources expected: equip/people, approvals </li></ul></ul><ul><ul><li>Availability of partners, connections </li></ul></ul><ul><ul><li>Delineate key limits: </li></ul></ul><ul><ul><ul><li>System load: expect an maximum of 100 users </li></ul></ul></ul>
    75. 75. Estimation <ul><li>“ Predictions are hard, especially about the future”, Yogi Berra </li></ul><ul><li>2 Types: Lucky or Lousy? </li></ul>
    76. 76. Planning, Estimating, Scheduling <ul><li>What’s the difference? </li></ul><ul><li>Plan: Identify activities. No specific start and end dates. </li></ul><ul><li>Estimating: Determining the size & duration of activities. </li></ul><ul><li>Schedule: Adds specific start and end dates, relationships, and resources. </li></ul>
    77. 77. Project Planning: A 12 Step Program <ul><li>Set goal and scope </li></ul><ul><li>Select lifecycle </li></ul><ul><li>Set org./team form </li></ul><ul><li>Start team selection </li></ul><ul><li>Determine risks </li></ul><ul><li>Create WBS </li></ul><ul><li>Identify tasks </li></ul><ul><li>Estimate size </li></ul><ul><li>Estimate effort </li></ul><ul><li>Identify task dependencies </li></ul><ul><li>Assign resources </li></ul><ul><li>Schedule work </li></ul>
    78. 78. How To Schedule <ul><li>1. Identify “what” needs to be done </li></ul><ul><ul><li>Work Breakdown Structure (WBS) </li></ul></ul><ul><li>2. Identify “how much” (the size) </li></ul><ul><ul><li>Size estimation techniques </li></ul></ul><ul><li>3. Identify the dependency between tasks </li></ul><ul><ul><li>Dependency graph, network diagram </li></ul></ul><ul><li>4. Estimate total duration of the work to be done </li></ul><ul><ul><li>The actual schedule </li></ul></ul>
    79. 79. WBS & Estimation <ul><li>How did you feel when I asked </li></ul><ul><ul><li>“ How long will your project take?” </li></ul></ul><ul><li>Not an easy answer to give right? </li></ul><ul><li>At least not if I were are real customer on a real project </li></ul><ul><li>How can you manage that issue? </li></ul>
    80. 80. Partitioning Your Project <ul><li>You need to decompose your project into manageable chunks </li></ul><ul><li>ALL projects need this step </li></ul><ul><li>Divide & Conquer </li></ul><ul><li>Two main causes of project failure </li></ul><ul><ul><li>Forgetting something critical </li></ul></ul><ul><ul><li>Ballpark estimates become targets </li></ul></ul><ul><li>How does partitioning help this? </li></ul>
    81. 81. Work Breakdown Structure: WBS <ul><li>Hierarchical list of project’s work activities </li></ul><ul><li>2 Formats </li></ul><ul><ul><li>Outline (indented format) </li></ul></ul><ul><ul><li>Graphical Tree (Organizational Chart) </li></ul></ul><ul><li>Uses a decimal numbering system </li></ul><ul><ul><li>Ex: 3.1.5 </li></ul></ul><ul><ul><li>0 is typically top level </li></ul></ul><ul><li>Includes </li></ul><ul><ul><li>Development, Mgmt., and project support tasks </li></ul></ul><ul><li>Shows “is contained in” relationships </li></ul><ul><li>Does not show dependencies or durations </li></ul>
    82. 82. WBS <ul><li>Contract WBS (CWBS) </li></ul><ul><ul><li>First 2 or 3 levels </li></ul></ul><ul><ul><li>High-level tracking </li></ul></ul><ul><li>Project WBS (PWBS) </li></ul><ul><ul><li>Defined by PM and team members </li></ul></ul><ul><ul><li>Tasks tied to deliverables </li></ul></ul><ul><ul><li>Lowest level tracking </li></ul></ul>
    83. 83. A Full WBS Structure <ul><li>Up to six levels (3-6 usually) such as </li></ul><ul><li>Upper 3 can be used by customer for reporting (if part of RFP/RFQ) </li></ul><ul><li>Different level can be applied to different uses </li></ul><ul><ul><li>Ex: Level 1: authorizations; 2: budgets; 3: schedules </li></ul></ul>
    84. 84. WBS Chart Example
    85. 85. WBS Outline Example 0.0 Retail Web Site 1.0 Project Management 2.0 Requirements Gathering 3.0 Analysis & Design 4.0 Site Software Development 4.1 HTML Design and Creation 4.2 Backend Software 4.2.1 Database Implementation 4.2.2 Middleware Development 4.2.3 Security Subsystems 4.2.4 Catalog Engine 4.2.5 Transaction Processing 4.3 Graphics and Interface 4.4 Content Creation 5.0 Testing and Production
    86. 86. WBS Types <ul><li>Process WBS </li></ul><ul><ul><ul><li>a.k.a Activity-oriented </li></ul></ul></ul><ul><ul><ul><li>Ex: Requirements, Analysis, Design, Testing </li></ul></ul></ul><ul><ul><ul><li>Typically used by PM </li></ul></ul></ul><ul><li>Product WBS </li></ul><ul><ul><ul><li>a.k.a. Entity-oriented </li></ul></ul></ul><ul><ul><ul><li>Ex: Financial engine, Interface system, DB </li></ul></ul></ul><ul><ul><ul><li>Typically used by engineering manager </li></ul></ul></ul><ul><li>Hybrid WBS: both above </li></ul><ul><ul><ul><li>This is not unusual </li></ul></ul></ul><ul><ul><ul><li>Ex: Lifecycle phases at high level with component or feature-specifics within phases </li></ul></ul></ul><ul><ul><ul><li>Rationale: processes produce products </li></ul></ul></ul>
    87. 87. Process WBS
    88. 88. WBS Types <ul><li>Less frequently used alternatives </li></ul><ul><ul><li>Organizational WBS </li></ul></ul><ul><ul><ul><li>Research, Product Design, Engineering, Operations </li></ul></ul></ul><ul><ul><ul><li>Can be useful for highly cross-functional projects </li></ul></ul></ul><ul><ul><li>Geographical WBS </li></ul></ul><ul><ul><ul><li>Can be useful with distributed teams </li></ul></ul></ul><ul><ul><ul><li>NYC team, San Jose team, Off-shore team </li></ul></ul></ul>
    89. 89. Work Packages <ul><li>Generic term for discrete tasks with definable end results </li></ul><ul><li>Typically the “leaves” on the tree </li></ul><ul><li>The “one-to-two” rule </li></ul><ul><ul><ul><li>Often at: 1 or 2 persons for 1 or 2 weeks </li></ul></ul></ul><ul><li>Basis for monitoring and reporting progress </li></ul><ul><ul><ul><li>Can be tied to budget items (charge numbers) </li></ul></ul></ul><ul><ul><ul><li>Resources (personnel) assigned </li></ul></ul></ul><ul><li>Ideally shorter rather than longer </li></ul><ul><ul><ul><li>Longer makes in-progress estimates needed </li></ul></ul></ul><ul><ul><ul><li>These are more subjective than “done” </li></ul></ul></ul><ul><ul><ul><li>2-3 weeks maximum for software projects </li></ul></ul></ul><ul><ul><ul><li>1 day minimum (occasionally a half day) </li></ul></ul></ul><ul><ul><ul><li>Not so small as to micro-manage </li></ul></ul></ul>
    90. 90. WBS <ul><li>List of Activities, not Things </li></ul><ul><li>List of items can come from many sources </li></ul><ul><ul><li>SOW, Proposal, brainstorming, stakeholders, team </li></ul></ul><ul><li>Describe activities using “bullet language” </li></ul><ul><ul><li>Meaningful but terse labels </li></ul></ul><ul><li>All WBS paths do not have to go to the same level </li></ul><ul><li>Do not plan more detail than you can manage </li></ul>
    91. 91. WBS & Methodology <ul><li>PM must map activities to chosen lifecycle </li></ul><ul><li>Each lifecycle has different sets of activities </li></ul><ul><li>Integral process activities occur for all </li></ul><ul><ul><li>Planning, configuration, testing </li></ul></ul><ul><li>Operations and maintenance phases are not normally in plan (considered post-project) </li></ul><ul><li>Some models are “straightened” for WBS </li></ul><ul><ul><li>Spiral and other iterative models </li></ul></ul><ul><ul><li>Linear sequence several times </li></ul></ul><ul><li>Deliverables of tasks vary by methodology </li></ul>
    92. 92. WBS Techniques <ul><li>Top-Down </li></ul><ul><li>Bottom-Up </li></ul><ul><li>Analogy </li></ul><ul><li>Rolling Wave </li></ul><ul><ul><li>1 st pass: go 1-3 levels deep </li></ul></ul><ul><ul><li>Gather more requirements or data </li></ul></ul><ul><ul><li>Add more detail later </li></ul></ul><ul><li>Post-its on a wall </li></ul>
    93. 93. WBS Techniques <ul><li>Top-down </li></ul><ul><ul><li>Start at highest level </li></ul></ul><ul><ul><li>Systematically develop increasing level of detail </li></ul></ul><ul><ul><li>Best if </li></ul></ul><ul><ul><ul><li>The problem is well understood </li></ul></ul></ul><ul><ul><ul><li>Technology and methodology are not new </li></ul></ul></ul><ul><ul><ul><li>This is similar to an earlier project or problem </li></ul></ul></ul><ul><ul><li>But is also applied in majority of situations </li></ul></ul>
    94. 94. WBS Techniques <ul><li>Bottom-up </li></ul><ul><ul><li>Start at lowest level tasks </li></ul></ul><ul><ul><li>Aggregate into summaries and higher levels </li></ul></ul><ul><ul><li>Cons </li></ul></ul><ul><ul><ul><li>Time consuming </li></ul></ul></ul><ul><ul><ul><li>Needs more requirements complete </li></ul></ul></ul><ul><ul><li>Pros </li></ul></ul><ul><ul><ul><li>Detailed </li></ul></ul></ul>
    95. 95. WBS Techniques <ul><li>Analogy </li></ul><ul><ul><li>Base WBS upon that of a “similar” project </li></ul></ul><ul><ul><li>Use a template </li></ul></ul><ul><ul><li>Analogy also can be estimation basis </li></ul></ul><ul><ul><li>Pros </li></ul></ul><ul><ul><ul><li>Based on past actual experience </li></ul></ul></ul><ul><ul><li>Cons </li></ul></ul><ul><ul><ul><li>Needs comparable project </li></ul></ul></ul>
    96. 96. WBS Techniques <ul><li>Brainstorming </li></ul><ul><ul><li>Generate all activities you can think of that need to be done </li></ul></ul><ul><ul><li>Group them into categories </li></ul></ul><ul><li>Both Top-down and Brainstorming can be used on the same WBS </li></ul><ul><li>Remember to get the people who will be doing the work involved (buy-in matters!) </li></ul>
    97. 97. WBS – Basis of Many Things <ul><li>Network scheduling </li></ul><ul><li>Costing </li></ul><ul><li>Risk analysis </li></ul><ul><li>Organizational structure </li></ul><ul><li>Control </li></ul><ul><li>Measurement </li></ul>
    98. 98. WBS Guidelines Part 1 <ul><li>Should be easy to understand </li></ul><ul><li>Some companies have corporate standards for these schemes </li></ul><ul><li>Some top-level items, like Project Mgmt. are in WBS for each project </li></ul><ul><ul><li>Others vary by project </li></ul></ul><ul><li>What often hurts most is what’s missing </li></ul><ul><li>Break down until you can generate accurate time & cost estimates </li></ul><ul><li>Ensure each element corresponds to a deliverable </li></ul>
    99. 99. WBS Guidelines Part 2 <ul><li>How detailed should it be? </li></ul><ul><ul><li>Not as detailed as the final MS-Project plan </li></ul></ul><ul><ul><li>Each level should have no more than 7 items </li></ul></ul><ul><ul><li>It can evolve over time </li></ul></ul><ul><li>What tool should you use? </li></ul><ul><ul><li>Excel, Word, Project </li></ul></ul><ul><ul><li>Org chart diagramming tool (Visio, etc) </li></ul></ul><ul><ul><li>Specialized commercial apps </li></ul></ul><ul><li>Re-use a “template” if you have one </li></ul>
    100. 100. Estimations <ul><li>Very difficult to do, but needed often </li></ul><ul><li>Created, used or refined during </li></ul><ul><ul><li>Strategic planning </li></ul></ul><ul><ul><li>Feasibility study and/or SOW </li></ul></ul><ul><ul><li>Proposals </li></ul></ul><ul><ul><li>Vendor and sub-contractor evaluation </li></ul></ul><ul><ul><li>Project planning (iteratively) </li></ul></ul><ul><li>Basic process </li></ul><ul><ul><li>Estimate the size of the product </li></ul></ul><ul><ul><li>Estimate the effort (man-months) </li></ul></ul><ul><ul><li>Estimate the schedule </li></ul></ul><ul><ul><li>NOTE: Not all of these steps are always explicitly performed </li></ul></ul>
    101. 101. Estimations <ul><li>Remember, an “exact estimate” is an oxymoron </li></ul><ul><li>Estimate how long will it take you to get home from class tonight </li></ul><ul><ul><li>On what basis did you do that? </li></ul></ul><ul><ul><li>Experience right? </li></ul></ul><ul><ul><li>Likely as an “average” probability </li></ul></ul><ul><ul><li>For most software projects there is no such ‘average’ </li></ul></ul><ul><li>Most software estimations are off by 25-100% </li></ul>
    102. 102. Estimation <ul><li>Target vs. Committed Dates </li></ul><ul><ul><ul><li>Target: Proposed by business or marketing </li></ul></ul></ul><ul><ul><ul><li>Do not commit to this too soon! </li></ul></ul></ul><ul><ul><ul><li>Committed: Team agrees to this </li></ul></ul></ul><ul><ul><ul><li>After you’ve developed a schedule </li></ul></ul></ul>
    103. 103. Estimation Methodologies <ul><li>Top-down </li></ul><ul><li>Bottom-up </li></ul><ul><li>Analogy </li></ul><ul><li>Expert Judgment </li></ul><ul><li>Priced to Win </li></ul><ul><li>Parametric or Algorithmic Method </li></ul><ul><ul><li>Using formulas and equations </li></ul></ul>
    104. 104. Top-down Estimation <ul><li>Based on overall characteristics of project </li></ul><ul><ul><li>Some of the others can be “types” of top-down (Analogy, Expert Judgment, and Algorithmic methods) </li></ul></ul><ul><li>Advantages </li></ul><ul><ul><li>Easy to calculate </li></ul></ul><ul><ul><li>Effective early on (like initial cost estimates) </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Some models are questionable or may not fit </li></ul></ul><ul><ul><li>Less accurate because it doesn’t look at details </li></ul></ul>
    105. 105. Bottom-up Estimation <ul><li>Create WBS </li></ul><ul><li>Add from the bottom-up </li></ul><ul><li>Advantages </li></ul><ul><ul><li>Works well if activities well understood </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Specific activities not always known </li></ul></ul><ul><ul><li>More time consuming </li></ul></ul>
    106. 106. Expert Judgment <ul><li>Use somebody who has recent experience on a similar project </li></ul><ul><li>You get a “guesstimate” </li></ul><ul><li>Accuracy depends on their ‘real’ expertise </li></ul><ul><li>Comparable application(s) must be accurately chosen </li></ul><ul><ul><li>Systematic </li></ul></ul><ul><li>Can use a weighted-average of opinions </li></ul>
    107. 107. Estimation by Analogy <ul><li>Use past project </li></ul><ul><ul><li>Must be sufficiently similar (technology, type, organization) </li></ul></ul><ul><ul><li>Find comparable attributes (ex: # of inputs/outputs) </li></ul></ul><ul><ul><li>Can create a function </li></ul></ul><ul><li>Advantages </li></ul><ul><ul><li>Based on actual historical data </li></ul></ul><ul><li>Disadvantages </li></ul><ul><ul><li>Difficulty ‘matching’ project types </li></ul></ul><ul><ul><li>Prior data may have been mis-measured </li></ul></ul><ul><ul><li>How to measure differences – no two exactly same </li></ul></ul>
    108. 108. Priced to Win <ul><li>Just follow other estimates </li></ul><ul><li>Save on doing full estimate </li></ul><ul><li>Needs information on other estimates (or prices) </li></ul><ul><li>Purchaser must closely watch trade-offs </li></ul><ul><li>Priced to lose? </li></ul>
    109. 109. Algorithmic Measures <ul><li>Lines of Code (LOC) </li></ul><ul><li>Function points </li></ul><ul><li>Feature points or object points </li></ul><ul><li>Other possible </li></ul><ul><ul><li>Number of bubbles on a DFD </li></ul></ul><ul><ul><li>Number of of ERD entities </li></ul></ul><ul><ul><li>Number of processes on a structure chart </li></ul></ul><ul><li>LOC and function points most common </li></ul><ul><ul><li>(of the algorithmic approaches) </li></ul></ul><ul><li>Majority of projects use none of the above </li></ul>
    110. 110. Code-based Estimates <ul><li>LOC Advantages </li></ul><ul><ul><li>Commonly understood metric </li></ul></ul><ul><ul><li>Permits specific comparison </li></ul></ul><ul><ul><li>Actuals easily measured </li></ul></ul><ul><li>LOC Disadvantages </li></ul><ul><ul><li>Difficult to estimate early in cycle </li></ul></ul><ul><ul><li>Counts vary by language </li></ul></ul><ul><ul><li>Many costs not considered (ex: requirements) </li></ul></ul><ul><ul><li>Programmers may be rewarded based on this </li></ul></ul><ul><ul><ul><li>Can use: # defects/# LOC </li></ul></ul></ul><ul><ul><li>Code generators produce excess code </li></ul></ul>
    111. 111. LOC Estimate Issues <ul><li>How do you know how many in advance? </li></ul><ul><li>What about different languages? </li></ul><ul><li>What about programmer style? </li></ul><ul><li>Stat: avg. programmer productivity: 3,000 LOC/yr </li></ul><ul><li>Most algorithmic approaches are more effective after requirements (or have to be after) </li></ul>
    112. 112. Code Reuse & Estimation <ul><li>Does not come for free </li></ul><ul><li>Code types: New, Modified, Reused </li></ul><ul><li>If code is more than 50% modified, it’s “new” </li></ul><ul><li>Reuse factors have wide range </li></ul><ul><ul><li>Reused code takes 30% effort of new </li></ul></ul><ul><ul><li>Modified is 60% of new </li></ul></ul><ul><li>Integration effort with reused code almost as expensive as with new code </li></ul>
    113. 113. Effort Estimation <ul><li>Now that you know the “size”, determine the “effort” needed to build it </li></ul><ul><li>Various models: empirical, mathematical, subjective </li></ul><ul><li>Expressed in units of duration </li></ul><ul><ul><li>Man-months (or ‘staff-months’ now) </li></ul></ul>
    114. 114. COCOMO <ul><li>COnstructive COst MOdel </li></ul><ul><li>Allows for the type of application, size, and “Cost Drivers” </li></ul><ul><li>Outputs in Person Months </li></ul><ul><li>Cost drivers using High/Med/Low & include </li></ul><ul><ul><li>Motivation </li></ul></ul><ul><ul><li>Ability of team </li></ul></ul><ul><ul><li>Application experience </li></ul></ul><ul><li>Biggest weakness? </li></ul><ul><ul><li>Requires input of a product size estimate in LOC </li></ul></ul>
    115. 115. Estimation Issues <ul><li>Quality estimations needed early but information is limited </li></ul><ul><li>Precise estimation data available at end but not needed </li></ul><ul><ul><li>Or is it? What about the next project? </li></ul></ul><ul><li>Best estimates are based on past experience </li></ul><ul><li>Politics of estimation: </li></ul><ul><ul><li>You may anticipate a “cut” by upper management </li></ul></ul><ul><li>For many software projects there is little or none </li></ul><ul><ul><li>Technologies change </li></ul></ul><ul><ul><li>Historical data unavailable </li></ul></ul><ul><ul><li>Wide variance in project experiences/types </li></ul></ul><ul><ul><li>Subjective nature of software estimation </li></ul></ul>
    116. 116. Know Your Deadlines <ul><li>Are they ‘Real Deadlines’? </li></ul><ul><ul><li>Tied to an external event </li></ul></ul><ul><ul><li>Have to be met for project to be a success </li></ul></ul><ul><ul><li>Ex: end of financial year, contractual deadline, Y2K </li></ul></ul><ul><li>Or ‘Artificial Deadlines’? </li></ul><ul><ul><li>Set by arbitrary authority </li></ul></ul><ul><ul><li>May have some flexibility (if pushed) </li></ul></ul>
    117. 117. Other Estimation Notes <ul><li>Remember: “manage expectations” </li></ul><ul><li>Parkinson’s Law </li></ul><ul><ul><li>“Work expands to fill the time available” </li></ul></ul><ul><li>The Student Syndrome </li></ul><ul><ul><li>Procrastination until the last minute (cram) </li></ul></ul>