CIS 5800 Test 1a.txt

A process by which information is exchanged between individuals through a common system of symbols, signs, or behavior

• 1. Communication Planning: A process for developing a comprehensive communication plan that identifies project stakeholders, the information they need, when they need it, and the format in which it should be delivered.
• 2. Information Distribution: The processes involved in providing project information to all relevant stakeholders in a timely manner.
• 3. Performance Reporting: The processes for collecting and distributing project status information.
• 4. Administrative Closure: The processes for careful and detailed documentation of a project or project phase at its termination.

The response process by a receiver to a sender within the communication process

Audio, visual, or environmental interference within the communication process

The process of developing a comprehensive communication plan for informing project stakeholders of all relevant information on a timely basis; identifies stakeholders, the information they need, when they need this information, and in what format it should be delivered on a timely basis

• The communication plan includes:
• 1. When and how written and oral reports will be provided by the team
• 2. How team members will coordinate work
• 3. What messages will be sent to announce project milestones
• 4. What kinds of information will be shared with vendors and external contractors involved in the project

• When developing this plan, these questions to answer to ensure the plan is comprehensive and complete:
• 1. Who are the stakeholders for this project?
• 2. What information does each stakeholder need?
• 3. When does this information need to be produced, and at what intervals?
• 4. What sources will be used to gather and generate this information?
• 5. Who will collect, store, and verify the accuracy of this information?
• 6. Who will organize and package this information into a document?
• 7. Who will be the contact person for each stakeholder should any questions arise?
• 8. What format will be used to package this information?
• 9. What communication medium will be most effective for delivering this information to the stakeholder?

