IS 401 Ch. 9 Flashcards

1
Q

Reasons for software development failure

A
  • Undefined project management practices
  • Poor IT management and poor IT procedures
  • Inadequate executive support for the project
  • Inexperienced project managers
  • Unclear business needs and project objectives
  • Inadequate user involvement
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Describe the factors that cause a software development project to succeed or fail

A

It is notable that the primary reasons projects fail are a lack of executive involvement and a lack of management skills. The other major reason is lack of involvement by the user community. In other words, projects don’t tend to fail for lack of programming skills or enthusiastic developers.

For an IT project to be successful, strong IT management and business direction need to be present. The other major element in all project success is sound project management procedures as well as experienced and competent project managers. In fact, good project managers always ensure that they have received clear directives from business executives and committed user involvement with the requirements for the new system.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Project management

A

is organizing and directing other people to achieve a
planned result within a predetermined schedule and budget.
At the beginning of a project, a plan is developed that specifies the activities that must take place, the deliverables that must be produced, and the resources that are needed. Thus, project management can also be defined as the processes used to plan the project and then to monitor and control it.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

project manager

A

Overall, project managers must be effective internally (managing people and resources) and externally (conducting public relations). Internally, the project manager serves as locus of control for the project team and all its activities. He or she establishes the team’s structure so work can be accomplished.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

The role of the project manager

A

This list identifies a few of these internal responsibilities:

  • Developing the project schedule
  • Recruiting and training team members
  • Assigning work to teams and team members
  • Assessing project risks
  • Monitoring and controlling project deliverables and milestones

Externally, the project manager is the main contact for the project. He or she must represent the team to the outside world and communicate the team members’ needs. Major external responsibilities include:

  • Reporting the project’s status and progress
  • Working directly with the client (the project’s sponsor) and other stakeholders
  • Identifying resource needs and obtaining resources
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Client

A

A project manager works with several groups of people. First of all, there is the client (i.e., the customer), who pays for the development of the new system. Project approval and the release of funds come from the client. For in-house developments, the client may be an executive committee or a vice president. The client approves and oversees the project, along with its funding.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Oversight committee

A

For large, mission-critical projects, an oversight committee (sometimes called the steering committee) may be formed. This consists of clients and other key executives who have a vision of the organization’s strategic direction and a strong interest in the project’s success.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Users

A

On the other hand, the users are the people who will actually use the new system. The user typically provides information about the detailed functions and operations needed in the new system.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Ceremony

A

Another dimension that has a heavy impact on project management is the level of formality, sometimes called ceremony, required for a given project. Ceremony is a measure of the amount of documentation generated, the
traceability of specifications, and the formality of the project’s decision-making processes. Some projects, particularly small ones, are conducted with very low
ceremony. Meetings occur in the hallway or around the water cooler. Written documentation, formal specifications, and detailed models are kept to a minimum. Developers and users usually work closely together on a daily basis to define requirements and develop the system. Other projects, usually larger,
more complex ones, are executed with high ceremony. Meetings are often held on a predefined schedule, with specific participants, agendas, minutes, and follow-through. Specifications are formally documented with an abundance of diagrams and documentation and are frequently verified through formal review meetings between developers and users.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

project management body of knowledge (PMBOK)

A

-a project management guide and standard of fundamental project management principles
-is a widely accepted foundation of information
that every project manager should know. The PMBOK is organized into these nine knowledge areas:
+Project Scope Management
+Project Time Management
+Project Cost Management
+Project Quality Management
+Project Human Resource Management
+Project Communications Management
+Project Risk Management
+Project Procurement Management
+Project Integration Management

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Project Scope Management

A

—Defining and controlling the functions that are to be included in the system as well as the scope of the work to be done by the project team

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Project Time Management

A

—Creating a detailed schedule of all project tasks and then monitoring the progress of the project against defined milestones

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Project Cost Management

A

—Calculating the initial cost/benefit analysis and its later updates and monitoring expenditures as the project progresses

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Project Quality Management

A

—Establishing a comprehensive plan for ensuring quality, which includes quality control activities for every phase
of a project

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Project Human Resource Management

A

—Recruiting and hiring project team members; training, motivating, and team building; and implementing related
activities to ensure a happy, productive team

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Project Communications Management

A

—Identifying all stakeholders and the key communications to each; also establishing all communications
mechanisms and schedules

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Project Risk Management

A

—Identifying and reviewing throughout the project all potential risks for failure and developing plans to reduce these risks

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Project Procurement Management

A

—Developing requests for proposals, evaluating bids, writing contracts, and then monitoring vendor performance

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Project Integration Management

A

—Integrating all the other knowledge areas

into one seamless whole

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

chaordic

A

describes a project that expects and allows chaos while remaining controlled or ordered.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Agile Scope Management

A

