HPI633 exam

profileDrgraham27
ManagingInformation.pptx

Managing and Using Information Systems: A Strategic Approach – Fifth Edition

Managing IT Projects

Keri Pearlson and Carol Saunders

Chapter 10

PowerPoint® files by Michelle M. Ramim

Huizenga School of Business and Entrepreneurship

Nova Southeastern University

(c) 2013 John Wiley & Sons, Inc.

Pearlson and Saunders – 5th Ed. – Chapter 10

1

Learning Objectives

List the elements of a good project.

Understand why many IT projects fail to meet their targeted goals.

Explain the relationship between time, scope, and cost of a project.

Explain why Gantt charts are popular for planning schedules.

Define RAD and explain how it compares to the SDLC.

Be able to identify when it is time to pull the plug on a project.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Duplicate this slide as necessary.

This and related slides can be moved to the appendix or hidden if necessary.

2

Real World Example

Rural Payments Agency (RPA) in the UK blamed poor planning and lack of system testing for delays in paying out 1.5billion pounds of EU subsidies.

Only 15% were paid out by the end of 2006.

RPA had to make substantial changes to the system after implementation.

The system had not been properly managed.

Costs were at 122 million pounds and were originally estimated at 46.5 million.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

This example highlights the financial and social consequences of a failed information systems (IS) project. Such failures occur at an astonishing rate 67% of all software projects are challenged—that is, delivered late or over budget or simply fail to meet their performance criteria.

3

What Defines a Project?

Organizations combine two types of work—projects and operations (Figure 10.1).

Both types are performed by people and require a flow of limited resources.

Both are planned, executed, and controlled.

Figure 10.1 compares characteristics of both project and operational work.

A project is a temporary endeavor undertaken to create a unique product, service, or result. Temporary means that every project has a definite beginning and a definite end.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Figure 10.1 Characteristics of operational and project work.

Characteristics Operations Projects
Labor skills Training time Worker autonomy Compensation system Material input requirements Suppler ties Raw Materials inventory Scheduling complexity Quality control Information flows Worker-management communication Duration Product or service Low Low Low Hourly or weekly wage High certainty Longer duration More formal Large Lower Formal Less important Less important Ongoing Repetitive High High High Lump sum for project Uncertain Shorter duration Less formal Small Higher Informal Very important Very important Temporary Unique

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

5

Project Stakeholders

All projects have stakeholders.

Project stakeholders are the individuals and organizations that are either involved in the project, or whose interests may be affected as a result of the project.

Include the project manager, project team, and the project sponsor (a general manager who provides the resources).

The customer is an important stakeholder group.

Individuals or organizations who use the project’s product.

Multiple layers of customers may be involved.

The relationships among the project stakeholders are displayed in Figure 10.2.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Figure 10.2 Relationships among project stakeholders.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

7

Organizing the Project

A project manager can divide the project into subprojects.

Subprojects can be based on distinct activities (e.g., quality control testing).

This organizing method enables the project manager to contract certain kinds of work externally.

Provides a framework for managing crucial project resources, competing resource requirements, and shifting priorities among a set of projects.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

A successful balance of scope, time, and cost yields a high-quality project.

8

What is Project Management?

Project management:

Applying knowledge, skills, tools, and techniques to project activities in order to meet or exceed stakeholder needs and expectations.

Involves continual trade-offs managed by the project manager.

Trade-offs can be subsumed in the project triangle (Figure 10.3).

Scope may be divided into:

Product scope - the detailed description of the product’s quality, features, and functions.

Project scope - the work required to deliver a product or service with the intended product scope.

Time refers to the time required to complete the project.

Cost encompasses all the resources required to carry out the project.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Figure 10.3 Project triangle.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

In the tragic case of the Titanic, the managers were willing to trade off quality for lower-cost rivets that allowed them to build all three ships (scope) in a more timely fashion (time).

10

Project Management

Changes in any one of the sides of the triangle affect one or both of the other sides.

Scope creep - increasing the scope after a project has begun.

The project stakeholders decide on the overriding “key success factor” (i.e., time, cost, or scope).

The project manager is responsible for demonstrating to stakeholders the impact of the key success factors on the project.

Stakeholders are concerned about all facets of the project.

Measuring and tracking progress by tracking time, cost, scope, resources, quality, and risks.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

In the RPA case at the beginning of this chapter, scope was a key success factor that was managed inappropriately, ultimately

resulting in a much longer time and much higher cost.

11

Project Management - Business Case

The business case spells out the components of the project and sets the foundation.

Argues resources for the project.

