Chapter 1: The Nature of Information Technology Projects

Download Report

Transcript Chapter 1: The Nature of Information Technology Projects

Information Technology
Project Methodology
(ITPM)
1-1
Methodology
• A strategic level plan for managing and controlling IT
projects
• A template for initiating, planning, & developing an
information system
• Recommends in support of an IT project:
–
–
–
–
–
phases
deliverables
processes
tools
knowledge areas
• Must be flexible and include best “practices” learned
from experiences over time
1-2
An IT Project Methodology
1-3
Phase 1: Conceptualize and Initialize
• Defining the overall goal of the project
– Defining scope
– Evaluating the project’s success
• Identifying alternatives
• Analyzing
– Costs & benefits
– Feasibility & risks
• Summarizing a recommended alternative
(business case)
1-4
Phase 2: Develop the Project Charter
and Detailed Project Plan
• Define project’s objectives in terms :
–
–
–
–
Scope
Schedule
Budget
Quality standards
1-5
Phase 3: Execute and Control the
Project
• Use an approach such as the SDLC
• Must ensure that the environment and
infrastructure to support the project are
included
1-6
Phase 4: Close Project
• Prepare final project report and presentation
• Document and verify that all project
deliverables have been completed
• Determine the final cost
• Invoice the client for any remaining payments
• Close all project accounts
• Archive all project documents and files
• Release project resources
1-7
Phase 5: Evaluate Project Success
• 4 areas for evaluation
– Post mortem by project manager and team of entire
project
– Evaluation of team members by project manager
– Outside evaluation of project, project leader, and
team members
– Evaluate project’s organizational value
1-8
IT Project Management Foundation
• Project Management
Processes
– Initiating processes
– Planning processes
– Executing processes
– Controlling processes
– Closing processes
• Project Objectives
• Tools support both the
processes and product of
the project.
– Tools and technique for
estimation, development
and management e.g.
CASE
• Infrastructure
• Project Management
Knowledge Areas
1-9
IT Project Management Foundation
• Organizational
Infrastructure
– Influences how project
resources are allocated, the
reporting relationships of the
project manager and the
project team members, and
the role within the
organization
• Project Infrastructure
– Support team in terms of
• Project Environment
• Roles and
Responsibilities of team
members
• Processes and Controls
• Technical Infrastructure
– Provides the hardware and
software tools to support the
project team
• Project management
software
• E-mail
• Voice mail
• Word processor
• Access to Internet
1-10
Project Management Processes
• Concerned with defining
and coordinating the
activities and controls
needed to manage the
project  project
management processes
• Require specific domain
knowledge, tools, and
techniques in order to
complete the work 
product-oriented
processes
1-11
Project Management Processes and
ITPM Phases
1-12
Project Management Process
• 5 Project Management Process Groups
–
–
–
–
–
Initiating
Planning
Executing
Controlling
Closing
1-13
Initiating the IT Project
1-14
The Business Case
• Definition of Business Case: an analysis of the
organizational value, feasibility, costs, benefits,
and risks of the project plan.
• Not a budget or project plan
• To provide senior management with all the
information needed to make an informed
decision as to whether a specific project should
be funded.
• Must document the methods & rationale used for
quantifying the costs and benefits.
1-15
The Business Case
• Attributes of a Good Business Case
–
–
–
–
Details all possible impacts, costs, benefits
Clearly compares alternatives
Objectively includes all pertinent information
Systematic in terms of summarizing findings
1-16
Process for Developing the
Business Case
1-17
Developing the Business Case
• Step 1: Select the Core Team with a goal of
providing the following advantages:
•
•
•
•
•
•
Credibility
Alignment with organizational goals
Access to the real costs
Ownership
Agreement
Bridge building
1-18
Developing the Business Case
• Step 2: Define Measurable Organizational
Value (MOV) the project’s overall goal
• MOV must:
–
–
–
–
be measurable
provide value to the organization
be agreed upon
be verifiable
• Aligning the MOV with the organizational strategy
and goals.
1-19
The IT Value Chain
1-20
Project Goal ?
• Install new hardware and software to improve
our customer service to world class levels
versus
• Respond to 95% of our customers’ inquiries
within 90 seconds with less than 5%
callbacks about the same problem.
1-21
A Really Good Goal
• Our goal is to land a man on the moon
and return him safely by the end of the
decade.
John F. Kennedy
1-22
Steps to Develop MOV
MOV Step 1 - Identify the
desired area of impact
—
—
—
—
—
Strategic
customer
financial
operational
social
MOV Step 2 - Identify the
desired value of the IT
project
—Better
—Faster
—Cheaper
—Do more
1-23
1-24
Steps to Develop MOV
MOV Step 3 - Develop an Appropriate Metric
—
—
—
—
provide target
set expectations
enable success/failure determination
common metrics
•
•
•
Money ($ £ ¥)
Percentage (%)
Numeric Values
MOV Step 4 - Set a time frame for Achieving
MOV
— When the project’s MOV will be evaluated
1-25
Steps to Develop MOV
MOV Step 5 - Verify and Get Agreement from
the Project Stakeholders
 To ensure that MOV can be achieved