Scope management refers to the scope of the new system and the scope of the project. In traditional predictive projects, the project manager and the team attempted to define the scope in both areas at the beginning of the project, during the planning phase. Unfortunately, for most new systems, there were so
many unknowns that the scope was almost never defined accurately. The Agile philosophy accepts the fact that the scope isn’t well understood and that there will be many changes, updates, and refinements to the requirements as the project progresses. However, uncontrolled scope can result in a project that never finishes, even if it is an Agile project. The project manager must have a process and mechanisms in place to control the scope of the project. Controlling the scope is a decision made by the client, with input provided by the project team and the users.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Agile Time Management

A

The Agile philosophy includes the idea that only for small work projects, in which the tasks are performed at nearly the same time (i.e., within one iteration), can a meaningful schedule be developed. In addition, the project team, not the project manager or team leader, will
schedule its own work. Thus, for an Agile project, each iteration is usually planned as the first task within the iteration. The tasks are identified, estimates of the effort are developed, and work is assigned by the project team members. Because there are so many iterations in a project, the project team gets lots of practice and quickly becomes proficient at estimating and scheduling the work.

23
Q

Agile Cost Management

A

Agile project managers admit more readily that time and cost estimates are difficult to make, especially with a
project in which the requirements are expected to change throughout. Hence, estimating the project’s cost isn’t as important as controlling the cost during the
life of the project. The project manager’s responsibility to control costs is just as important for an Agile project as it is for a traditional predictive project.

24
Q

Agile Risk Management

A

In most adaptive, iterative projects, including Agile projects, close attention is given to project risks, particularly technical risks. Iterative projects are often
risk-driven, meaning that early iterations focus specifically on addressing the most critical project risks. Although a similar emphasis on risk can be included
in a predictive project, it is more difficult to integrate specific risk-reducing activities into the project schedule. The major difference between the two types of projects is that in predictive projects, separate prototypes are built, whereas in adaptive projects, the high-risk portions of the new system are built first.

25
Q

Agile Quality Management

A

Usually, quality management has to do with the quality of the deliverable from the project. However, in an Agile project, we also consider the quality of the process. How well is the project working, and how well do the internal procedures promote project success?
In an Agile project, each iteration has a deliverable. Often, each iteration also integrates a new piece into the growing total system. Within each iteration, the new pieces are tested by themselves and as integrated with the rest of the system. The users also get involved in testing the system’s ability to meet their business needs. Hence, testing and quality control are spread across the entire project and usually provide a better-tested and more robust system. Another kind of quality control that should be done as part of an Agile project is a process evaluation at the end of each iteration. In other words, the project team does a self-evaluation to figure out how well it did and what could be done to improve the next iteration.

26
Q

Activities of Core Process 1:

A

Identify the Problem and Obtain Approval

27
Q

Identify the Problem

A

Information system development projects are initiated for various reasons, including:

(1) to respond to an opportunity
(2) to resolve a problem
(3) to respond to an external directive.

28
Q

Identify Problem Activities

A

Identify the problem.
Quantify project approval factors.
Perform risk and feasibility analysis.
Review with the client and obtain approval.

29
Q

An effective way to define the problem is to develop a System Vision Document (SVD)

A

a document to help define the scope of a new system

There are three components to this document: the problem description, the anticipated business benefits, and the system capabilities.

30
Q

Firsts Task (SVD)

A

The first task in developing a System Vision Document is to review the business needs that initiated the project. If the project was initiated as part of the strategic plan, then the planning documents need to be reviewed. If the
project originated from departmental needs, then key users need to be consulted to help the project team understand the business need. From this task, a brief
problem description is developed.

31
Q

Second Task (SVD) - Business benefits

A

The list of business benefits contains the results that the organization anticipates it will accrue from a new system. Business benefits are normally described in terms of the
specific results that can change the financial statements, either by decreasing costs or increasing revenues.
The business benefits focus on the financial benefit to the company. The system capabilities focus on the system itself. The benefits are achieved through the capabilities provided by the system.

32
Q

Third Task (SVD) - System capabilities

A

As the business benefits are being identified, the project team will identify the new system’s specific capabilities to support the realization of these benefits. The objective of this task is to define the scope of the problem in terms of the requirements for the information system. This scoping statement, as defined by a list of system capabilities, helps identify the size and complexity of the new system and the project that will be required.

33
Q

Quantify Project Approval Factors

A

The objective is to provide sufficient justification so funds will be released and the project can start. Sometimes, the need is so great or so obvious that
project approval is almost automatic. In other situations, it may be necessary to prepare a thorough cost-benefit analysis. These criteria must frequently be considered to obtain project approval:
■The estimated time for project completion
■The estimated cost for the project and system
■The anticipated benefits from the deployment of the new system

These are rough estimates. With the more adaptive approaches, the stakeholders recognize that the requirements are unknown and that it is more important to monitor and control scope, cost, and schedule than to try to make estimates.

34
Q

cost/benefit analysis

A

process of comparing costs and benefits to see whether

investing in a new system will be beneficial

