“Systems Analysis and Design”

LECTURE 3:
The Analyst as a Project Manager

1
Lecture Outline

 IS Projects: Success and Failure

 Role of the Project Manager
 Project Management Tasks in SDLC
 Project Initiation and Project Planning
 Project Planning Activities
 Project Schedule
 Risks Management and Project Feasibility
 Financial Calculations
 Tangible and Intangible Benefits
 Staffing the Project
 Launching the Project 2
Project Success Factors

 Project management important for success of

system development project
 2000 Standish Group Study
Only 28% of system development projects
successful
72% of projects cancelled, completed late,
completed over budget, and/or limited in
functionality
 Thus, project requires careful planning,
control, and execution
3
Reasons for Project Failure

 Incomplete or changing requirements

 Limited user involvement
 Lack of executive support
 Lack of technical support
 Poor project planning
 Unclear objectives
 Lack of required resources
4
Reasons for Project Success

 Clear system requirement definitions

 Substantial user involvement
 Support from upper management
 Thorough and detailed project plans
 Realistic work schedules and
milestones

5
Role of the Project Manager

 Project management – organizing and directing

people to achieve a planned result within budget and on
schedule
 Project manager – a person has primary responsibility
for the functioning of the team.
 Success or failure of project depends on skills of the
project manager
Beginning of project – plan and organize

During project – monitor and control

 Responsibilities are both internal and external

6
Internal Responsibilities

 Identify project tasks and build a work breakdown structure

 Define the milestones (i.e., key events in a project which can be
identified by a specific pieces of documentation or a specific status
review meeting) and deliverables to monitor progress.
 Develop the project schedule
 Recruit and train team members
 Assign team members to tasks
 Coordinate activities of team members and subteams
 Assess project risks
 Monitor and control project deliverables and milestones
 Verify the quality of project deliverables 7
External Responsibilities

 Report the project’s status and progress

 Establish good working relationships with
those who identify the needed system
requirements
The people who will use the system
 Work directly with the client (the project’s
sponsor) and other stakeholders
 Identify resource needs and obtain resources

8
Participants in a System
Development Project
A project manager reports to and woks with several groups
of people:
•The client is a person or group of people who will be paying
for the development of the new system – the customer. The
client releases funds and ultimately approves the project.
For in-house development, the client can be an executive
committee or a particular vice president who is funding the
project
•For large project, an oversight committee may be formed.
This committee consists of clients and other key executives
who have a vision of the strategic direction of the
organization and have a strong interest in the success of
the project
•Users are the people who will actually be using the new
system. The user typically provides information about the
detailed functions and operations of the new system 9
Participants in a System
Development Project

10
Various Titles/Roles of Project
Managers

11
Project Management Tasks
throughout the SDLC

 Overlap with SDLC phases

 Beginning of project
Overall project planning
 During project
Project execution management
Project control management
Project closeout
 Project management approach differs for
Predictive SDLC (linear, concurrently with SDLC
activities)
Adaptive SDLC (in cycle, planning is distributed across
the entire SDLC) 12
Project Management Tasks in SDLC

13
Project Execution Management

 Following the project schedule

 Assigning and coordinating the work
of project team
 Communicating with all project
stakeholders

14
Project Control

 Determining progress and taking

corrective actions when necessary
 Assessing whether requests for
scope changes are necessary
 Maintaining an outstanding issues
list
 Resolving problems

15
Project Closeout

 To smooth project shutdown

 Releasing team members for other
assignments
 Finalizing the budget
 Reviewing or auditing the results of
the projects

16
Project Management and SDLC
Tasks for a Predictive Project

17
Project Management and SDLC
Tasks for an Adaptive Project

18
Project Management Body of
Knowledge (PMBOK)

 Developed by The Project Management Institute (PMI)

 9 knowledge areas: foundation information for every
project manager
 Scope management
control functions included in system
control scope of work done by team

 Time management
Build detailed schedule of all project tasks
Monitor progress of project against milestones

 Cost management
Calculate initial cost/benefit analysis
Monitor expenses
19
Project Management Body of
Knowledge (cont’d)

 Quality management
Establish quality plan and control activities
for each project phase
 Human resource management
Recruit and hire project team members
Train, motivate, team build
 Communications management
Identify stakeholders and their
communications
Establish team communications
20
Project Management Body of
Knowledge (cont’d)

 Risk management