MOV Step 6 - Summarize MOV in a Clear,
Concise Statement or Table
— Provides an important chance to get final
agreement and verification
— Provides a simple and clear directive for the
project team
— Sets explicit expectations for all project
stakeholders
— Not include any explicit statements about
technology
1-26
Steps to Develop MOV
MOV: The B2C project will provide a 20% ROI and
500 new customers within the first year of its operation
Sample MOV Using Table Format
Year
MOV
1
20% return on investment
500 new customers
2
25% return on investment
1,000 new customers
3
30% return on investment
1,500 new customers
1-27
Developing the Business Case
• Step 3: Identify Alternatives
– Alternatives
– Base Case Alternative
• Describes how the organization would perform if
it did not pursue any of the options described in
the business case.
– Alternative Strategies
•
•
•
•
•
Change existing process sans IT investment
Adopt/Adapt systems from other organizational areas
Reengineer Existing System
Purchase off-the-shelf Applications package
Custom Build New Solution
1-28
Developing the Business Case
• Step 4: Define Feasibility and Asses Risk
– Economic feasibility
– Technical feasibility
– Organizational feasibility
– Other feasibilities
Risk focus on
– Identification
– Assessment
– Response
• Step 5: Define Total Costs of Ownership
– Direct or Upfront costs
– Ongoing costs
– Indirect costs
1-29
Developing the Business Case
• Step 6: Define Total Benefits of Ownership
–
–
–
–
Direct benefits
Ongoing benefits
Indirect benefits
Benefits can arise from
• Increasing high-value work
• Improving accuracy and efficiency
• Improving decision-making
• Improving customer service
1-30
Developing the Business Case
• Step 7: Analyze Alternatives using financial
models and scoring models
– Payback
Payback Period = Initial Investment
Net Cash Flow
= $100,000
$20,000
= 5 years
1-31
Developing the Business Case
– Break Even
Materials (putter head, shaft, grip, etc.)
$12.00
Labor (0.5 hours at $9.00/hr)
$ 4.50
Overhead (rent, insurance, utilities, taxes, etc.)
$ 8.50
Total
$25.00
If you sell a golf putter for $30.00 and it costs $25.00 to make, you have
a profit margin of $5.00:
Breakeven Point = Initial Investment / Net Profit Margin
= $100,000 / $5.00
= 20,000 units
1-32
Developing the Business Case
– Return on Investment
Project ROI =(total expected benefits – total expected costs)
total expected costs
= ($115,000 - $100,000)
$100,000
= 15%
1-33
Developing the Business Case
– Net Present Value
Year 0
Year 1
Year 2
Year 3
Year 4
Total Cash Inflows
$0
$150,000
$200,000
$250,000
$300,000
Total Cash Outflows
$200,000
$85,000
$125,000
$150,000
$200,000
Net Cash Flow
($200,000)
$65,000
$75,000
$100,000
$100,000
NPV = -I0 +  (Net Cash Flow / (1 + r)t)
Where:
I = Total Cost or Investment of the Project
r = discount rate
t = time period
1-34
Developing the Business Case
– Net Present Value
Time Period
Calculation
Discounted Cash Flow
Year 0
($200,000)
($200,000)
Year 1
$65,000/(1 + .08)1
$60,185
Year 2
$75,000/(1 + .08)2
$64,300
Year 3
$100,000/(1 + .08)3
$79,383
Year 4
$100,000/(1 + .08)4
$73,503
Net Present Value (NPV)
$77,371
1-35
Developing the Business Case
– Scoring Model
n
Total Score =  wici
i=1
Where
wi = criterion weight
ci = criterion score
0  wi  1
1-36
Weight
Alternative A
Alternative B
Alternative C
ROI
15%
2
4
10
Payback
10%
3
5
10
NPV
15%
2
4
10
Alignment with strategic
objectives
10%
3
5
8
Likelihood of achieving
project’s MOV
10%
2
6
9
Availability of skilled
team members
5%
5
5
4
Maintainability
5%
4
6
7
Time to develop
5%
5
7
6
Risk
5%
3
5
5
10%
2
4
9
10%
2
5
8
100%
2.65
4.85
8.50
Criterion
Financial
Organizational
Project
Customer satisfaction
External
Total Score
Increased market share
Notes: Risk scores have a reverse scale – i.e., higher scores for risk imply lower levels of risk
1-37
Developing the Business Case
• Step 8: Propose and Support the
Recommendation
1-38
Business Case Template
1-39
Project Selection and Approval
• The Project Selection Decision
– Methods include:
•
•
•
•
•
focusing on broad needs
categorizing projects
performing financial analyses
using a weighted scoring model
implementing a balanced scorecard
1-40
Project Selection and Approval
• Focusing on Broad Organizational Needs
– IT project must map to organization goals
– IT project must provide verifiable MOV
• Categorizing IT Projects
– One categorization is whether the project
addresses
• a problem
• an opportunity
• a directive
– Another categorization is how long it will take to do
and when it is needed
– Another is the overall priority of the project
1-41
Project Selection and Approval
• Financial Analysis of Projects
– Financial considerations are often an important
consideration in selecting projects
– Three primary methods for determining the
projected financial value of projects:
• Net present value (NPV) analysis
• Return on investment (ROI)
• Payback analysis
1-42
Project Selection and Approval
• Implementing a Balanced Scorecard
– Drs. Robert Kaplan and David Norton developed
this approach to help select and manage projects
that align with business strategy
– A balanced scorecard converts an organization’s
value drivers, such as customer service,
innovation, operational efficiency, and financial
performance to a series of defined metrics
– See www.balancedscorecard.org for more
information
1-43
Balanced Scorecard Approach
1-44
Reasons Balanced Scorecard Approach
Might Fail
• Nonfinancial variables incorrectly identified as
primary drivers
• Metrics not properly defined
• Goals for improvements negotiated not based
on requirements
• No systematic way to map high-level goals
• Reliance on trial and error as a methodology
• No quantitative linkage between
nonfinanacial and expected financial results
1-45
MOV and the Organization’s
Scorecard
1-46
Project Integration
Management
1-47
Project Integration Management
1-48
The Key to Overall Project Success: Good
Project Integration Management
• Project Plan Development: taking the results
of other planning processes and putting them
into a consistent, coherent document—the
project plan
• Project Plan Execution: carrying out the
project plan
• Overall Change Control: coordinating
changes across the entire project
1-49
Project Plan Development
• A project plan is a document used to coordinate all
project planning documents
• Its main purpose is to guide project execution
• Project plans assist the project manager in leading
the project team and assessing project status
• Project performance should be measured against a
baseline plan
• Inputs
–
–
–
–
Past project
Policies and procedures
Constraints and Assumptions
Tools (structured process)
1-50
Common Elements of a Project Plan
• Introduction or overview of the project
• Description of how the project is organized
• Management and technical processes used
on the project
• Work to be done, schedule, and budget
information
1-51
Project Plan Execution
• Project plan execution involves managing and
performing the work described in the project
plan
• The majority of time and money is usually spent
on execution
• The application area of the project directly
affects project execution because the products
of the project are produced during execution
1-52
Important Skills for Project Execution
• General management skills like leadership,
communication, and political skills
• Product skills and knowledge
• Use of specialized tools and techniques
1-53
Tools and Techniques for Project
Execution
• Work Authorization System: a method for
ensuring that qualified people do work at the
right time and in the proper sequence
• Status Review Meetings: regularly scheduled
meetings used to exchange project
information
• Project Management Software: special
software to assist in managing projects
1-54
Overall Change Control
• Overall change control involves identifying,
evaluating, and managing changes
throughout the project life cycle
• Main objectives of change control:
– ensure process in place to evaluate the value of
proposed change
– determine whether accepted change has been
implemented
– include procedures for handling emergencies
– help project manager manage change
1-55
Overall Change Control
1-56
Change Control System
• A formal, documented process that describes
when and how official project documents and
work may be changed
• Describes who is authorized to make
changes and how to make them
• Often includes a change control board (CCB),
configuration management, and a process for
communicating changes
1-57
Change Control Boards (CCBs)
• A formal group of people responsible for
approving or rejecting changes on a project
• CCBs provide guidelines for preparing
change requests, evaluate change requests,
and manage the implementation of approved
changes
• Includes stakeholders from the entire
organization
1-58
Making Timely Changes
• Some CCBs only meet occasionally, so it may
take too long for changes to occur
• Some organizations have policies in place for
time-sensitive changes
– “48-hour policy” allows project team members to
make decisions, then they have 48 hours to
reverse the decision pending senior management
approval
– Delegate changes to the lowest level possible, but
keep everyone informed of changes
1-59
Configuration Management
• Ensures that the products and their descriptions are
correct and complete
• Concentrates on the management of technology by
identifying and controlling the functional and physical
design characteristics of products
• Configuration management specialists identify and
document configuration requirements, control
changes, record and report changes, and audit the
products to verify conformance to requirements
1-60
Software Configuration Management
(SCM)
The “First Law”
No matter where you are in the system
life cycle, the system will change, and the
desire to change it will persist throughout
the life cycle.
Bersoff, et al, 1980
1-61
What Are These Changes?
changes in
business requirements
changes in
technical requirements
changes in
user requirements
other
documents
software models
Project
Plan
data
Test
code
1-62
What is SCM
• SCM is a set of tracking and control activities
that begin with a software project begins and
terminate only when the software is taken out
of operation
• The purpose of SCM is to maintain the
integrity of products as the evolve from
specifications through design, development,
and production
1-63
The Software Configuration
programs
The pieces
documents
data
1-64
Software Configuration Item (SCI)
•
•
•
•
•
•
•
•
•
•
System Specification
Software Project Plan
Software Requirements Specification
Preliminary User Manual
Design Specification
Source Code Listing
Test Specification
Operation and Installation Manuals
Executable Program
Database Description
1-65
Software Configuration Item
1-66
Change & SCM
Software Engineering
tools
methods
procedures
a TQM foundation
SCM
•
•
•
•
•
•
identification
version control
change control
auditing
reporting
construction
1-67
Component Identification
• 714F-RTC-SRS-B
• 714-MTEP-A
– where
•
•
•
•
•
714 หมายถึง หมายเลข project
RTC หมายถึง Real Time Control
SRS หมายถึง Software Requirement Specification
MTEP หมายถึง Master Test and Evaluation Plan
A และ B เป็ น revision
1-68
Version Control
• RTC_101.FOR.5
– where
• 101 = input / output
• FOR = Fortran language
• 5 = version
1-69
Change Control
STOP
1-70
Change Control Process—I
need for change is recognized
change request from user
developer evaluates
change report is generated
change control authority decides
request is queued for action
change request is denied
user is informed
change control process—II
1-71
Change Control Process-II
assign people to SCIs
check-out SCIs
make the change
review/audit the change
establish a “baseline” for testing
change control process—III
1-72
Change Control Process-III
perform SQA and testing activities
check-in the changed SCIs
promote SCI for inclusion in next release
rebuild appropriate version
review/audit the change
include all changes in release
1-73
Auditing
Change
Requests
SQA
Plan
SCIs
SCM Audit
1-74
Access Control
1-75
Status Accounting
Change
Requests
Change
Reports
ECOs
SCIs
Status Accounting
Reporting
1-76
Suggestions for Managing Integrated
Change Control
 View project management as a process of constant
communications and negotiations
 Plan for change
 Establish a formal change control system, including a
Change Control Board (CCB)
 Use good configuration management
 Define procedures for making timely decisions on
smaller changes
 Use written and oral performance reports to help
identify and manage change
 Use project management and other software to help
manage and communicate changes
1-77