• 1. Who are the stakeholders for this project?
• 2. What information does each stakeholder need?
• 3. When does this information need to be produced, and at what intervals (how often)?
• 4. What sources will be used to gather and generate this information? (Where will the information come from?)
• 5. Who will collect, store, and verify the accuracy of this information?
• 6. Who will organize and package this information into a document?
• 7. Who will be the contact person for each stakeholder should any questions arise? (Who will be the stakeholder's contact person?)
• 8. What format will be used to package this information?
• 9. What communication medium will be most effective for delivering this information to the stakeholder?

The execution of the project communication plan and the response to an ad hoc information requests by stakeholders

• - What? (2 types of information):
• 1. Work resuts: the outcomes of the various tasks and activities that are performed to complete the project
• 2. Project plan: the formal comprehensive document that is used to execute the project

• - Where?
• 1. Vertically: communication that flows between higher and lower levels within an organization
• 2. Horizontally: communication that flows among team members or across functional areas within the same level of an organization

• - Format?
• 1. Written: the exchange of memos, reports, letters, e-mail, instant messaging, and so on through the use of standard symbols - provides a record of the communication and is particularly useful for formal and complex communication
• 2. Oral: the exchange of spoken words
• 3. Formal: comprises the routine methods for communicating within organizations; often follows customs and norms with regard to authority, rank, and the type of information
• 4. Informal: grows out of people's social interactions and is bound by convention, custom, and culture

• Written: The exchange memos, reports, letters, e-mail, instant messaging, and so on through the use of standard symbols
• Oral: The exchange of spoken words
• Nonverbal: Information that is conveyed by body language through our posture, hands, facial expressions, eye contact, and personal space

• Informal: Ad hoc methods of communication within organizations
• Formal: Routine methods for communication within organizations

• Vertical: Communication that flows between higher and lower levels within an organization
• Horizontal: Communication that flows among team members or across functional areas within the same level of an organization

The collection and distribution of the project performance information to stakeholders so that they understand the status of the project at any given time period

• Involves 3 types of reports:
• Status: Reports designed to describe current information about the project, such as project schedule or budget information
• Progress: Reports designed to describe what the project team has accomplished, sum total
• Forecasting: Reports designed to make predictions about future status and progress

• 1. Lack of adequate notification and preparation
• 2. No agenda
• 3. Wrong people or too many people in attendance
• 4. Lack of control
• 5. Political pressure and hidden agendas
• 6. No conclusions or follow-up

• 1. Define the project, team members, and key stakeholders
• 2. Provide a forum for revising, updating, modifying, and clarifying key aspects of the project
• 3. Provide an opportunity for team members to better understand how their contribution fits within the scope of the overall project
• 4. Increase team member commitment to the project and team through shared decision making and collaboration
• 5. Increase work productivity and job satisfaction by clarifying task assignments and other project details
• 6. Provide an opportunity for the project manager to demonstrate leadership and vision
• 7. Provide an opportunity for project members to demonstrate their creativity, skills, and commitment to the project and team

• 1. Running productive project meetings
• 2. Making effective presentations
• 3. Becoming a good listener
• 4. Using communication templates
• 5. Conducting a walkthrough

• Before the meeting:
• 1. Define the meeting purpose
• 2. Set the ground rules for discussion
• 3. Identify and invite only those people who need to attend
• 4. Notify people in advance of the meeting's purpose, location, and time
• 5. Distribute agenda in advance
• 6. Prepare any presentation, handouts, or other materials
• During the meeting:
• 1. Start and end the meeting on time
• 2. Begin by specifying the purpose of the meeting
• 3. Gather information from all participants using good listening skills
• 4. Take good notes or have someone assigned to record the meeting minutes
• 5. Keep things moving and stay on topic
• 6. Use visual aids to enhance the sharing of information
• 7. Periodically summarize the results of the discussion in terms of consensuses achieved or disagreements to be resolved
• 8. Assign action items to participants with clear deadlines if possible
• After the meeting:
• 1. Review and professionally prepare the minutes. Minutes should include at least the following information - Time and place of the meeting; List of attendees with their project role; Agenda items discussed; Decisions reached or held for further study; Action items (include who is responsible and timelines for completion); Time and place of the next meeting, if necessary
• 2. Review and circulate the minutes among all attendees. Request clarifications and corrections with a deadline
• 3. Circulate the finalized minutes to all attendees and relevant nonattending members

• The careful and detailed documentation of a project or project phase at its termination
• The project's results so that all related information reflects the most accurate account of success or failure of the project

• - Natural termination occurs when the requirements of the project or phase have been met - the project or phase has been completed and is a success:
• Planned
• Triggered by successful project or phase completion

• - Unnatural termination occurs when the project is stopped before completion:
• Unplanned
• Multiple causes such as some assumptions that were used to guide the project proved false, that the performance of the system or the development team was somehow inadequate, or that the project requirements are no longer relevant or valid in the current business environment, or running out of time and/or money

• 1. Listen without evaluating: Don't judge or guess what is being said
• 2. Do not anticipate: Don't assume you know what someone is going to say
• 3. Note taking: Take detailed notes because we forget one-third to one-half of what we hear within 8 hours
• 4. Listen for themes and facts: Try to organize what is being said into larger concepts
• 5. Do not fake attention: Really paying attention is actually easier than faking it
• 6. Review: Review what is being said and restate it back to the speaker as you understand it

• Presentation planning:
• 1. Who is the audience: To design the most effective presentation, you need to consider the audience (e.g., What do they know about your topic? What is their education level?).
• 2. What is the message: Your presentation should be designed with a particular objective in mind.
• 3. What is the presentation environment: Knowledge of the room size, shape, and lighting is valuable to designing an optimal presentation.
• Presentation design:
• 1. Organize the sequence: Organize your presentation so that like elements or topics are found in one place instead of randomly scattered throughout the material.
• 2. Keep it simple: Make sure that you don't pack too much information onto a slide so that it is difficult to read. Also, work to have as few slides as possible; in other words, only include information that you absolutely need.
• 3. Be consistent: Make sure that you use consistent types of fonts, font sizes, colors, design approach, and backgrounds.
• 4. Use variety: Use both textual and graphical slides to convey information in the most meaningful format.
• 5. Don't rely on the spell-checker alone: Make sure you carefully review your presentation for typographical and wording errors.
• 6. Use bells and whistles sparingly: Make sure that you use familiar graphical icons to guide and enhance slides; don't lose sight of your message as you add bells and whistles. Also, take great care when making transitions between slides and elements so that special effects don't take away from your message.
• 7. Supplemental materials: Take care when using supplemental materials so that they don't distract the audience. For example, don't provide handouts until you want the audience to actually read them.
• 8. Have a clear beginning and end: At the beginning, introduce yourself and your teammates (if any), thank your audience for being there, and provide a clear outline of what will be covered during the presentation. At the conclusion, have an ending slide so that the audience clearly sees that the presentation is over.
• Presentation delivery:
• 1. Practice: Make sure that you thoroughly test your completed work on yourself and others to be certain it covers your points and presents them in an effective manner within the time allowed.
• 2. Arrive early and cue up your presentation: It is good practice when feasible to have your presentation ready to go before the arrival of the audience.
• 3. Learn to use the special software keys: Using special keys to navigate the presentation will allow you to focus on your message and not on the software.
• 4. Have a backup plan: Have a backup plan in case technology fails or your presentation is lost when traveling.
• 5. Delivery: To make an effective presentation, you must become an effective public speaker through practice.
• 6. Personal appearance: Your appearance and demeanor can greatly enhance how the audience receives your presentation.

• 1. Does not interrupt
• 2. Waits until the end, then asks questions
• 3. Asks for clarification
• 4. Pays close attention
• 5. Verifies understanding by repeating what was said
• 6. Gives feedback -- smiles, nods, or frowns
• 7. Avoids arguing and its negative effects on a relationship
• 8. Responds to the idea, not to the person
• 9. Gets rid of distractions
• 10. Concentrates on both the words and feelings behind them; stays on track

• Poor listener:
• 1. Always interrupts
• 2. Is impatient
• 3. Makes hasty judgments
• 4. Shows disinterest (poor posture, wandering eyes)
• 5. Doesn't try to understand
• 6. Doesn't respond
• 7. Mentally prepares an argument to "win"
• 8. Reacts to people and loses temper
• 9. Fidgets with pen, paper clips
• 10. Goes off the subject

Specifications that enforce standards for the appearance and content of formal project documents

A peer-group review of any product created during the systems development process

• Walk-throughs have been used to review projects:
• 1. Project scope statements
• 2. Budget and schedule reviews
• 3. System specifications
• 4. Logical and physical designs
• 5. Code or program segments
• 6. Test procedures and results
• 7. Documentation and user training materials

When scheduling a walk-through meeting, most organizations use a walk-through review form to ensure that a qualified individual is assigned to each walk-through role, that each member has been given a copy of the review materials, and that each member knows the agenda, date, time, and location of the meeting.

Walkthrough Template:

• 1. Coordinator: This person plans the meeting and facilitates a smooth meeting process. The coordinator may be the project leader or a lead analyst responsible for the current life-cycle step.
• 2. Presenter: This person describes the work product to the group. The presenter is usually an analyst who has done all or some of the work being presented.
• 3. User: This person (or group) makes sure that the work product meets the needs of the project's customers. The user would usually be someone not on the project team.
• 4. Secretary: This person takes notes and records decisions or recommendations made by the group. The secretary may be a clerk assigned to the project team or may be one of the analysts on the team.
• 5. Standards bearer: The role of this person is to ensure that the work product adheres to organizational technical standards. Many larger organizations have staff groups within the unit who are responsible for establishing standard procedures, methods, and documentation formats. These standards bearers validate the work so that it can be used by others in the development organization.
• 6. Maintenance oracle: This person reviews the work product in terms of future maintenance activities. The goal is to make the system and its documentation easy to maintain.

A form of communication where all parties involved are present at the same time but not necessarily in the same place

A form of communication where all parties involved need not be available or present at the same time or the same place

The extent to which a communication environment allows the exchange of verbal and nonverbal cues, supports interaction and feedback, and can be personalized to the communicator

The use of integrated telephone, video recording, and playback technologies by two or more people to interact with each other from remote sites

The use of integrated computer, telephone, video recording, and playback technologies - typically by two people - to interact with each other using their desktop computers from remote sites

Software that enables people to work together more effectively

• 1. Process structuring: Keeps teams on track and helps them avoid costly diversions (e.g., doesn't allow people to get off topic or the agenda)
• 2. Parallelism: Enables many people to speak and listen at the same time (e.g., everyone has an equal opportunity to participate)
• 3. Group size: Enables members in larger teams to participate (e.g., brings together broader perspectives, expertise, and participation)
• 4. Group memory: Automatically records member ideas, comments, votes (e.g., allows members to focus on content of discussions rather than on recording comments)
• 5. Access to external information: Can easily incorporate external electronic data and files (e.g., plans and proposal documents can be collected and easily distributed to all members)
• 6. Spanning time and space: Enables members to collaborate from different places at different times (e.g., reduces travel costs or allows people from remote locations to participate)
• 7. Anonymity: Member ideas, comments, and votes not identified to others (if desired) (e.g., can make it easier to discuss controversial or sensitve topics without fear of identification or retribution)

A collection of personal computers networked with sophisticated software tools to help group members to solve problems and make decisions through interactive electronic idea generation, evaluation, and voting

• These environments, such as Microsoft's Enterprise Project Management or eProject's Project Management Office, provide a variety of capabilities to enhance the management of a portfolio of projects, especially when project teams are composed of members who are geographically dispersed.
• These environments provide a Web-based interface for accessing all relevant project information and provide numerous capabilities:
• 1. Manage multiple projects as an overall portfolio for better decision making in regard to resource assignment, problem identification, and trend and risk analysis
• 2. More closely track resource usage and workload as well as plan better for short- and long-term resource assignments
• 3. Manage stakeholders' expectations by effectively reporting project status in regard to time and resources
• 4. Enforce organizational best practices of project methodologies and processes
• 5. Support improved participation by enabling team members to easily manage, track, and report project updates
• 6. Better manage project-related deliverables through the use of a central document repository with versioning and editing control

• 1. Initiate
• 2. Plan
• 3. Execute
• 4. Monitor and control
• 5. Close

The process of authorizing a new project or continuing an existing project

• Four distinct activities:
• 1. Identifying information systems development projects
• 2. Classifying and ranking information systems development projects
• 3. Selecting information systems development projects
• 4. Establishing the project charter

• 1. Identifying information systems (IS) development projects
• 2. Classifying and ranking IS development projects
• 3. Selecting IS development projects
• 4. Establishing the project charter

• 1. A key member of top management, either the CEO of a small- or medium-sized organization or a senior executive in a larger organization -- greater strategic focus, largest project size, longest project duration
• 2. A steering committee composed of a cross-section of managers with an interest in systems -- cross-functional focus, great organizational change, formal cost-benefit analysis, larger and riskier projects
• 3. User departments, in which either the head of the requesting unit or a committee from the requesting department decides which projects to perform -- narrow, nonstrategic focus, faster development, fewer users, management layers, and business functions
• 4. The development group or a senior information systems manager -- integration with existing systems focus, fewer development delays, less concern with cost-benefit analysis

• Isolated: attempts to solve individual organizational problems; ex.: medical record in health care
• What procedure (application program) is required to solve this particular problem as it exists today?
• Dependent on current IT infrastructure
• Difficulty with this approach is that the required organizational procedures are likely to change over time as the environmental changes. For example, if a company decides to change its method of billing customers or a university changes its procedure for registering students, it usually will be necessary to modify existing information systems.

• Planned: systematic identification of projects that will provide solutions today and into the future
• What information (or data) requirements will satisfy the decision-making needs or business processes of the enterprise today and well into the future?
• Independent of current IT infrastructure constraints
• Organization's information needs are less likely to change (or change slowly) than its business processes. For example, unless an organization fundamentally changes its business, its underlying data structures may remain reasonably stable for more than 10 years. However, the procedures used to access and process the data may change many times during that same period.

An ongoing process that defines the mission, objectives, and strategies of an organization

• Requirements:
• 1. Mission statement: A statement that defines what business the company is in
• 2. Objective statement: A series of statements that express an organization's qualitative and quantitative goals for reaching a desired future position; sometimes call Critical Success Factors or Corporate Values
• 3. Competitive strategy: The method by which an organization attempts to achieve its mission and objectives

Corporate strategic planning: An ongoing process that defines the mission, objectives, and strategies of an organization

• Information systems planning (ISP): An orderly means of assessing the information needs of an organization and defining the systems, databases, and technologies that will best satisfy those needs. It's a top-down process that takes into account the outside forces - industry, economy, relative size, geographic
• region, and so on - that are critical to the success of the firm.

• Parallel Activities:
• 

• 1. Low-cost producer: This strategy reflects competing in an industry on the basis of product or service cost to the consumer. For example, in the automobile industry, the South Korea-produced Kia is a product line that competes on the basis of low cost.
• 2. Product differentiation: This strategy reflects capitalizing on a key product criterion requested by the market (e.g., high quality, style, performance, roominess). In the automobile industry, many manufacturers are trying to differentiate their products on the basis of quality (e.g., "At Ford, quality is job one.").
• 3. Product focus or niche: This strategy is similar to both the low-cost and differentiation strategy but with a much narrower market focus. For example, a niche market in the automobile industry is the convertible sports car market. Within this market, some manufacturers may employ low-cost strategy, whereas others may employ a differentiation strategy based on performance or style.

An orderly means of assessing the information needs of an organization and defining the systems, databases, and technologies that will best satisfy those needs. It's a top-down process that takes into account the outside forces - industry, economy, relative size, geographic region, direction of technical change, and so on - that are critical to the success of the firm.

• 1. Current situation: listing of manual & automated processes, listing of manual & automated data, technology inventory, human resources inventory
• 2. Future situation: blueprints of manual & automated processes, blueprints of manual & automated data, technology blueprints, human resources blueprints
• 3. Schedule of projects: help move the organization from its current state to the future desired state. Of course, scheduled projects are just one source for projects. Others include bottom-up requests from managers and business units, such as the system service request (SSR)

A form used in most organizations to request new development, to report problems, or to request new features within an existing system

• 1. Describe the current situation: The most widely used approach for describing the current organizational situation is generally referred to as top-down planning. Another approach is bottom-up planning. The process of describing the current situation begins with selecting a planning team that includes executives chartered to model the existing situation. To gain this understanding, the team needs to review corporate documents; interview managers, executives, and customers; and conduct detailed reviews of competitors, markets, products, and finances. The type of information that must be collected to represent the current situation includes all organizational locations, units, functions, processes, data (or data entities), and information systems. Once high-level information is collected, each item typically can be broken into smaller units as more detailed planning is performed. After created these lists, the team can develop a series of matrices to cross-reference various parts of the organization.
• 2. Describe the target situation, trends, and constraints: The target situation consists of the desired state of the locations, units, functions, processes, data, and information systems. For example, if the desired future state of the organization includes several new branch offices or a new product line that requires several new employee positions, functions, processes, and data, then most lists and matrices will need to be updated to reflect this vision. The target situation must be developed in light of technology and business trends, in addition to organizational constraints. This means that lists of business trends and contraints should also be constructed to help ensure that the target situation reflects these issues.
• 3. Develop a transition strategy and plan: This plan should be very comprehensive, reflecting broad, long-range issues and providing sufficient detail to guide all levels of management concerning what needs to be done, how and when it needs to be done, and who in the organization will be doing it.

• Top-down: A generic information systems planning methodology that attempts to gain a broad understanding of the information system needs of the entire organization
• Bottom-up: A generic information systems planning methodology that identifies and defines information systems development projects based upon solving operational business problems or taking advantage of business opportunities

• A generic information systems planning methodology that attempts to gain a broad understanding of the information system needs of the entire organization.
• This approach begins with conducting an extensive analysis of the organization's mission, objectives, and strategy and determining the information requirements needed to meet each objective.
• It takes a high-level organizational perspective with active involvement of top-level management.

• 1. Broader perspective: If not viewed from the top, information systems may be implemented without first understanding the business from general management's viewpoint.
• 2. Improved integration: If not viewed from the top, totally new management information systems may be implemented rather than planning how to evolve existing systems.
• 3. Improved management support: If not viewed from the top, planners may lack sufficient management acceptance of the role of information systems in helping them achieve business objectives.
• 4. Better understanding: If not viewed from the top, planners may lack the understanding necessary to implement information systems across the entire business rather than simply to individual operating units.

• A generic information systems planning methodology that identifies and defines information systems development projects based upon solving operational business problems or taking advantage of business opportunities. It's an approach requires planners to identify problems and opportunities that are then used to define projects.
• Using this approach is faster and less costly than using the top-down approach and also has the advantage of identifying pressing organizational problems.
• Yet, it often fails to view the information needs of the entire organization. This can result in the creation of disparate information systems and databases that are redundant or not easily integrated without substantial reworking.

• I. Organizational Mission, Objectives, and Strategy
• Briefly describes the mission, objectives, and strategy of the organization. The current and future views of the company are also briefly presented (i.e., where are we now, where do we want to be in the future).
• II. Informational Inventory
• This section provides a summary of the various business processes, functions, data entities, and information needs of the enterprise. This inventory will view both current and future needs.
• III. Mission and Objectives of Information Systems
• Description of the primary role IS will play in the organization to transform the enterprise from its current to future state. While it may later be revised, it represents the current best estimate of the overall role for IS within the organization. This role may be as a necessary cost, an investment, or a strategic advantage, for example.
• IV. Constraints on IS Development
• Briefly describes limitations imposed by technology and current level of resources within the company - financial, technological, and personnel.
• V. Overall Systems Needs and Long-Range IS Strategies
• Presents a summary of the overall systems needed within the company and the set of long-range (2-5 years) strategies chosen by then IS department to fill the needs
• VI. The Short-Term Plan
• Shows a detailed inventory of present projects and systems and a detailed plan of projects to be developed or advanced during the current year. These projects may be the result of the long-range IS strategies or of requests from managers that have already been approved and are in some stage of the life cycle.
• VII. Conclusions
• Contains likely but not-yet-certain events that may affect the plan, an inventory of business change elements as presently known, and a description of their estimated impact on the plan.

The justification that presents the economic, technical, operational, schedule, legal and contractual, and political factors influencing a proposed information systems project

• 1. Value chain analysis: Extent to which activities add value and costs when developing products and/or services
• 2. Strategic alignment: Extent to which the project is viewed as helping the organization achieve its strategic objectives and long-term goals
• 3. Potential benefits: Extent to which the project is viewed as improving profits, customer service, and so forth and the duration of these benefits
• 4. Resource availability: Amount and type of resources the project requires and their availability
• 5. Project size/duration: Number of individuals and the length of time needed to complete the project
• 6. Technical difficulty/risks: Level of technical difficulty to successfully complete the project within given time and resource constraints

Completed by top management, steering committee, business units, or IS development groups. Criteria varies among organizations.

• 1. Economic: Identify and compare the financial benefits and costs associated with a development project; tangible or intangible benefits or costs
• 2. Technical: Process of assessing the development organization's ability to construct a proposed system
• 3. Operational: Process of assessing the degree to which a proposed system will solve business problems or takes advantage of business opportunities (outlined in the systems service request (SSR) or project) identification study; What impact will the proposed system have on the organization's structures and procedures?
• 4. Schedule: Process of assessing the degree to which the potential time frame and completion dates for all major activities within a project meet organizational deadlines and constraints for affecting change; ex.: Y2K, a system may have to be operational by a government-imposed deadline, by a particular point in the buiness cycle
• 5. Legal and contractual: Process of asessing potential legal and contractual ramifications due to the construction of a system; ex.: copyright or nondisclosure infringement, labor laws, antitrust legislation
• 6. Political: Process of evaluating how key stakeholders within the organization view the proposed system

• Tangible: A benefit that can be measured in dollars and with certainty. Following categories -- cost reduction and avoidance; error reduction; increased flexibility; increase speed of activity; improvement of management planning and control; opening new markets and increasing sales opportunities
• Intangible: A benefit that cannot be easily measured in dollars or with certainty. Include -- competitive necessity to stay on par with competitors; increased organizational flexibility; increased employee morale; promotion of organizational learning and understanding; more timely information

• Tangible: A cost that can be measured in dollars and with certainty.
• Intangible: A cost that cannot be easily measured in terms of dollars or with certainty.

• 1. Procurement: Consulting costs; equipment purchase or lease; equipment installation costs; site preparation and modifications; capital costs; management and staff time
• 2. Project-related: Application software; software modifications to fit local systems; personnel, overhead, etc., from in-house development; training users in application use; collecting and analyzing data; preparing documentation; managing development
• 3. Start-up: Operating system software; communications equipment installation; start-up personnel; personnel searches and hiring activities; disruption to the rest of the organization; management to direct start-up activity
• 4. Operating: System maintenance costs (hardware, software, and facilities); rental of space and equipment; asset depreciation; management, operation, and planning personnel

• One-time: A cost associated with project start-up and development or system start-up. These costs typically encompass activities such as systems development, new hardware, and software purchases, user training, site preparation, and data or system conversion.
• Recurring: A cost resulting from the ongoing evolution and use of a system. Examples are application software maintenance, incremental data storage expenses, incremental communications, new software and hardware leases, supplies and other expenses (e.g., paper, forms, data center personnel).

The use of variety of analysis techniques for determining the financial feasibility of a project

The rate of return used to compute the present value of future cash flows

The current value of a future cash flow

• 1. Assign the initial estimating task to the final developers
• 2. Delay finalizing the initial estimate until the end of a thorough study
• 3. Anticipate and control user changes
• 4. Monitor the progress of the proposed project
• 5. Elevate proposed project progress by using independent auditors
• 6. Use the estimate to evaluate project personnel
• 7. Study the cost estimate carefully before approving it
• 8. Rely on documented facts, standards, and simple arithmetic formulas rather than guessing, intuition, personal memory, and complex formulas
• 9. Don't rely on cost-estimating software alone for an accurate estimate

• 1. Net Present Value (NPV): uses a discount rate determined from the company's cost of capital to establish the present value of the project. The discount rate is used to determine the present value of both cash receipts and outlays.
• 2. Return on Investment (ROI): is the ratio of the net cash receipts of the project divided by the cash outlays of the project. Trade-off analysis can be made among projects competing for investment by comparing representative ROI ratios.
• 3. Break-Even Analysis (BEA): finds the amount of time required for the cumulative cash from a project to equal its initial and ongoing investment.

• 1. Standardizing hardware platforms: Standardizing server and storage platforms can significantly reduce recurring costs; quantity purchases can reduce one-time costs.
• 2. Standardizing application infrastructure: Common application environments reduce recurring costs by reducing system and data integration as well as ongoing maintenance.
• 3. Improving security: Standardizing on a single operating system and automating updates can reduce the need for individual desktop repair and upgrades, as well as increase overall system security and simplify administration; together, these steps reduce one-time and recurring system costs.
• 4. Managing operations: By carefully monitoring and proactively administering system updates and security repairs, operational problems can be dramatically reduced or eliminated, thus reducing recurring system costs.

• 1. Failure to attain expected benefits from the project
• 2. Inaccurate project cost estimates
• 3. Inaccurate project duration estimates
• 4. Failure to achieve adequate system performance levels
• 5. Failure to adequately integrate the new system with existing hardware, software, or organizational procedures

• 1. Project size: number of members on the project team; project duration time; number of organizational departments involved in the project; size of programming effort (e.g., hours, function points)
• 2. Project structure: new system or renovation of existing system(s); organizational, procedural, structural, or personnel changes resulting from system; user perceptions and willingness to participate in effort; management commitment to system; amount of user information in system development effort
• 3. Development group: familiarity with target hardware, software development environment, tools, and operating system; familiarity with proposed application area; familiarity with building similar systems of similar size
• 4. User group: familiarity with information systems development process; familiarity with proposed application area; familiarity with using similar systems

• Using these factors for conducting a technical risk assessment, 4 general rules emerge:
• 1. Large projects are risker than small projects: Project size, of course, relates to the relative project size with which the development group is familiar. A small project for one development group may be relatively large for another.
• 2. A system in which the requirements are easily obtained and highly structured will be less risky than one in which requirements are messy, ill-structured, ill-defined, or subject to the judgment of an individual: For example, the development of a payroll system has requirements that may be easy to determine due to legal reporting requirements and standard accounting procedures. On the other hand, the development of an executive support system would need to be customized to the particular executive decision style and critical success factors of the organization, thus making its development more risky.
• 3. The development of a system employing commonly used or standard technology will be less risky than one employing novel or nonstandard technology: A project has a greater likelihood of experiencing technical problems when the development group lacks knowledge related to some aspect of the technology environment. A less risky approach is to use standard development tools and hardware environments. It is not uncommon for experienced system developers to talk of the difficulty of using leading-edge (or in their own words, bleeding-edge) technology.
• 4. A project is less risky when the user group is familiar with the system development process and application area: Successful information systems projects require active involvement and cooperation between user and developement groups. Users familiar with the application area and the systems development process are more likely to understand the need for their involvement and how this involvement can influence the success of the project.

• 5 Factors:
• 1. Perceived and real needs
• 2. Existing and available resources
• 3. List of potential and ongoing projects
• 4. Current organizational environment
• 5. Evaluation criteria

• 6 Decision outcome:
• 1. Accept project
• 2. Reject project
• 3. Delay project
• 4. Refocus project
• 5. End-user development
• 6. Proof of concept

The process of analyzing an organization's activities to determine where value is added to products and/or services and the costs incurred for doing so

A project selection method that uses weighted scoring for a variety of criteria to contrast alternative projects or system features

• A short document prepared for the customer during project initiation that describes what the project will deliver and outlines generally at a high level all work required to complete the project
• Ensures common understanding
• Communicates that a project has been created
• Does not include scope

• Sample charter:
• 

• Contains the following elements (varies):
• 1. Project title and date of authorization
• 2. Project manager name and contact information
• 3. Customer name and contact information
• 4. Projected start and completion dates
• 5. Key stakeholders, project role, and responsibilities
• 6. Project objectives and description
• 7. Key assumptions or approach
• 8. Signature section for key stakeholders

The process of progressively elaborating and documenting the project work plan in order to effectively manage a project

• 3 major activities occur:
• 1. Project workbook is created - a repository of all project-related documents and information, both paper and electronic
• 2. Project scope statement is developed - short document briefly outlines all work that will be done and clearly describes what the project will deliver and helps to make sure that you, the customer, and other project team members have a clear and common understanding of the project
• 3. Develop the baseline project plan - provides an estimate of the project's tasks and resource requirements and is used to guide the next project phase

An on-line or hard-copy repository for all project correspondence, inputs, outputs, deliverables, procedures, and standards established by the project team

A document prepared for the customer that describes what the project will deliver and outlines generally at a high level all work required to complete the project

• During this activity, the project manager will work with the customer to reach agreement on the following questions:
• 1. What problem or opportunity does the project address?
• 2. What quantifiable results are to be achieved?
• 3. What needs to be done?
• 4. Will success be measured?
• 5. How will we know when we are finished?

• • Role of scope statement varies:
• –Can range from: basis for a formal contract outlining costs, specifications and deadlines (for use with an
• outside provider)
• –To: a communication vehicle outlining current best estimates (for use with an internal development group)

• A major outcome and deliverable from the project scope definition process that contains the best estimate of a project's scope, benefits, costs, risks, and resource requirements
• Documents the best estimate of a project's scope, benefits, costs, risks, and resource requirements as of point of initiation and scope definition, and is continuously updated

• Baseline project plan contains 4 major sections:
• 1. Introduction
• 2. System description
• 3. Feasibility assessment
• 4. Management issues

• 1.0 Introduction
• A. Project overview: Provides an executive summary that specifies the project's scope, feasibility, justification, resource requirements, and schedules. Additionally, a brief statement of the problem, the environment in which the system is to be implemented, and constraints that affect the project are provided.
• B. Recommendation: Provides a summary of important findings from the planning process and recommendations for subsequent activities.

• 2.0 System Description
• A. Alternatives: Provides a brief presentation of alternative system configurations (e.g., web-based online system; mainframe with central database; local area network with decentralized databases; batch data input with online retrieval; purchasing of a prewritten package).
• B. System description: Provides a description of the selected configuration and a narrative of input information, tasks performed, and resultant information.

• 3. Feasibility Assessment
• A. Economic analysis: Provides an economic justification for the system using cost-benefit analysis.
• B. Technical analysis: Provides a discussion of relevant technical risk factors and an overall risk rating of the project.
• C. Operational analysis: Provides an analysis of how the proposed system solves business problems or take advantage of business opportunities in addition to an assessment of how current day-to-day activities will be changed by the system.
• D. Legal and contractual analysis: Provides description of any legal or contractual risks related to the project (e.g., copyright or nondisclosure issues, data capture or transferring, and so on).
• E. Political analysis: Provides a description of how key stakeholders within the organization view the proposed system.
• F. Schedules, timeline, and resource analysis: Provides a description of potential time frame and completion data scenarios using various resource allocation schemes.

• 4.0 Management Issues
• A. Team configuration and management: Provides a description of team member roles and reporting relationships.
• B. Communication plan: Provides a description of the communication procedures to be followed by management, team members, and the customer.
• C. Project standards and procedures: Provides a description of how deliverables will be evaluated and accepted by the customer.
• D. Other project-specific topics: Provides a description of any other relevant issues related to the project uncovered during planning.

• Definition: The process of subdividing the major project deliverables - as identified in the project scope statement - into smaller, more manageable activities in order to make more accurate cost, task duration, and resource estimates
• Focuses on developing a work breakdown structure (WBS) and updates to the project scope statement
• Enables assignment of tasks and responsibilities
• Establishes a baseline for performance estimates and project control

• Verification: The process of obtaining the project stakeholders' formal acceptance of a project's scope
• Involves a formal walk-through to ensure compliance with standards and to make sure all relevant parties understand and agree with scope statement and baseline plan

• Change control: A formal process for assuring that only agreed-upon changes are made to the project's scope
• This controlled process should be applied when handling project scope change requests as well as any other relevant project request items, including: Project specifications; Project schedules; Budgets; Resources
• Many packages available for tracking requests and change
• Change control must be integrated into the overall project control process so that schedules, resource requirements, risks, etc. are updated
• Scope creep: Progressive, uncontrolled increase in project scope
• –Deadly for schedule and budget
• –Single biggest cause of missed targets and project failure
• –Must have good scope statement and change control process

• Change request:
• 

• A progressive, uncontrolled increase in project scope:
• Deadly for schedule and budget
• Single biggest cause of missed targets and project failure
• Must have good scope statement and change control process

• 1. Educate your staff: Make sure all project members understand the dangers of scope creep.
• 2. Clearly define the project: A poorly defined project is one of the leading causes of scope creep.
• 3. Gather all relevant information: Talk to all relevant parties to make sure the scope of the project is complete and is understood by all stakeholders very early in the life of the project.
• 4. Define the objectives and deliverables: Write a clear project scope statement that includes project objectives and deliverables.
• 5. Assign a project sponsor: Have a project sponsor at the beginning; changing team composition often leads to project scope changes.
• 6. Create an approval process: A clear project scope change control process is necessary to limit changes to only those that have been formally approved.
• 7. Stay on track: Use comprehensive project management techniques to keep the project on schedule, on budget, and on track.
• 8. Create a good communication process: Keep all project team members and stakeholders informed of project status and changes.
• 9. Understand when change is necessary: Sometimes it is necessary to make project changes; update all project materials - schedules, budgets, resources, etc. - when changes occur.
• 10. Schedule regular meetings: Regular meetings help to keep everyone informed of the project's status and are useful for resolving any disagreements or misunderstandings.

• Organizations with long-term success in utilizing offshoring typically do not offshore the following types of projects:
• 1. Complex projects that involve multiple coordinated teams
• 2. Core-competency or core intellectual property related projects
• 3. "Crash" projects to return another project back onto schedule
• 4. New product development projects
• 5. Projects initiated to produce immediate cost savings (because it typically takes time to realize project benefits)

• Alternatively, projects that have been identified as good candidates for offshoring include those for maintenance, support, or extension of legacy systems, as well as non-mission-critical systems that do not involve key intellectual property or processes.
• Even though organizations may choose the "right" type of projects for offshore outsourcing, there is still a great risk of failure if the project is not carefully managed. Key management issues include having a local project manager who is experienced and skilled in managing an offshore team, good communication plans, and frequent milestones to ensure that problems are quickly identified.