Class Notes (835,495)
Canada (509,212)
ITM 305 (73)
Lecture

Ch2 - Project Management.docx

7 Pages
111 Views
Unlock Document

Department
Information Technology Management
Course
ITM 305
Professor
Youcef Derbal
Semester
Fall

Description
Chapter 2 Project Management - Project management is the process of planning and controlling the development of a system within a specified time frame at a minimum cost with the right functionality. - Project management is trade-offs between important elements (cost, time, functionality/quality) Project Identification - Project is identified when a business need (new marketing campaign, reaching to new customers, and interactions with supp) is identified to build a system. - Tangible value (quantified and easily measured) and Intangible value (hard to measure, benefits the organization) System Request (First step) - Project initiating begins with a technique called System request - A document that shows reasons for building a system and the profit (value) that the system can provide. - Five elements (page 53, 2-1): o Project sponsor (initiates the project, serves as primary point of contact for the on the business side) o Business need (business-related reason for initiating the system.) o Business requirements (Business capabilities that the system will provide) o Business value (benefits that the system will create for the organization) o Special issues or Constraints (relevant tool of the system, decision by the committee) Feasibility Analysis (Second step) - Identifies the risks associated with the project that must be addressed if the project is approved. Technical Feasibility (can we build it?) - Extent to which the system can be successfully designed, developed, and installed by the IT - Technical risk analysis: “can we build it?” o Familiarity w. the functional area o Familiarity w. the technology Chapter 2 o Project size ( # of ppl on development team, time limit of finishing the project, or how many features) o Compatibility - Developing new systems is riskier than producing extensions to an existing system because existing systems tend to be better understood - Larger projects is more risky (more complicated to manage, greater that system requirements will be misunderstood) Economic Feasibility a.k.a Cost-benefit analysis (Should we build it?) - Identifies the costs and benefits associated with the system (can they profit or lose money?) - Steps in performing economic analysis (page 57, 2-4): o Identifying costs and benefits (list the tangible costs and benefits for the project. Include one-time and recurring costs) o Assigning values to costs and benefits (business users and IT professionals to create the costs and benefits. Intangibles should be valued as well) o Determining cash flow (Project what the costs and benefits will be over a period of time, usually 3-5 yrs. Apply growth rate if possible) o Determining net present value, NPV (Calc. the compared value of future costs and benefits between today’s standards. o Determining return on investment, ROI (Calc. how much money the organization will receive in return for the investment o Determining the break-even point (Find first year in which the system has greater benefits than costs and use it in the formula. This shows how long it will take when they start making profits) o Graphing the break-even point (Plot the yearly costs and benefits on a line graph. The point at which the lines cross is the break-even point) - FORMULAS FOR present value, NPV, ROI, break even (PAGE 61,2-9) Organizational Feasibility (if we build it, will they come?) - How well will the system are used by the users and incorporations. - Strategy alignment, fit between the project and business strategy. Greater the alignment, the less risky the project will be. - Stakeholder analysis, some important stakeholders highest to lowest are (pages 65, 2-11): o Champion (initiates, promotes, allocates time, provides resources) o Organizational management (know about the project, budget enough money for the project, encourage users to accept and use the system) o System users (decisions that influence the project, do hands-on activities for the project, determine whether it was successful) Chapter 2 Project Selection - Committee accepts or declines the project. - Portfolio management, considerate these things (page66, 2-12): o Size (what is the size, how many ppl is needed for the project?) o Cost (how much is the project cost?) o Purpose (meant to improve the technical infrastructure?, support business strategy?, new innovation?) o Length (how long will it take to complete?) o Risk (success or fail?) o Scope (how much is the organization effected by the system? A Department? A division? Entire Corporation?) o Return on investment (how much profit?) - Trade-offs, the organization must give up something in return for something else to keep its portfolio well balanced. Traditional Project Management Tools - Task, unit of work such as feasible analysis (page 69, 2-13) Work Breakdown Structure - High-level tasks are first defined and then broken down into subtasks (page 70, 2-14) - List of tasks hierarchically numbered is called Work Breakdown Structure (WBS). Must include duration and status of the tasks - Task dependencies, can’t start until other tasks are completed - Organizing a traditional WBS: by development phase or by product. Gantt Chart - A horizontal bar chart that shows the same task information as WBS but graphically.(pages 72, 2-15) - Faster and easier. - Limit the number of tasks 20-30. If there are more tasks, break them down into subtasks Network Diagram - Lays out the project tasks in a flowchart. (page 73, 2-16) - Project evaluation and review technique (PERT) is a network analysis technique - PERT uses three time estimates: optimistic, most likely, and a pessimistic. Calculates it into a single weighted average (formula on page 71) - Critical path method (CPM) simply allows the identification of the critical path in the network. Chapter 2 Project Effort Estimation - Estimation is the process of assigning projected values for time and effort - Use-case points, based on unique features of use cases and object orientation. (Pages 75) - Use-case models have two primary constructs: o Actor represents a role that a user of the system plays, not a specific user. o Use-cases point estimation purposes o Actors can be classified as: simple, average, or complex  Simple (separate systems with which the current system must communicate through a well-defined application program interface (API))  Average (separate systems that interact with the current system using standard communication protocols)  Complex (typically end users communicating with
More Less

Related notes for ITM 305

Log In


OR

Join OneClass

Access over 10 million pages of study
documents for 1.3 million courses.

Sign up

Join to view


OR

By registering, I agree to the Terms and Privacy Policies
Already have an account?
Just a few more details

So we can recommend you notes for your school.

Reset Password

Please enter below the email address you registered with and we will send you a link to reset your password.

Add your courses

Get notes from the top students in your class.


Submit