Clearly articulates the details of the project and contingency plans.

Implementation issues, areas of concern, and gaps are first identified in the planning phase.

A strong business plan gives the project team a reference document to help guide decisions and activities.

Project management software (e.g., Microsoft Project, Intuit Quickbase, Basecamp):

Tracks team members, deliverables, schedules, budgets, priorities, tasks, and other resources.

Provides a dashboard of key metrics.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Essential Project Elements

There are four components essential for any project and necessary to assure a high probability of project success:

Project management.

A project sponsor and a project manager.

A project team.

Team members.

A project cycle plan.

The methodology and schedule.

The sequential steps of organizing and tracking the work of the team.

A common project vocabulary.

Effective communication.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

A commitment to working together as a team and a common project vocabulary are essential throughout the life of the project.

13

Project Management - Key Players

The project sponsor:

liaises between the project team and other stakeholders.

is a project champion providing leadership.

is a senior C-level executive with influence with the key stakeholders and C-level team.

provides the financial resources for the project.

The project manager:

Requires a range of management skills to make the project successful.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

The Project Manager Skills

A Project Manager’s skills include:

Identifying requirements of the systems to be delivered.

Providing organizational integration by defining the team’s structure.

Assigning team members to work on the project.

Managing risks and leveraging opportunities.

Measuring the project’s status, outcomes, and exception to provide project control.

Making the project visible to general management and other stakeholders.

Measuring project status against the plan, often using project management software.

Taking corrective action when necessary to get the project back on track.

Project leadership.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

The first three of these skills are formulative; they require considerable planning and designing ability.

The remaining skills are all about taking action and reacting.

15

Figure 10.4 Project leadership vs. project management (PM) process.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

16

Project leadership

Lack of leadership can result in unmotivated or confused people.

Strong project leaders skillfully manage team composition, reward systems, and other techniques to focus, align, and motivate team members.

Figure 10.4 reflects the inverse relationship between the magnitude of the project leader’s role and the experience and commitment of the team.

Factors influencing the project managers and team’s performance:

Organizational culture.

Socioeconomic influences.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

In organizations with strong processes for project management and professionals trained for this activity, the need for aggressive

project leadership is reduced.

17

Project Team

A project team consists of those people who work together to complete the project.

Teams fail because members don’t understand the nature of the work required.

Teamwork should:

Clearly define the team’s objectives.

Define each member’s role in achieving these objectives.

Have norms about conduct, shared rewards, a shared understanding of roles, and team spirit.

Project managers should leverage team member skills, knowledge, experiences, and capabilities.

Team members should share information about their departments.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Effective project managers use teamwork to organize and apply human resources, to motivate an acceptance of change, and to collect and share information throughout the organization.

18

Project Cycle Plan

The project cycle plan:

organizes discrete project activities, sequencing them into steps along a time line.

identifies critical beginning and ending dates and breaks the work spanning these dates into phases.

The three most common approaches are:

Project Evaluation and Review Technique (PERT) (Figure 10.5).

Critical Path Method (CPM).

Gantt chart (Figure 10.6).

Figure 10.7 compares both a generic project cycle plan and the Project Management Institute’s project life cycle.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Project Cycle Plan Software

PERT:

Identifies the tasks, orders the tasks in a time sequence, identifies their interdependencies, and estimates the time required to complete the task.

Critical tasks - must be performed individually; together they account for the total elapsed time of the project.

Non-critical tasks - can be built into the schedules without affecting the duration of the entire project.

CPM:

A tool that is similar to PERT.

Incorporates a capability for identifying relationships between costs and the completion date of a project as well as the amount and value of resources that must be applied in alternative situations.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Figure 10.5 PERT Chart.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Project Cycle Plan Software

PERT and CPM differ in terms of time estimates.

PERT:

builds on broad estimates about the time needed to complete project tasks.

calculates the optimistic, most probable, and pessimistic time estimates for each task.

CPM:

assumes that all time requirements for completion of individual tasks are relatively predictable.

fits projects where direct relationships can be established between time and resources (costs).

Gantt charts are:

A visual tool for displaying time relationships between project tasks.

Effective for monitoring the progress toward project completion.

Useful for planning purposes.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Figure 10.6 GANTT Chart.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Figure 10.7 Project cycle template.