35
Q

net present value (NPV)

A

the present value of dollar benefits and dollar costs of a
particular investment

The two concepts behind net present value are
(1) that all benefits and costs are calculated in
terms of today’s dollars (present value)
(2) that benefits and costs are combined to give a net value. The future stream of benefits and costs are netted
together and then discounted by a factor for each year in the future. The discount factor is the rate used to bring future values back to current values..

36
Q

break-even point

A

the point in time at which dollar benefits offset dollar costs

37
Q

payback period

A

the time period after which the dollar benefits have offset the dollar costs

38
Q

tangible benefit

A

a benefit that can be measured or estimated in terms of dollars

39
Q

intangible benefit

A

a benefit that accrues to an organization but that can’t be measured quantitatively or estimated accurately

Examples of intangible benefits include:

  • Increased levels of service (in ways that can’t be measured in dollars)
  • Increased customer satisfaction (not measurable in dollars)
  • Survival
  • Need to develop in-house expertise (such as a pilot program with new technology)

Examples of intangible costs include:
-Reduced employee morale-
-Lost productivity (the organization may not be able to estimate it)
-Lost customers or sales (during some unknown period of time)
.

40
Q

Determining Project Risk and Feasibility

A

Project risk and feasibility analysis verifies whether a project can be started and completed successfully. Because each project is a unique endeavor, every project
has unique challenges that affect its potential success.
The objective of this activity is to identify and assess the potential risks to project success and to take steps to eliminate or at least ameliorate these risks. They should be identified during the project approval process so all stakeholders are aware of the potential for failure. The team can also establish plans and procedures to ensure that those risks don’t interfere with the success of the project. Generally, the team assigns itself these tasks when confirming a project’s feasibility:
-Determine the organizational risks and feasibility.
-Evaluate the technological risks and feasibility.
-Assess the resource risks and feasibility.
-Identify the schedule risks and feasibility.

41
Q

Review with Client and Obtain Approval

A

In any event, it is always good policy to get the approval and support of the entire company. This process starts by making presentations to the senior executives of RMO. Often, a project manager will be asked to make the presentation or at least be present to answer questions.
After the executive committee approves the project, it goes to the board. After board approval, the IT department begins to assign full-time resources to
the project. It is also a good idea at this point to have a company-wide memo or meeting to mark the beginning of this major activity. If the entire company knows that all the executives are supporting it and requesting cooperation, the project will proceed much more smoothly.

42
Q

Plan and Monitor Activities

A
Establish the project environment.
Schedule the work.
Staff and allocate resources.
Evaluate work processes.
Monitor progress and make corrections.
43
Q

Establish the Project Environment

A
  • Recording and communicating—internal/external
  • Work environment—support/facilities/tools
  • Processes and procedures
44
Q

Work Environment

A

-Personal computer(s) and/or workstation(s)
-Personal development software and tools
-Development server with repositories, sandboxes, and communication tools
-Office space, conference rooms, and equipment, including printers, scanners,
and projectors
-Support staff

45
Q

Processes and Procedures

A

■Reporting and documentation—What is done? How is it done? Who does it?
■Programming—Single or pair programming? How is work assigned? By whom?
■Testing—Programmer tests or user tests? How to mark items ready for testing?
■Deliverables—What are they? How and when are they handed over to users? How are they accepted?
■Code and version control—How is the code controlled to prevent conflicts? How to coordinate bug fixing with new development? How and when are deliverables released?

46
Q

project iteration schedule

A

the list of iterations and use cases or user stories assigned to each iteration

47
Q

detailed work schedule

A

the schedule that lists, organizes, and describes the
dependencies of the detailed work tasks

Developing a detailed work schedule for a single iteration is a three-step process:
■Develop a work breakdown structure.
■Estimate effort and identify dependencies.
■Create a schedule by using a Gantt chart.

48
Q

work breakdown structure (WBS)

A

the list or hierarchy of activities and tasks of a project; used to estimate the work to be done and to create a detailed work schedule

49
Q

Gantt chart

A

a bar chart that portrays the schedule by the length of horizontal bars superimposed on a calendar

50
Q

critical path

A

a sequence of tasks that can’t be delayed without causing the entire project to be delayed

51
Q

Staff and Allocating Resources

A

Developing a resource plan for the project
■Identifying and requesting specific technical staff
■Identifying and requesting specific user staff
■ Organizing the project team into work groups
■Conducting preliminary training and team-building exercises

52
Q

Evaluate Work Processes (How Are We Doing?)

A

■Are our communication procedures adequate? How can they be improved?
■Are our working relationships with the user effective?
■ Did we hit our deadlines? Why or why not?
■Did we miss any major issues? How can we avoid this in the future?
■What things went especially well? How can we ensure it continues?
■What were the bottlenecks or problem areas? How can we eliminate them?

53
Q

retrospective

A

a meeting held by the team at the end of an iteration to determine what was successful and what can be improved