Term
| 4 Dimensions of IS Project Success |
|
Definition
Resource Constraints: Project meet time and budget criteria?
Impact on customers: How much benefit customers receive?
Business success: How high and long are the profits?
Prepare the future: Altered organizational infrastructure for higher probability of r future business sucess and customer impact? |
|
|
Term
| Reasons behind IS projects risks |
|
Definition
- IT projects have a large IT component (in terms of budget/personnel)
= Scope (objective)
= Start and end dat
= Temporary use of resources
= Unique
= Accomplish something new
- Hard to estimate time, budget, and scope |
|
|
Term
| IT project management (ITPM) |
|
Definition
Collection of techniques and methods that project managers use to plan, coordinate, and complete IT projects
including:
- planning tools
- budgeting methods
- graphical scheduling methods
- risk management techniques
- communication planning
- high-tech team development |
|
|
Term
|
Definition
- Off-the-shelf (buy it and use it)
- Off-the-shelf with adaptation (buy it and customize)
- Lease (short term license)
- Tailor-made (you build it) |
|
|
Term
| Systems analysis and design |
|
Definition
Process of creating and maintaining IS
- Building computer networks, writing cpu programs, implementing data models require technical skills
- Non-technical skills: Est. the system's goals, setting up the project, determining requirements, interviewing users and understanding their view of the business and designing procedures
- require business knowledge and an understanding of group dynamics |
|
|
Term
|
Definition
| Requires coordinated teamwork by both specialists and non-specialists with business knowledge |
|
|
Term
| Systems Development Approaches |
|
Definition
1. Develop in-house
- Traditional Systems Development Life Cycle
- Rapid Application Design - Prototyping
2. Purchase Software
- Commercial Off-the-shelf
- Customized Off-the-shelf
3. Outsourcing/Offshoring |
|
|
Term
| Project Team Roles and Skills |
|
Definition
1. Business analyst
- interfaces with sponsors, managers, and users
- typically has a background in a functional area and
may have professional certification (e.g. CA, CGA ..)
2. Infrastructure analyst
- Focuses on the interaction of the new system with the
organizations existing technical infrastructure
- Significant training and experience in technology
3. Systems analyst
- Interfaceces with technical professionals
- Significant training and experience in analysis and
design
- May have experience in either programming,
database, or a business area
4. Change management analyst
- focuses on people and management issues such as
training, transitioning and support
- significant training and experience in HR |
|
|
Term
| 4 main methodologies IT professionals use to manage the technology projects |
|
Definition
1. SDLC (Systems Development Life Cycle
2. RAD (Rapid Application Development)
3. OOD (Object-Oriented Development)
4. XP (Extreme Programming) |
|
|
Term
| SDLC (System Development Life Cycle) |
|
Definition
- Describes a phased approach to the development of an IS
- Process where IS is planned, analyzed, designed, implemented, and maintained |
|
|
Term
|
Definition
1. Planning: Why should the system be built?
- Step 1: Define goals and objectives
2. Analysis: Who, what, where and when?
- Step 2: Define requirements
- Step 3: Identify alternatives
= Build, buy, outsource
3. DesignL How will the system be built?
= Step 4: Design chosen alternative
4. Implementation and Maintenance
= Step 5: Construction
= Step 6: Maintain the system |
|
|
Term
|
Definition
- Involves users, managers and technical development team
- Examine current system and identify problems
- Identify Possible Solutions
- Cost/benefit analysis of possible solutions
- Set goals for new systems
- Generate report to summarize findings |
|
|
Term
| SDLC: Requirements Analysis Phase |
|
Definition
Evluatioin of current systems through interviews, questionnaires and observations
- How does it work?
- Strengths/ weaknesses
- Determine new and existing user and business requirements
- Create data model |
|
|
Term
| Users' role in requirements development |
|
Definition
- Determine requirements (what they want/need)
= Through interviewing users
= Document requirements
--examine existing system
-- review reports, forms, queries, application features
-- security and controls
- Approve Requirements
= Users review and approve specified requirements |
|
|
Term
|
Definition
Defines detailed "system specification" of the new system:
- Determine Hardware requirements
- Determine software specifications
- Design the database
- Design procedures
- Create job definitions |
|
|
Term
| SDLC: implementation Phase |
|
Definition
Involves programmers, analysts, users, and managers to:
- Build the system and integrate components
- Install necessary hardware
- Test the system (and fix bugs)
- Change over (convert) to new system
- Train users |
|
|
Term
|
Definition
| Allowing future system users to try out the new system on their own |
|
|
Term
| 4 ways of system conversion |
|
Definition
1. Pilot
2. Phased
3. Parallel
4. Plunge |
|
|
Term
|
Definition
Implementing the entire system in a limited portion of the business
adv:
if system fails, failure is contained within limited boundary
reduces business's exposure and protect new system from developing a negative reputation throughout the organi. |
|
|
Term
|
Definition
New system is installed in phases across the organization
- once one piece works install the next piece |
|
|
Term
|
Definition
New system runs in parallel with the old one until the new system is tested and fully operational
disadv:
Costly to run both systems
Users have to work double time
Considerable work to determine whether results of new system is consistent with old system |
|
|
Term
|
Definition
Shuts old system down and starts new one
Should be avoided unless the new system is providing a service that is not vital to the operation of organization
disadv:
If new system fails, organization is screwed
(nothing can be done until new sys. fixed/old system installed) |
|
|
Term
|
Definition
Perform a post-audit: Does sys. meet users' needs?
Identify and fix problems (bugs, patches ...)
Prioritize requests
Identify modifications due to changing business needs |
|
|
Term
|
Definition
Identifies key activities and processes
- reduces the risk of forgetting something (e.g. doc./testing)
- facilitates monitoring of progress by project manager
Encourages systematic progression through phases
- each phase has a standard set of outputs and deliverables
- each phase refines the previous phase from conceptual to physical |
|
|
Term
|
Definition
Waterfall method
- System developments often isn't smooth -> there might be a need to repeat work done in a prior phase
Difficulty of documenting requirements in a usable way
- analysis paralysis: projects people spend so much time documenting requirements |
|
|
Term
| Reason behind outsourcing |
|
Definition
1. Gain expertise
2. Cost reductions
3. Reduce development risk (cap financial risk by setting specific price on components of the system)
4. Reduce risk by ensuring a certain level of quality or avoiding the risk of having substandard quality
5. Reduce implementation risk |
|
|
Term
|
Definition
1. Lost of control
- vendor in driver's seat
- technology direction
- potential loss of intellectual capital
- product fixes, enhancements in wrong priority
- vendor management, direction, or identity changes
- CIO unnecessary?
2. Benefits outweighed by long-term costs
- high unit cost, forever
- paying for someone else's mismanagement
- in time, outsource vendor is de facto sole source
- may not get what you pay for but don't know it
3. No easy exit
- critical knowledge in minds of vendors, not employees
- expensive and risky to change vendors
4. Losing confidential info
5. Losing learning opportunities |
|
|
Term
| System Purchasing Process |
|
Definition
1. Definition Phase
2. Feasibility Analysis
3. Requirements Definition
4. Short List of Packages
5. Establish Evaluation Criteria
6. Develop and Distribute RFP (request for proposal)
7. Choose Package
8. Negotiate Contract |
|
|
Term
|
Definition
1. Economic Feasibility - can we afford it? Make fin. sense?
2. Organizational Fea. - will it be accepted in this organizat?
3. Technical Fea. - does the capability exist and acceptab?
4. Operational feasibility - Is it a good fit?
5. Strategic Alignm. - Fit with long term orientation of organiza? |
|
|
Term
| Roles in Purchasing an Application Package |
|
Definition
1. User sponsor
- high level exec who helps justify system, arranges for funding, ensures that appropriate users participate in selection process
2. User champion
- user who pushes the project forward, enthusiastic
= responsible for implementing new system in organization
3. Project manager
- manages process, responsible for the sucess of the project
= may be user but IS expertise required
4. Vendor
5. Contract specialist
- provide technical and legal advice |
|
|
Term
| Advantages and Disadvantages of purchasing Packaged Software |
|
Definition
Adv:
- Cost saving
- Shorter lead time
- Quality of the software usually quite high
- Infusion of external expertise
- Frees up scarce internal development resources
Disadvantages:
- Differences between the needs of the organization and capabilities of available software packages
- Dependence upon vendor
- Risks involved in modification
- May be harder to install and integrate into an organization's operations than custom-developed software |
|
|
Term
| 3 Types of Outsourcing Contracts: |
|
Definition
1. Time and Arrangement
- pay for what is needed to get job done
- flexible but risk of large bill at the end
2. Fixed-price
- certainly regarding payment but very little flexibility in delivering IS support
3. Value-added
- outsourcer shares in benefits gained from the system
- difficult to measure |
|
|