Requirements Definition Period Production Period Deployment/ Dissemination Period
Investigation Task Force
User requirement definition Research concept definition Information use specification Collection planning phase Collection and analysis phase Draft report phase Publication phase Distribution phase
Typical High Tech Commercial Business
Product requirement phase Product definition phase Product proposal phase Product develop-ment phase Engineer model phase Internal test phase Production phase Manufacturing, sales & support phase
Generic Project Cycle Template
User require-ment definition phase Concept definition phase System specification phase Acquisition planning phase Source selection phase Development phase Verification phase Deploy-ment or production phase Operations/maintenance or sales support phase Deactivate phase

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Common Project Vocabulary

A typical project team includes a variety of members from different backgrounds and parts of the organization that use a different technical vocabulary.

Comprised of consultants, technical specialists, and business members.

Difficult to carry on conversations, meetings, and correspondence.

Teams should establish a common project vocabulary for terms, definitions, and meanings (i.e., acronyms, cryptic words).

Good management of the common project vocabulary as well as project management, project team, and project life cycle are all essential to project success.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Common project vocabulary: agreement on definitions and common meanings.

25

IT Projects

IT projects are a specific type of business project.

The more complex the IT aspect of the project, the higher the risk of failure of the project.

IT projects are difficult to estimate.

Projects can be measured in terms of function points or functional requirements of the software product.

Projects can be measured in “man-months”—how many people will be required to complete the project in a specified time period.

Additional people may or may not speed up the process.

Requires more communication and coordination.

Adding people to a late project only makes the project later.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

For example, a project that takes 100 man-months means that it will take one person 100 months to do the work, or 100 people can do it in a month.

26

IT Project Development Methodologies and Approaches

The choice of development methodologies and managerial influences distinguish IT projects from other projects.

The systems development life cycle (SDLC) - a traditional tool for developing IS or implementing software developed by an outsourcing provider or software developer.

Other development approaches:

Agile programming.

Prototyping.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

The general manager needs to understand the issues specific to the IT aspects of projects to select the right management tools for the

particular challenges presented in such projects.

27

Systems Development Life Cycle

Systems Development: a set of activities used to create an IS.

Systems Development Life Cycle (SDLC): the process of designing and delivering the entire system.

The SDLC generally is used in one of two distinct ways:

as a general project plan of all activities required for the entire system to operate.

Plan includes the analysis and feasibility study, the development or acquisition of components, the implementation activities, the maintenance activities, and the retirement activities.

as a process to design and develop system software.

Process is highly structured, disciplined, and formal.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

The focus is on system goals and trade-offs.

28

SDLC Phases

Seven phases (Figure 10.8):

Project initiation.

Requirements definition.

Functional design.

Construction.

Verification.

“Cut over.”

Maintenance and review.

Each phase is carefully planned and documented.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Figure 10.8 Systems development life cycle (SDLC) phases.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Traditional SDLC Methodology Issues

Several problems arise with using traditional SDLC methodology:

Many systems projects fail to meet objectives.

The skills needed to estimate costs and schedules are difficult to obtain.

Each project is unique.

The objectives may reflect a scope that is too broad or too narrow.

The problem the system was designed to solve may still exist.

Organizations need to respond quickly.

Not enough time available to adequately do each step of the SDLC for each IT project.

Newer methodologies designed to address these concerns use an iterative approach (Figure 10.9).

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Figure 10.9 Iterative approach to systems development.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Agile Development

Agile development methodologies were developed for situations where a predictable development process cannot be followed.

E.g., XP (Extreme Programming), Crystal, Scrum, Feature-Driven Development, and Dynamic System Development Method (DSDM).

Agile development is people-oriented rather than process oriented.

Adapts to changing requirements by iteratively developing systems in small stages and then testing the new code extensively.

The mantra for agile programming is “Code a little; test a little.”

DSDM is an extension of Rapid Application Development (RAD) used in the UK and is based on the underlying principles of active user interaction, frequent deliveries, and empowered teams.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

33

Agile Development

DSDM:

incorporates a project planning technique that divides the schedule into a number of separate time periods (timeboxes) with each part having its own deliverables, deadline, and budget.

is based on four types of iterations:

Study (business and feasibility).

Functional model.

Design and build.

Implementation.

XP is a more prescriptive agile methodology.

XP revolves around 12 practices, including pair programming, test-driven development, simple design, and small releases.

Some disadvantages include difficulty estimating the required effort easily getting off track if the customer is unclear about final outcomes.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Iterations occur (and reoccur) in cycles of between two and six weeks.

34

Prototyping

Prototyping:

is a type of evolutionary development.

builds a fast, high-level version of the system at the beginning of the project.

User involvement.

Users see the day-to-day growth of the system and contribute frequently to the development process.

Prototyping can be used as a phase in the SDLC to capture project requirements.

