CIS 3001 Midterm Study Guide SHIM GSU
CIS 3001 Midterm Study Guide SHIM GSU CIS 3001
Popular in Managing IT Projects
Popular in Computer Information Systems
This 21 page Study Guide was uploaded by Vraj Patel on Friday September 30, 2016. The Study Guide belongs to CIS 3001 at Georgia State University taught by Dr. Shim in Fall 2016. Since its upload, it has received 4 views. For similar materials see Managing IT Projects in Computer Information Systems at Georgia State University.
Reviews for CIS 3001 Midterm Study Guide SHIM GSU
Report this Material
What is Karma?
Karma is the currency of StudySoup.
You can buy or earn more Karma at anytime and redeem it for class notes, study guides, flashcards, and more!
Date Created: 09/30/16
CIS 3001 Midterm Study Guide Ø Information Technology (IT) projects are organizational investments that require ¡ Time, money, and other resources such as people, technology, facilities etc. Ø Organizations expect some type of value in return for this investment (ROI) Ø IT Project Management is a relatively new discipline that attempts to make IT projects more successful and combines traditional Project Management with Software Engineering/Management Information Systems Ø An ITPM (IT Project Management) Approach ¡ Organizational resources are limited, so organizations must choose among competing interests to fund specific projects ¡ This decision should be based on the value a competing project will provide to an organization Ø Modern Project Management ¡ Often credited to the U.S. Navy as an outgrowth of the Polaris Missile Project in the 1950s ¡ Focuses on reducing costs & product cycle time. ¡ Provides an important link between an organization’s strategy and the deployment of that strategy o Can have a direct impact on an organization’s bottom line and competitiveness Ø Why Many Projects Fail: Project Failure can be grouped into four categories (examples) ¡ People – The stakeholders of a project with varied roles and interests in the project’s success or failure. o Lack of Top management support, Ineffective user involvement, Lack of skills, Lack of experience, Poor communication, Poorly defined roles and responsibilities, poor decisions. ¡ Processes – This includes having a set of project management and product management processes. o Poorly defined goals and objectives, poor planning, lack of controls, poorly defined requirements, inadequate testing, poor execution ¡ Technology – Only 3% of IT project failures can be attributed to technical challenges but this percentage can be increased if obsolete, unproven, or incompatible technologies are used. o Obsolete, Unproven, Incompatible ¡ Organization – Organizational issues can lead to project failure. A lack of clear direction, improper strategy, rapidly changing business environment and/or customer needs can create a moving target for the product’s product or service. o Lack of Direction, changing priorities, lack of funding, competition for funding, bureaucracy, lack of oversight, Poor Change management. Ø The Software Crisis ¡ The CHAOS Study published in 1995 by The Standish Group found that although the U.S spent over $250 billion on IT projects … approximately: ¡ 31% were cancelled before completion ¡ 53% were completed but overbudget, over schedule, & did not meet original specifications o For mid-size companies, average cost overruns were 182%, while average schedule overruns were 202%! Ø Has the Current State of IT Projects Changed Since 1994? ¡ The Standish Group has continued to study IT projects over the years. ¡ IT Projects are showing higher success rates due to: o Better project management tools & processes, Smaller projects, improved communication among stakeholders, More skillful IT project managers ¡ But there is still ample opportunity for improvement! Ø IT Project Success Criteria ¡ Schedule: 61.3% said it is more important to deliver a system when it is ready to be shipped than to deliver it on time. ¡ Scope: 87.3% said that meeting the actual needs of stakeholders is more important than building the system to specification. ¡ Money: 79.6% said that providing the best return on investment (ROI) is more important than delivering a system under budget. ¡ Quality: 87.3% said that delivering high quality is more important than delivering on time and on budget ¡ Staff: 75.8% said that having a mentally and physically healthy workplace is more important than delivering on time and on budget Ø Improving the Likelihood of Success ¡ A Value-Driven Approach o Plain & Simple: IT Projects must provide value to the organization ¡ Socio-technical Approach o It’s not just about the technology or building a better mouse trap ¡ Project Management Approach o processes and infrastructure (Methodology) o resources o expectations o competition o efficiency and effectiveness ¡ Knowledge Management Approach o lessons learned, best practices & shared knowledge Ø The PMBOK® Guide’s Definitions for Project and Project Management ¡ A project is a temporary endeavor undertaken to create a unique product, service, or result. ¡ Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements. ¡ A project manager is the person assigned by the performing organization to achieve the project objectives Ø The Context of Project Management – Project Attributes ¡ Time Frame ¡ Purpose (to provide value!) ¡ Ownership ¡ Resources (the triple constraint) ¡ Roles o Project Manager o Project Sponsor o SME (Subject Matter Expert - domain & technical) ¡ Risk & Assumptions ¡ Interdependent Tasks o Progressive elaboration – steps & increments ¡ Planned Organizational Change ¡ Operate in Environments Larger than the Project Itself Ø The Project Management Body of Knowledge (PMBOK®) ¡ The Guide to the Project Management Body of Knowledge (PMBOK® Guide) documents 9 project management knowledge areas ¡ The PMBOK® Guide is published and maintained by the Project Management Institute (PMI) http://www.pmi.org ¡ PMI provides a certification in project management called the Project Management Professional (PMP) that many people today believe will be as relevant as a CPA certification ¡ PMP certification requires that you pass a PMP certification exam to demonstrate understanding about project management, as well as satisfy education & experience requirements and agree to a professional code of conduct Ø What is Project Management? ¡ Project Management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements. ¡ Project Portfolio – a collection of diverse projects managed collectively to align with the organization’s strategy and overall plan to achieve competitive advantage. ¡ Program – a collection of projects within a project portfolio whose activities are coordinated so that the benefits of the program are great than the sum of the benefits of the individual projects. Chapter 2 Ø Information Technology Project Methodology (ITPM) ¡ Methodology o A strategic-level plan for managing and controlling the project o Game plan for implementing project and product lifecycles o Recommends phases, processes, tools, and techniques for supporting an IT project o Must be flexible and include “best practices” learned from experiences over time. ¡ Can be: o Traditional (e.g., Waterfall) o Agile (e.g., XPM, SCRUM) Ø The Project Life Cycle and IT Development Ø Project Life Cycle ¡ Collection of logical stages or phases that maps the life of a project from its beginning to define, build, and deliver the product ¡ Each phase should provide one or more deliverables Ø Deliverable ¡ Tangible and verifiable product of work ¡ Project plan, design specifications, delivered system Ø Project Phases ¡ Phase Exits, Stage Gates, Kill Points o These are the phase-end review of key deliverables o Allows the organization to evaluate project performance and take immediate action to correct errors or problems ¡ Fast Tracking o Starting the next phase of a project before approval is obtained for the current phase o Can be used to reduce the project schedule o Can be risky and should only be done when the risk is acceptable Ø Project time line ¡ Start: Define project goal > plan project > ececute project plan> close project > evaluate project: Finish Ø Define Project Goal ¡ The project goal should be focused on providing business value to the organization ¡ Provides a clear focus and drives the other phases of the project ¡ How will we know if this project is successful given the time, money, and resources invested? Ø Plan Project ¡ Defines the agreed upon scope, schedule, and budget ¡ Used as a tool to gauge the project’s performance throughout the life cycle. Ø Execute Project Plan ¡ Manage the project scope, schedule, budget, and people to ensure the project achieves its goal ¡ Progress must be documented and compared to the baseline plan ¡ Project performance must be communicated to all of the stakeholders Ø Close Project ¡ Ensures that all of the work is completed as planned ¡ Final project report and presentation to the client Ø Evaluate Project ¡ Lessons learned to determine those things to do the same and those things to change ¡ Evaluate team member performance (e.g., the goal of the e-commerce site may be to produce $250K in revenue within 6 months) ¡ May be audited by an outside third party (e.g., partner, senior manager) Ø Systems Development Life Cycle (SDLC) ¡ Planning o Identifying and responding to a problem or opportunity o Incorporates the project management and system development processes and activities o Ensures that the goal, scope, budget, schedule, technology, and system development processes, methods, and tools are in place ¡ Analysis o A closer look at the problem or opportunity o Documents the specific needs and requirements for the new system ¡ Design o The project team uses the requirements and “to be” logical models to design the architecture to support the new information system o This includes designing the network, hardware configuration, databases, user interface, and application programs ¡ Implementation o The development or construction of the system, testing, and installation o Training, support, and documentation must also be in place. ¡ Maintenance and Support o The system is updated to respond to bugs, new features, or to adjust to a changing business environment ¡ Phases o Phase 1: Conceptualize and Initialize o Phase 2: Develop the Project Charter and Detailed Project Plan defined in terms of projects: ¡ Scope, schedule, budget, quality objectives o Phase 3: Execute and Control the Project using approach such as the SDLC. o Phase 4: Close Project o Phase 5: Evaluate Project Success ¡ Post mortem by project manager and team of entire project ¡ Evaluation of team members by project manager ¡ Outside evaluation of project, project leader, and team members ¡ Evaluate project’s organizational value o Project Management Processes ¡ Initiating processes ¡ Planning processes ¡ Executing processes ¡ Controlling processes ¡ Closing processes Ø IT Project Management Foundation ® ¡ Tools - e.g. Microsoft Project , Computer Aided Software Engineering (CASE) ¡ Infrastructure o Organizational Infrastructure o Project Infrastructure ¡ Project Environment ¡ Roles and Responsibilities of team members ¡ Processes and Controls o Technical Infrastructure ¡ Project Management Knowledge Areas ( 9 areas) Ø The Business Case ¡ Definition of Business Case: an analysis of the organizational value, feasibility, costs, benefits, and risks of the project plan. ¡ Attributes of a Good Business Case o Details all possible impacts, costs, and benefits o Clearly compares alternatives o Objectively includes all pertinent information o Systematic in terms of summarizing findings Ø Developing the Business Case ¡ An IT project may be undertaken to reduce costs; create a new product/service; improve customer service, communication, decision making; create relationships with customers; improve process, etc. ¡ Step 1: Select the Core Team ¡ Advantages: o Credibility o Alignment with organizational goals o Access to the real costs o Ownership o Agreement o Bridge building ¡ Step 2: Define Measurable Organizational Value (MOV) - the project’s overall goal o The project’s goal o -Must be measurable o -Provides value to the organization o -Must be agreed upon o -Must be verifiable at the end of the project ¡ Process for Developing the MOV: Identify the desired area of impact o 1.Potential Areas of Impact: ¡ Strategic, Customer, Financial, Operational, Social o 2.Identify the desired value of the IT project ¡ Organizational Value: Better? Faster? Cheaper? ¡ Do More? (growth or expansion) o 3. Develop an Appropriate Metric ¡ Should it increase or decrease? ¡ Metrics: Money ($, £, ¥ ), Percentage (%), Numeric Values (500 new customers) ¡ Set a time frame for achieving the MOV ¡ When will the MOV be achieved? o 4. Set a time frame for achieving the MOV ¡ When will the MOV be achieved? o 5. Verify and get agreement from the project stakeholders ¡ Project manager and team can only guide the process o 6. Summarize the MOV in a clear, concise statement or table ¡ Step 3: Identify Alternatives o Base Case Alternative o Possible Alternative Strategies ¡ Change existing process without investing in IT ¡ Adopt/Adapt systems from other organizational areas ¡ Reengineer Existing System ¡ Purchase off-the-shelf Applications package ¡ Custom Build a New Application ¡ Step 4: Define Feasibility and Assess Risk o Economic feasibility o Technical feasibility o Organizational feasibility o Other feasibilities (legal, ethical) ¡ Risk focus on: Identification, Assessment, Response ¡ Step 5: Define Total Cost of Ownership (TCO) o Direct or Up-front costs – hardware/software/telecom o Ongoing Costs – salaries, training, upgrade o Indirect Costs ¡ Step 6: Define Total Benefits of Ownership (TBO) o Increasing high-value work o Improving accuracy and efficiency o Improving decision-making o Improving customer service ¡ Step 7: Analyze alternatives using financial models (Payback, Breakeven, ROI, NPV) and scoring model ¡ Payback: Payback period = Initial investment/ Net cash flow $100,000 / $20,000 = 5 years o Breakeven Point = Initial Investment / Net Profit Margin o Return on Investment: Project ROI =(total expected benefits – total expected costs)/ total expected costs = ($115,000 - $100,000)/$100,000 = 15% t ¡ Net Present Value: NPV = -I +0Σ (Net Cash Flow / (1 + r)) o Where: I = Total Cost or Investment of the Project r = discount rate t = time period o ¡ Step 8: Propose and Support the Recommendation Ø Project Selection and Approval o The IT Project Selection Process § The Project Selection Decision § Project must map to organization goals § Project must provide verifiable MOV § Selection should be based on diverse measures such as • tangible and intangible costs and benefits • various levels throughout the organization Ø Reasons Balanced Scorecard Approach Might Fail ¡ Non-financial variables incorrectly identified as primary drivers ¡ Metrics not properly defined ¡ Goals for improvements negotiated not based on requirements ¡ No systematic way to map high-level goals ¡ Reliance on trial and error as a methodology ¡ No quantitative linkage between non-financial and expected financial results Chapter 3 Ø The Project Infrastructure ¡ Up to this point, we’ve looked at IT Project Management from a very high or strategic level. ¡ The basic question when conceptualizing and initializing the project is, “What is the value of this Project to the Organization?” Making the right decision is critical. ¡ The development of the business case (i.e., Conceptualizing and Initializing) à Develop the Project Charter and Plan (i.e., Requiring the planning, creating, review and acceptance of another project) [Important transition from a strategic mindset to a tactical one] à to make up a project governance framework (or infrastructure) ¡ In the project management context, integration includes characteristics of: unification, consolidation, articulation, and integrative actions that are crucial to project completion, successfully managing stakeholder expectations, and meeting requirements. ¡ Project Integration Management entails making choices about resource allocation, making trade-offs among competing objectives and alternatives, and managing the interdependencies among the project management Knowledge Areas. Ø Project Integration Processes (6) ¡ Develop Project Charter ¡ Develop Project Management Plan ¡ Direct and Manage Project Execution ¡ Monitor and Control Project Work (preventive, corrective) ¡ Perform Integrated Change Control ¡ Close Project or Phase Ø Process: A set of interrelated actions and activities performed to achieve a pre-specified product, result, or service Ø Projects vs. Processes ¡ Processes are ongoing (processes are an integral component of project management) Ø Project Management Process Groups ¡ Initiating: Signals the beginning of the project or a phase ¡ Planning: Supports planning of the entire project and each individual phase ¡ Executing: Focuses on integrating people and resources to carry out the planned activities of the project plan or phase ¡ Monitoring and Controlling: Allows for managing and measuring progress towards the project’s MOV and scope, schedule, budget, and quality objectives. Also allows the project manager and team to measure and keep an eye on project variances between actual and planned results so that appropriate corrective actions can be taken when necessary. ¡ Closing: Provides a set of processes for formally accepting the project’s product, service, or end result so that the project or phase can be brought to an orderly end Ø Product-Oriented Processes ¡ Defines how the Systems Development Life Cycle (SDLC) will be implemented. ¡ This will then define all of the sub-phases and deliverables associated with the Execute and Control project management life cycle phase. Ø Implementing the SDLC ¡ Implementation method will depend upon the size and complexity of the project as well as the experience and skills of the project team. ¡ This will be a critical factor for developing the project plan in terms of project phases, deliverables, tasks, and resources that will be used to estimate the project’s schedule and budget. ¡ Can use a structured development approach or an iterative development approach. Ø Structured Development Approach (since the 60s and 70s) ¡ The Waterfall Model was developed as a simple and disciplined method for systems development. ¡ Stresses a sequential and logical flow of software development activities (Define Requirements àDesignàBuild/CodingàTestàImplementàMaintenance). ¡ Detailed planning makes estimating easier. ¡ More suitable for large, complex systems. ¡ May also work well when the project team is less experienced or less technically competent. Ø Iterative Systems Development ¡ Focuses on shortening the SDLC by embracing the idea that requirements are difficult to define and will change over time. ¡ Emphasizes using working software to measure progress. ¡ Relies heavily upon face-to-face communication. Ø Iterative Approaches to Systems Development ¡ Rapid Application Development (RAD) ¡ Attempts to compress the analysis, design, build, and test activities of the SDLC into a series of short iterations or development cycles. ¡ Prototyping ¡ The user and developer work together to develop a partially or fully functional system as soon as possible. ¡ A prototype may be developed to discover or refine system requirement specifications ¡ Spiral Development o Breaks up a software project into a number of mini-projects that address one or more major risks. o Identifies risks as each iteration is completed. ¡ Agile Systems Development o SCRUM, Dynamic Systems Development Method (DSDM), Adaptive Software Development (ASD), eXtreme Programming (XP). o Releases are developed through several iteration. o Each working release is transferred to users. Ø The Project Charter ¡ Together with the baseline project plan, provides a tactical plan for carrying out the project ¡ Serves as an agreement or contract between the project sponsor and team ¡ Provides a framework for project governance Ø The MOV ¡ Define the Project’s Scope o Initiation o Planning o Definition o Verification o Change Control Ø Project Planning Framework ¡ Subdivide the Project into Phases ¡ Tasks-Sequence, Resources, and Time Estimates o Sequence o Resources o Time ¡ Schedule and Budget-The Baseline Plan Ø The Kick-Off Meeting ¡ Officially starts the work on the project ¡ Brings closure to the planning phase ¡ Communicates to all what the project is about ¡ Energizes stakeholders ¡ Engenders positive attitudes Chapter 5 Defining and managing project and product scope Ø Project planning framework o MOV> scope>phases>tasks> (sequence,resources,time estimates,)>(schedule and budget) Ø Scope management plan/Processes o Collect Requirements: Centers on defining and documenting the stakeholders’ ( the client’s) needs to properly manage expectations o Define Scope: A detailed description of project and the product. It should define what work will and will not be included in the project. (i.e., Project deliverables) o Create Work Breakdown Structure (WBS): The decomposition or dividing of the major project deliverables into smaller and more manageable components o Verify Scope: Confirmation and formal acceptance that project’s scope is accurate, complete, and supports the project’s goal o Control Scope: Ensuring that controls are in place to manage proposed scope changes one the project’s scope is accepted. These procedures must be communicated and understood by all project stakeholders. Ø Scope Planning o Initiating process to begin defining and documenting the project work (i.e., deliverables) needed to achieve the project’s MOV § Extra work that will not help the project achieve it’s MOV will only needlessly increase the project’s schedule and budget o This process begins at a high level and will become more detailed as the project progresses and more information becomes available o Attempts to answer the question: What is and what is not to be delivered by this project? § Makes the project sponsor’s needs and expectations explicit o Tools: § Scope Boundary § Scope Statement Ø Scope Boundary: having a clear/agreed-upon definition of the project MOV is critical for managing the scope boundary Ø Statement of work (SOW) o Narrative description of the product, service, or information system. o For internal projects, this is tied to the business need o For external projects, this would include specifications, quantities, quality standards, and performance requirements for prospective bidders (SOW is included in RFP) Ø Scope Statement o Develop a proactive electronic commerce strategy that identifies the processes, products and services to be delivered through the World Wide Web. o Develop an application system that supports all of the processes, products, and services identified in the electronic commerce strategy. o The application system must integrate with the bank’s existing enterprise resource planning system (ERP). Ø Out of Scope (for the project) o Technology and organizational assessment of the current environment o Customer resource management and data mining components Ø Project Scope Definition o The scope boundary and scope statement provide a useful first step o The project’s scope must now be defined in more detail in terms of specific deliverables that provide a basis for developing the project’s work breakdown structure (WBS) o Tools: § Deliverable Definition Table § Deliverable Structure Chart § Context Level Data Flow Diagram § Use Case Diagram Ø Scope o Project-Oriented Deliverables § Support the project management and IT development processes defined in the Information Technology Project Methodology (ITPM). § Tools • Deliverable Definition Table (DDT) • Deliverable Structure Chart (DSC) o Product-Oriented Deliverables § Specific features and functionality of the application system § First cut of requirements definition § Tools • Context Dataflow Diagram (DFD) • Use Case Diagram (UCD) Ø Project Scope Verification o MOV § Has the project’s MOV been clearly defined and agreed upon? o Deliverables § Are the deliverables tangible and verifiable? § Do they support the project’s MOV? o Quality Standards o Milestones § Significant events that mark the acceptance of a deliverable o Review and Acceptance § Formal Signoff Ø Scope Change Control o Concerned with managing changes to the project’s scope and to ensure that these changes are beneficial when they occur o Mitigates: § Scope Grope § Scope Creep § Scope Leap o Tools/Procedures: § Scope Change Request Form § Scope Change Request Log Ø Benefits of scope Control o Keeps the project manager in control of the project. § Authorized changes to the project’s scope are reflected in changes to the project’s schedule and budget. o Allows the project team to stay focused and on track § They do not have to perform unnecessary work Chapter 6 The Work breakdown structure and project estimation Ø Project time management PMBOK o Define Activities § Identifying what activities must be completed to produce the project scope deliverables o Sequence Activities § Determining whether activities can be completed sequentially or in parallel and any dependencies that may exist among them o Estimate Activity Resources § Identifying the type of resources (people, technology, facilities, etc.) and the quantity of resources needed to carry out project activities o Estimate Activity Durations § Estimating the time to complete each activity o Develop Schedule § Based on the availability of resources, the activities, their sequence, and time estimates, a schedule for the entire budget can be developed o Control Schedule § Ensuring that proper processes and procedures are in place in order to control changes to the project schedule o Work Breakdown Structure (WBS) § The WBS represents a logical decomposition of the work to be performed and focuses on how the product, service, or result is naturally subdivided. It is an outline of what work is to be performed Ø Deliverables vs. Milestones o Deliverables § Tangible, verifiable work products • Reports, presentations, prototypes ect o Milestones § Significant events or achievements § Acceptance of deliverables or phase completion § Cruxes (proof of concepts) § Quality control § Keeps team focused Ø Developing the WBS o A work package is developed for each of the phases and deliverables defined in the Deliverable Structure Chart (DSC) Ø Deliverable: Test Results Report o Logical Activities: § Review the test plan with the client so that key stakeholders are clear as to what will be tested, how the tests will be conducted, and when the tests will be carried out. § Carry out the tests as outlined in the plan. § Once the test results are collected, we need to analyze them. § The results should be summarized in the form of a report and presentation to the client. § If all goes well, the client will sign-off or approve the test results and then we can move on to the implementation phase of the project. If not, then we need to address and fix any problems. o The WBS… § Should be “deliverable-oriented” § Should support the project’s MOV (100% rule) § Have enough detail to support planning and control § Should involve the people who will be doing the work § Should include learning cycles and past lessons learned Ø Estimation Questions: o What are you going to estimate? o Where do you start? o How do you start? o How do you estimate Ø Estimation Techniques – Traditional Project Management Approaches o Guesstimating, Delphi Technique, Time Boxing, Top-Down Estimating, Bottom- Up Estimating, Analogous Estimates (Past experiences), Parametric Modeling (Statistical) o Ø Guesstimate o Estimation by guessing or just picking numbers out of the air is not the best way to derive a project’s schedule and budget. Unfortunately, many inexperienced project managers tend to guesstimate, or guess at the estimates, because it is quick and easy. Ø Delphi Technique o Involves multiple, anonymous experts o Each expert makes an estimate o Estimates compared § If close, can be averaged § If not, do another iteration until consensus is reached Ø Time Boxing o A “box” of time is allocated for a specific activity, task, or deliverable o Can focus a team if used effectively o Can demoralize a team if not used effectively (e.g., burned out and frustrated) Ø Top-Down Estimating o Top & middle managers determine overall project schedule &/or cost o Lower level managers are expected to breakdown schedule/budget estimates into specific activities (WBS) Ø Bottom-Up Estimating o Schedules & budgets are constructed from WBS o Starts with people who will be doing the work o Schedules & budgets are the aggregate of detailed activities & costs (person- hours, person-weeks, person-months for each module) Ø Analogous Estimates o Developing estimates based upon one’s opinion o Similar to Top-Down approach o Use information from previous, similar projects as a basis for estimation Ø Parametric Modeling o Use project characteristics (parameters) in a mathematical model to estimate o Example: $50/ LOC based on: o Programming language o Level of expertise o Size & complexity Ø Estimating Techniques - Software Engineering Approaches o Lines of Code (LOC) o Function Points o COCOMO (COnstructive COst MOdel) o Heuristics Ø Function Point Analysis o Allan Albrecht, IBM – 1979 o Synthetic metric (functionality, complexity) o Independent of the Technology o IFPUG standards (www.ifpug.org) o 5 Primary Elements: Inputs, Outputs, Inquiries, Logical Files, Interfaces Ø COCOMO o COnstructive COst MOdel o Developed by Barry Boehm o Has been extended to COCOMO II Ø COCOMO Models (Effort) o Organic – Routine 1.05 § Person Months = 2.4 * KDSI o Embedded – Challenging § Person Months = 3.6 * KDSI 1.20 o Semi-Detached – Middle § Person Months = 3.0 * KDSI 1.12 o *KDSI = thousand of delivered source instructions, i.e ., LOC Ø COCOMO Models (Duration) o Organic § Duration = 2.5 * Effort38 o Semi-Detached 0.35 § Duration = 2.5 * Effort o Embedded § Duration = 2.5 * Effort32 Ø Heuristics (Rules of Thumb) o When scheduling a software task: o 1/3 – Planning (30%) o 1/6 – Coding (20%) o 1/4 – Component test and early system test (25%) o 1/4 – System test, all components in hand (25%) Ø T Caper Jones, 1988 o The seeds of major software disasters are usally sown in the first three months of commencing the software project o Hasty scheduling, irrational commitments, unprofessional estimating techniques, and carelessness of the project management function are the factors that tend to introduce terminal problems. o Once a project blindly lurches forward towards an impossible delivery date, the rest of the disaster will occur almost inevitably Ø Brooks Law o Adding manpower to a late software project makes it later Ø Adding people o Increases the total effort necessary § The work and disruption of repartitioning § Training new people § Added intercommunication Ø How can estimates be improved ? o Experience! § Lessons learned § Best practices o Revision o Monitor o Focus on Deliverables o Control The Project Schedule and Budget Chapter ® PMBOK Project Cost Management Ø Estimate Costs o Focuses on the processes to estimate the monetary resources needed to complete the project work or activities. Ø Determine Budget o Aggregating the individual cost for each of the project activities or work package components to determine the cost baseline or overall project budget. Ø Control Costs o Updating the project’s status while monitoring the project’s budget and managing any changes to the baseline plan. The Project Planning Framework Budget and Schedule Development Ø The project’s schedule can be determined based upon the tasks and time estimates in the WBS o The schedule will also depend on how these activities are sequenced Ø The project’s budget can be determined based upon the activities and time estimates from the WBS as well as the cost of the resources assigned to the WBS tasks Ø Iterations may still be necessary Ø The objective is to create a realistic project schedule and budget! Developing the Project Schedule Ø Project Management Tools o Gantt Charts Ø Project Network Diagrams o Activity on the Node (AON) o Critical PathAnalysis o Program Evaluation and Review Technique (PERT) o Precedence Diagramming Method (PDM) Gantt Chart for Planning Gantt Chart Reporting Project’s Progress Developing the Project Schedule Ø Project Management Tools o Gantt Charts o Project Network Diagrams § Activity on the Node (AON) § Critical PathAnalysis § Program Evaluation and Review Technique (PERT) § Precedence Diagramming Method (PDM) AON (Activity On the Node) Ø Project Network Diagramming Tool o Activities – boxes (nodes) o Arrows (à) – precedence and flow o DummyArrows (--->) o Predecessors, Successors, or Parallel ActivityAnalysis forAON Activity on the Node (AON) Network Diagram PossibleActivity Paths Critical Path Ø Longest path Ø Shortest time project can be completed o Zero slack (or float) § The amount of time an activity can be delayed before it delays the project Ø Must be monitored and managed! o Project manager can expedite or crash by adding resources o Fast tracking – running activities in parallel which were originally planned as sequential o The CP can change o Can have multiple CPs PERT Ø Program Evaluation and Review Technique Ø Developed in 1950s to help manage the Polaris Submarine Project Ø Developed about the same time as the Critical Path Method (CPM) o Often combined as PERT/CPM Ø Employs both a project network diagram with a statistical distribution ActivityAnalysis for PERT Possible PERTActivity Paths Precedence Diagramming Method - PDM Ø Based on 4 fundamental relationships o Finish-To-Start (FS) o Start-To-Start (SS) o Finish-To-Finish (FF) o Start-To-Finish (SF) PDM (precedence diagramming method) Relationships Lead and Lag times Ø Lead is starting the next task before the first task is complete o Example: Begin installing the operating systems when half of the PCs are set up Ø Lag (or negative lead) is the adding of a buffer of time before the next task begins o Example: Once the walls have been painted, wait one day before laying the carpet so that the walls have had a chance to dry Critical Chain Project Management (CCPM) ¡ Introduced in 1997 in a book called Critical Chain by Eliyahu Goldratt ¡ Based on his previous work called the Theory of Constraints ¡ CCPM is based on the idea that people often inflate or add cushioning to their estimates to create a form of “safety” to compensate for uncertainty or risk because … § Your work is dependent upon the work of someone else, and you believe that starting your work will be delayed § Your pessimism from previous experience where things did not go as planned § Your belief that the project sponsor or customer will cut your project schedule or budget so you inflate your estimates to guard against this cut If people build safety into their estimates, then … Ø Why are projects still late? o Student’s Syndrome or procrastinating until the last minute before starting to work on a task o Parkinson’s Law or the idea that work expands to fill the time available § People will rarely report finishing something early because there is little incentive to do so or because they may fear that management will cut their estimates next time o Multitasking of resources or “resource contention” § Aperson is often assigned to more than one project or required to attend meetings, training, etc. As a result, they can no longer devote their time to tasks that are on the critical path CCPMAssumptions Ø Begins by asking each person or team working on a task to provide an estimate that would have a 50% chance of being completed as planned o About half of the project tasks will be completed on time, about half won’t Ø Instead of adding safety to each task, put that safety in the form of buffers where it is needed most o Feeding buffers § Reduce the likelihood of bottlenecks by ensuring that critical tasks will start on time when a task acts as a feeder to another task on the critical path o Resource buffers § Reduce resource contention o End of Project buffers § Are equal to one-half of the time saved from putting safety into each task The Critical Chain Project Schedule Critical Chain Project Management Ø And the critical path are similar o The difference is the CCPM takes into account resource contention Ø Takes a more project portfolio view o Other projects should be scheduled so that a resource can be dedicated to a particular task Ø Requires that everyone understand that each project task has a 50% chance of being completed as scheduled, so about half of the tasks will be late. o This is the reason for having the project buffer. o Instead of tracking each task individually, we become more concerned with the project buffer –i.e., the project will be late only if it uses more than the allotted project buffer. Ø Instead of penalties for being late, bonuses or other incentives for completing tasks early may be needed Developing the Project Budget Ø Define what resources will be needed to perform the work Ø Determine the quantity of resources that are needed Ø Define the cost of using each resource Ø Calculate the cost of the task or activity Ø Ensure that the resources are leveled, that is, resources have not been over allocated, assigned to more than one task scheduled at the same time Project Management Software Tools Ø Anumber of project management software tools are available to plan and track the progress of your project Ø However, having a fundamental understanding of these project management techniques is important to make the most of these software tools Other Costs Ø Direct Costs o The direct cost of labor or other resources Ø Indirect Costs o The cost for covering such things as rent, utilities, insurance, etc. Ø Sunk Costs o Costs incurred prior to the project, such as a project that has been restarted after a failed attempt Ø Learning Curve o Often have to “Build one and throw it away” to understand a problem or a new technology Ø Prorated Costs o The idea that there is a cost associated with using a resource Ø Reserves o Contingency funds to be used at the discretion of the project manager Finalizing the Project Schedule and Budget Ø The project schedule and budget may require several iterations before it is acceptable to the sponsor, the project manager, and the project team. Ø Once the project schedule and project plan are accepted, the project plan becomes the baseline plan. Ø Once accepted, the project manager and project team have the authority to execute or carry out the plan. ® Free MS Project Tutorials
Are you sure you want to buy this material for
You're already Subscribed!
Looks like you've already subscribed to StudySoup, you won't need to purchase another subscription to get this material. To access this material simply click 'View Full Document'