Identify and review risks for failure
Develop plans to reduce these risks
 Procurement management
Develop requests for proposals (RFPs)
Evaluate bids, write contracts, monitor
performance
 Integration management

21
Project Initiation and Project
Planning
 Driving forces/Reasons to start project
Respond to opportunity
Resolve problem
Conform to directive

22
Project initiation

Top-down projects. The optimal method is through the

long-term IS strategic plan, that identifies the overall efforts
of the organization to maintain a competitive positions and
results in specific projects.
Bottom-up projects. Individual department managers or
process managers are close to the daily work. They often
identify IS problems within their respective areas. Brought to
the attention of the strategic planning committee, these
needs are integrated into the overall business strategy. In
case of immediate needs that cannot wait for the strategic
plan (such as a new sales commission schedule or a new
productivity report), the process manager may request
initiation of individual development projects.
Outside-forces project. Projects can be initiated to
respond to outside forces. One common outside pressure is
legislative changes such as changes in tax or labor law.
These changes affect the strategic plan, resulting in an
urgent need for new IS.
23
CASE STUDY: CSS Project initiation
for Rocky Mountain Outfitters

 Strategic IS plan directs project development priorities

 RMO’s strategic plan is to build more direct customer
contact, improve service, and expand the marketing
presence
 Customer support system development selected as a
top priority

 Customer support system (CSS) selected

John MacMurty – creates project charter
Barbara Halifax – project manager
Steven Deerfield – senior systems analyst
Goal is to support multiple types of customer services
(ordering, returns, online catalogs)
 Project charter describes key participants
24
RMO Project Charter

25
Project Planning Activities

26
Project Planning Activities and
their key questions

27
Defining the Problem

 Review business needs

Use strategic plan documents
Consult key users
Develop list of expected business benefits (i.e., results
organization expects to achieve from the new IS)
 Identify expected system capabilities (at a general
level)
Define scope in terms of requirements
 Create system scope document (3 components:
problem description, business benefits, system
capabilities)
 Build proof of concept prototype (if new technology or
new solutions) to show they are feasible and possible
 Create context diagram (scope of the IS): an IS,
external entities and input/output information flows 28
System Scope Document

29
Context Diagram for Customer
Support System

30
CASE STUDY: Defining the Problem
at RMO

Barbara and Steven, the CSS project team, developed the

list of business benefits and system capabilities and
the context diagram after talking to William McDougal, vice
president of marketing and sales
Steven did some preliminary investigation on possible
alternative solutions (researched the trade magazines, the
Internet, and other sources to determine whether there were
sales and customer support systems that could be bought
and installed rapidly. None seemed to have the exact match
of capabilities that RMO needs)
They decided to proceed with the analysis phase before
making any final decisions about solutions
They began developing a schedule, budget, and feasibility
statement for the new system.

31
Producing the Project Schedule

Each project consists of tasks, activities and

phases.

A phase is made up of a group of related activities

An activity is made up of a group of related tasks
A task is a smallest piece of work that is identified,
named and scheduled

The development of a project schedule involves

three main steps:
 Develop work breakdown schedule
 Build a PERT/Gantt chart
 Develop resource requirements and staffing plan
32
Work Breakdown Structure (WBS)

A work breakdown structure (WBS) is a

hierarchy of tasks, activities and phases for the
project.
It is used as a foundation for developing the
project schedule, identifying milestones in the
schedule and for managing the costs
Each task has an associated duration (sometimes
three different values: expected, pessimistic and
optimistic) and number of resources required)
How to identify tasks:
 Top-down: identify major activities first, then internal
tasks
 Bottom-up: list all the tasks and organize them
 Analogy: from similar projects 33
RMO Work Breakdown Structure

34
Project Scheduling

Developing a project schedule is a four-step

process:
(1) Project members identify all tasks for each
activity
(2) Estimation the size of the task: number of
human resources, person-day required, calendar
time required and any other specific resources
(3) Determining the sequence of the tasks
(4) Scheduling the tasks themselves

There are special techniques and tools for project

scheduling (e.g., MS Project)
35
PERT/CPM Chart