Drawbacks to prototyping:

Documentation may be difficult to write.

Users may not understand the realistic scope of the system.

The final prototype may not be scalable to an operational version.

An operational version may be difficult to complete.

The process can be difficult to manage.

Difficult to integrate across a broad range of requirements.

Suitable for “quick-and dirty” types of systems.

System design flaws may be more prevalent.

Various approaches are summarized in Figure 10.10.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Figure 10.10 Comparison of IT development methodologies.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Other Development Methodologies and Approaches

Rapid applications development (RAD), joint applications development (JAD), Object-oriented analysis, design and development, and the open sourcing approach.

RAD is similar to prototyping in that it is an interactive process in which tools are used to drastically speed up the development process.

Has tools for developing the user interface, graphical user interface (GUI), reusable code, code generation, and programming language testing and debugging.

Enables the developer to build a library of standard sets of code—or objects—used and reused in multiple applications.

“Drags and drops” objects into the design.

Automatically writes the code necessary to include that functionality.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

“A fool with a tool is still a fool.” RAD is more than just using advanced systems development tools. Rather, it is about making systems developers work more effectively.

37

Other Development Methodologies and Approaches

Joint applications development (JAD):

Is a version of RAD or prototyping.

Has users that are more integrally involved.

Uses a group approach to elicit requirements by interviewing groups of users.

Is expensive due to travel and living expenses needed to coordinate participants.

Object-oriented development:

Is a way to avoid the pitfalls of procedural methodologies.

Builds on the concept of objects—or reusable components.

An object encapsulates both the data stored about an entity and the operations that manipulate that data.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Open Sourcing Approach

Linux:

Was created by Linus Torvalds and several thousand hackers around the world.

Is a world-class OS—a clone of Unix.

Was built using a development approach called open sourcing, which is the process of building and improving “free” software via an Internet community.

Eric Raymond suggests that the Linux community resembles a great bazaar of differing agendas and approaches (with submissions from anyone) out of which a coherent and stable system emerged.

Software is open source software (OSS) if it is released under a license approved by the Open Source Initiative (OSI).

The most widely used OSI license is the general public license (GPL), which is based on the concept of free software.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Free Software

Free software offers the following freedoms for the software users:

The freedom to run the program for any purpose.

The freedom to study how the program works and adapt it to your needs. Access to the source code is a precondition for this.

The freedom to distribute copies so that you can help your neighbor.

The freedom to improve and release your improvements to the public so that the whole community benefits. Access to source code is a precondition for this.

A user who modifies the software must observe the rule of copyleft.

Copyleft - a user cannot add restrictions to deny others their central freedoms regarding the free software.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Open Sourcing Movement

The Open Sourcing Movement.

Offers a speedy way to develop software that:

is available to a whole community.

uses widespread testing.

is free.

A number of managerial issues are associated with its use in a business organization.

Preservation of intellectual property.

Updating and maintaining open source code.

Competitive advantage.

Tech support.

Standards.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Popular Open Source Software

Examples of popular open source:

Software Mozilla (a popular web browser core).

Apache (web server).

PERL (web scripting language).

OpenOffice (a Sun Microsystems-originated set of office applications that support the Microsoft Office suite formats).

PNG (graphics file format).

Open source applications available on the Internet, including Web 2.0 applications, are becoming part of the corporate infrastructure.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Managing IT Project Risk

IT projects are often distinguished from many non-IT projects on the basis of their high levels of risk.

Risk is the possibility of additional cost or loss due to the choice of alternative.

Some alternatives have a lower associated risk than others.

Risk can be quantified by assigning a probability of occurrence and a financial consequence to each alternative.

Project risk is a function of:

complexity.

clarity.

size.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Complexity

The complexity level is the extent of difficulty and interdependent components of the project.

Several factors contribute to greater complexity in IT projects:

The sheer pace of technological change.

The degree of uncertainty in identifying and agreeing on common goals.

Complexity can be determined once the context of the project has been established.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Clarity

Clarity is concerned with the ability to define the requirements of the system.

A project has low clarity if the users cannot easily state their needs or define what they want from the system.

A project with high clarity is one in which the systems requirements can be easily documented and do not change.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Size

Size plays a big role in project risk.

A project can be considered big if it has:

a large budget relative to other budgets in the organization.

a large number of team members or number of man-months.

a large number of organizational units involved in the project.

a large number of programs/components.

a large number of function points or lines of code.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Managing Project Risk Level

The project’s complexity, clarity, and size determine its risk.

Varying levels of these three determinants affect the amount of project risk.

Large, highly complex projects that are low in clarity are extremely risky.

Small projects that are low in complexity and high in clarity are usually low risk.

Everything else is somewhere in between.

The level of risk determines how formal and detailed the project management system and planning should be.

When it is difficult to estimate duration or expense of a project because it is complex or has low clarity, formal management practices or planning may be inappropriate.

Formal planning tools may be useful in low-risk projects.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Managing the Complexity Aspects of Project Risk

Strategies that may be adopted in dealing with complexity are:

Leveraging the technical skills of the team.

Having a leader or team members who have had significant work experience.

Relying on consultants and vendors.

Their work is primarily project-based and they usually possess the crucial IT knowledge and skills.

Integrating within the organization.

Having frequent team meetings, documenting critical project decisions, and holding regular technical status reviews.

Requires good communication among team members.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Managing Clarity Aspects of Project Risk

When a project has low clarity, project managers need to:

rely more heavily upon the users to define system requirements.

manage stakeholders.

Managers must balance the goals of the various stakeholders to achieve desired project outcomes.

Often involves both the project manager and the general manager.

Sustain project commitment (Figure 10.11).

Four primary types of determinants of project commitment:

Project determinants.

Psychological determinants.

Social determinants.

Organizational determinants.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Figure 10.11 Determinants of commitment for IT projects.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Gauging Success

At the start of the project, the general manager should:

consider several aspects based on achieving the business goals.

The goals be measurable and should be used throughout the project to provide the project manager with feedback.

assess if the system meets the specifications and project requirements laid out in the project scope.

Metrics may be derived specifically from the requirements and business needs.

Four dimensions that are useful in determining if a project is successful or not (Figure 10.12):

Resource constraints.

Impact on customers.

Business success.

Prepare the future.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

After the project is completed, a post-project feedback (post-implementation audit) should be completed to ensure that the system met its requirements and the system development process was a good one.

51

Figure 10.12 Success dimensions for various project types.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Chapter 10 - Key Terms

Agile development (p. 306) – a group of software development methodologies based on iteratively developing systems in small stages and then testing the new code extensively.

Direct cutover (p. 304) - conversion in which the old system stops running as soon as the new system is installed.

Joint applications development (JAD) (p. 309) - a version of RAD or

prototyping in which users are more integrally involved with the entire

development process.

Mashups (p. 311) - web apps that combine other apps to create a new app.

Object (p. 309) - encapsulates both the data stored about an entity and the

operations that manipulate that data.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Chapter 10 - Key Terms (Cont.)

Open sourcing (p. 310) - the process of building and improving “free”

software via an Internet community.

Open source software (OSS) (p. 310) - software released under a license

approved by the Open Source Initiative (OSI).

Parallel conversion (p. 304) - conversion where the old system runs alongside the new system.

Project (p. 290) - a temporary endeavor undertaken to create a unique

product, service, or result.

Project manager (p. 295) - ensures the entire project is executed

appropriately and coordinated properly.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Chapter 10 - Key Terms (Cont.)

Project management (p. 292) - applying knowledge, skills, tools, and techniques to project activities in order to meet project requirements.

Project management office (PMO) (p. 294) - a department responsible for

boosting efficiency, gathering expertise, and improving project delivery.

Project stakeholder (p. 290) - the individuals and organizations that are either

involved in the project or whose interests may be affected as a result of project.

Prototyping (p. 307) - a type of evolutionary development for of building systems where developers get the general idea of what is needed by the users and then build a fast, high-level version of the system at the beginning of the project.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Chapter 10 - Key Terms (Cont.)

Rapid applications development (RAD) (p. 308) - an interactive

process in which tools are used to drastically speed up the

development process.

Systems development life cycle (SDLC) (p. 303) - a traditional tool

for developing information systems or for implementing software

developed by an outsourcing provider or software developer.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Copyright 2013 John Wiley & Sons, Inc.

All rights reserved. Reproduction or translation of this work beyond that named in Section 117 of the 1976 United States Copyright Act without the express written consent of the copyright owner is unlawful. Request for further information should be addressed to the Permissions Department, John Wiley & Sons, Inc. The purchaser may make back-up copies for his/her own use only and not for distribution or resale. The Publisher assumes no responsibility for errors, omissions, or damages, caused by the use of these programs or from the use of the information contained herein.

(c) 2013 John Wiley & Sons, Inc.

10-‹#›

Pearlson and Saunders – 5th Ed. – Chapter 10

Time Cost

QUALITY

Scope

Time

Cost

QUALITY

Scope