PERT/CPM (Project Evaluation and Review

Technique/Critical Path Method) chart:
shows the relationships among tasks
defines tasks that can be done concurrently
shows the critical path (= the longest path of
dependent tasks from the first task to the last task, i.e.
the shortest completion period for the project)
If any task on that path slips, then the entire project
schedule will slip
Other tasks (not on the critical path) usually have some
slack time (the amount of time that the task can slip
without affecting the schedule)
Good to show dependencies and critical path but it is
not easy to see the project’s progress on a PERT chart

36
Partial PERT/CPM chart for the CSS
project

37
 How to Develop NW diagram

1. Determine time estimates and

expected completion times for each
activity.

2.
2.
38
38
2. Calculate ET, and TL

 Once each of these estimates is

made for each activity, the ET can
be calculated.
 Because the Expected Completion
time (E) should be close to the
realistic time, it is weighted 4 times
more than the (O) & (P) times.
 3. Determine sequence of activities &
precedence r/ps among tasks using Gant
Chart and Network Diagram

2.
2.
41
41
 4. Determine critical path
 Is represented by a sequence of connected
activities that produces the longest overall time
period. All nodes and activities within these
sequence is referred as the critical path. CP
represents the shortest time in which a project
can be completed. I. e., any delay in the activity
on the critical path delays the completion time of
the project

2.
2.
42
42
 To determine the critical path & expected
completion time, calculate the earliest and
latest expected completion time for each
activity.
 TE = sum of the estimated time (Et) from left to
right for each activity. (i.e., the precedence
order.) Hence TE is 22 days.
 Note: if 2 or more activities precede an activity,
the largest expected completion time is used in
calculating the new activity’s completion time.
Eg. Activity 8 is preceded by 5 & 7 hence the
largest expected time is 21+1=22. So the
earliest expected completion time for the last
activity is the projects life time.
 The latest completion time (TL) =
the time an activity can be
completed without delaying the
project. To find it, start from the
last activity (act 8) which is TE of
22 days. Next move from right to
the left and subtract the expected
time for each activity.
 The slack time for each activity is
equal to the diff b/n the earliest
and latest completion time
All activities with a slack of 0 are on
the critical path. So, all activities
except No 5 are on the critical path.

activity TE TL Slack on Critical Path

1 5 5 0 √
2 11 11 0 √
3 11 11 0 √
4 13 13 0 √
5 18.5 21 -2.5
6 18 18 0 √
7 21 21 0 √
8 22 22 0 √
Gantt chart

Gantt Chart: shows information for each task as

horizontal bar chart where the vertical tick marks
are calendar days and weeks:
 Doesn’t show the dependencies of tasks
 A good tool for monitoring the progress of the
project
 Tasks represented by horizontal bars
 Vertical tick marks are calendar days and weeks
 Shows calendar information in a way that is easy
to track
 Bars may be colored or darkened to show
completed tasks
 Vertical line indicates today’s date

46
Partial Gantt chart for the CSS
project

47
Importance of the Proper Project
Scheduling

In 1984, Microsoft planned to develop MS Word for one year

At that time, this was two months less than the most
optimistic estimated deadline for a project of its size
In reality, it took Microsoft five years to complete Word
Ultimately, the overly aggressive schedule for Word slowed
its development for a number of reasons:
The project experienced high turnover due to unreasonable
pressure and work hours
Code was ”finalized” prematurely, and the software spent
much longer in “stabilization” (i.e., fixing bugs) than was
originally expected (i.e., 12 months versus 3 months).
Aggressive scheduling resulted in poor planning – the delivery
date consistently was off by more than 60% for the first four
years of the project
48
Just For Fun

http://www.getfunnypictures.com/crt052.html

MS software release 49
Risks Management and Project
Feasibility

 Risk management
 Organizational and cultural feasibility
 Technological feasibility
 Schedule feasibility
 Resource feasibility
 Economic feasibility
Cost/benefit analysis
Sources of funds (cash flow, long-term
capital)
50
Risk Analysis

51
Organizational and Cultural
Feasibility

 Each company has own culture

New system must fit into culture
 Evaluate related issues for potential risks
Low level of computer competency
Computer phobia
Perceived loss of control
Shift in power
Fear of job change or employment loss
Reversal of established work procedures
 Positive steps should be undertaken to reduce the risks
 E.g.: additional training can be held to teach new procedures
and provide increased computer skills
52
Technological Feasibility

 Does system stretch state-of-the-art

technology?
 Does in-house expertise presently exist for
development?
 Does an outside vendor need to be involved?
 Solutions include
Training or hiring more experienced employees
Hiring consultants
Changing scope and project approach

53
Schedule Feasibility

 Estimates needed without complete

information
 Management deadlines may not be realistic
 Project managers
Drive realistic assumptions and estimates
Recommend completion date flexibility
Assign interim milestones to periodically reassess
completion dates
Involve experienced personnel
Manage proper allocation of resources
54
Resource Feasibility

 Team member availability

 Team skill levels
 Computers, equipment, and
supplies
 Support staff time and availability
 Physical facilities

55
Economic Feasibility

 Cost/benefit analysis
Estimate project development costs
Estimate operational costs after project
Estimate financial benefits based on annual
savings and increased revenues
Calculate using table of costs and benefits
 Uses net present value (NPV), payback
period, return on investment (ROI)
techniques
56
Development Costs for RMO

The project manager has responsibility for

estimating the cost of development:
Salaries and wages
Equipment and installation
Software and licenses
Consulting fees and payments to third
parties
Training
Facilities
Utilities and tools
Support staff
Travel and miscellaneous 57
Supporting details of salary and
wages for the CSS project

58
Summary of Development Costs for
RMO

59
Operating Costs

The following list identifies the major categories of

costs that may be allocated to the operation of the
new system:
• connectivity
• equipment maintenance
• computer operations
• programming support
• amortization of equipment
• training and ongoing assistance (e.g., help desk)
• supplies

60
Summary of Annual Operating
Costs for RMO

61
Just For Fun

Technical support

62
Sources of Benefits

Benefits usually come from two major sources:

decreased costs
increased revenues
Unlike development costs, there are no “standard” benefits
Sample of reduced costs:
• Reducing staff due to automating manual functions or increasing
efficiency
• Maintaining constant staff with increasing volumes of work
• Decreasing operating expenses, such as shipping charges for
emergency shipments
• Ensuring quicker processing and turnaround of documents or
transactions
• Capturing lost discounts on money management
• Reducing bad accounts or bad credit losses
• Reducing inventory or merchandise losses due to tighter controls
• Collecting accounts receivables more quickly
• Capturing income lost due to “stock outs” with better inventory
management
• Reducing the cost of goods with volume discounts and purchases
• Reducing paperwork costs with electronic data interchange and
other automation 63
Sample Benefits for RMO

64
Financial Calculations

Companies use a combination of methods:

Fist approach, called the net present value (NPV), has
two concepts:
(1) all benefits and costs are calculated in terms of today’s
dollars (present value)
(2) the future streams of benefits and costs is netted together
and then discounted by a certain factor for each year in the
future
Second method to determine whether investments will be
beneficial is to determine the payback period, sometimes called
the breakeven point. This is the point in time at which benefits
becomes equal to the cost of development and operation

Third economic measure is the return on investment (ROI).

ROI shows a percentage return needed so that the costs and
benefits are exactly equal over the specified time period.

65
RMO Cost Benefit Analysis

66
Tangible vs. Intangible Benefits

Tangible benefits – can be measured or estimated in terms of

dollars
Intangible benefit – can’t be directly measured or estimated in
dollars
In some instance, the intangible benefits far exceed the tangible
costs
Examples of intangible benefits:
• Increased levels of service (in ways that cannot be measured)
• Increased customer satisfaction (not measurable)
• Survival (a standard capability common in the industry, or
common to many competitors)
• The need to develop in-house expertise (such as with a pilot
program with new technology)

Examples of intangible costs:

• Reduced employee moral
• Lost productivity (inestimable)
• Lost customers or sales (during some period of time)

67
Staffing the Project

There are five tasks within this activity:

Develop a resource plan
Identify and request technical staff
Identify and request specific user staff
Organize the project team into work groups
Conduct preliminary training and team-building

68
Launching the Project

 Scope defined, risks identified, project

is feasible, schedule developed, team
members identified and ready
 Oversight committee finalized, meet to
give go-ahead, and release funds
 Formal announcement made to all
involved parties within organization

69
 Readings

Today’s lecture: Chapter 3 – “The Analyst as A

Project Manager” ! ! !
y ou
a n k
Th
For next week: Chapter 4 – “Investigating System
Requirements”

70