MODULE 13 : A Portfolio Approach to IT Project Matakuliah

advertisement
Matakuliah
Tahun
Versi
: J0422 / Manajemen E-Corporation
: 2005
:1/2
MODULE 13 :
A Portfolio Approach to IT Project
1
Learning Outcomes
 In this chapter, we will study:
 The risk of implementation the project depends on project
size, Experience with Technology, and project structure.
 Implementation the project was using many management
tools to handle the IT integration.
 SDLC represents IT projects in a sequence of phases of
development of the project. The phases was consist of :
Analysis and design, Construction, Implementation,
Operation and maintenance.
 Process Formalization was using to do the minimalist
approach to IT development. There was three categories :
Flow, Completeness, and Visibility.
2
Outline Topic
 Source of Implementation Risk.
 Project Management : A Contingency Approach.
 Process Consistency and Agility in Project Management.
 A Minimalist Approach to Process Formalization.
3
Content
 Despite 40 years of accumulated experience in managing
information technology (IT) projects, the day of the big
disaster on a major IT project has not passed. Why? An
analysis of these examples and a preponderance of
research over the last 10 years suggest three serious
deficiencies that involve general and IT management:
 Failure to assess the implementation risk of a project at the
time it is funded
 Failure to consider the aggregate implementation risk of a
portfolio of projects
 Failure to recognize that different project require different
managerial approaches.
4
Source of Implementation Risk
 Project Size
 Experience with Technology
 Project Structure
5
Source of Implementation Risk
 Project feasibility studies typically provide estimates of
financial benefits, qualitative benefits, implementation
costs, targets milestone and completion dates, and
staffing levels. Ignoring project risk is a profound error with
significant consequences, such as the following:
 Failure to obtain anticipated benefits due to implementation
difficulties
 Higher than expected implementation costs
 Longer than expected implementation time
 Resulting systems whose technical performance is below
plans and requirements
 System incompatibility with selected hardware and software
6
Source of Implementation Risk
 Project Size
 The larger the project in monetary terms, staffing levels,
duration, and number of departments affected, the greater
the risk. Multimillion-dollar projects obviously carry more risk
than do $50,000 efforts and tend to affect the company more
if the risk is realized.
 Experience with the technology.
 Project risk increases when the project team and
organization are unfamiliar with the hardware, operating
systems, database systems, and other project technologies.
 Project structure
 The nature of the task fully and clearly defines project
outputs. From the project’s beginning throughout its duration,
outputs remain fixed.
7
Project Management: A Contingency Approach
 Management Tools
 Influences on Tool Selection
 Relative Contribution of Management Tools
 Emergence of Adaptive Project Management
Methods
 Software Development Life Cycles
 Adaptive Methodologies
 Adaptive Methods an Change Management
8
Project Management: A Contingency Approach
 Management Tools
 The general methods for managing projects are of four
principal types:
• External integration tools include organizational and other
communication devices that link the project team’s work to
users at both managerial and lower levels.
• Internal integration devices, which include various personnel
controls, ensure that the project team operates as an integrated
unit.
• Formal planning tools help structure the sequence of tasks in
advance and estimate the time, money, and technical
resources the team will need for executing them.
• Formal results-control mechanisms help managers evaluate
progress and spot potential discrepancies so that corrective
action can be taken. Results controls have been particularly
effective in project settings with the following characteristics:
– There is clear knowledge in advance of the desired results
– The individuals whose actions are influenced by the formal
mechanisms can control the desired result, at least to some extent
– Results can be measured effectively.
9
Project Management: A Contingency Approach
 Influences on Tool Selection
 Different project types call for the use of different
management tools. Tools fo each project type below:
• High-Structure/Low-Technology Projects
– High structured projects that present familiar technical problems
have the lowest risk and are the easiest to manage of the projects.
– High structure implies that the nature of the task defines its
outputs, the possibility of users changing their minds about the
desired outputs is practically nonexistent, and significant change
management issues are not present.
• High-Structure/High-Technology Projects
– Projects with high structure and high technology call for significant
elaboration on the practices outlined in most project management
handbooks.
– Converting a mainframe system to run on client-server
architecture is a good example of a high-structure/high-technology
project so long as the objective is replicating the same functions
on the new platform.
– Technical leadership and internal integration are the keys in this
type of project; external integration plays a distinctly secondary
role. Formal planning tools yield estimates that may contain major
inaccuracies, and great danger results when neither IT managers
nor high-level executives recognize this.
10
Project Management: A Contingency Approach
• Low-Structure/Low-Technology Projects
– When low-structure/low-technology projects are well managed,
they present low-risk profiles.
– Developing substantial user support for a system design and
keeping the users committed to that design are critical. Such
projects therefore benefit from the following:
» A user as project leader or as the number two person on the
team
» A user steering committee to evaluate the design periodically.
» Breaking the project into a sequence of small, discrete
subprojects.
» Formal user review and approval on all key project
specifications.
» Distributing minutes of all key design meetings to the users.
» Adhering, when possible, to all key subproject time
schedules. Low turnover among users is important here.
• Low-Structure/High-Technology Projects
– Projects in this category have outputs not clearly defined at the
project’s start. Such projects are also technically complex.
– Formal planning and results-control tools are useful here, in the
early stages they contribute little to reducing uncertainty or
highlighting problems. Planning tools do allow the manager to
structure the sequence of tasks.
11
Project Management: A Contingency Approach
 Relative Contribution on Management Tools
Project Project Description
Type
External
Integration
Internal
Integration
Formal
Planning
Formal Results
Control
I
High structure-low technology.
large
Low
Medium
High
High
II
High structure-low technology.
small
Low
Low
Medium
High
III
High structure-high technology.
large
Low
High
Medium
Medium
IV
High structure-high technology.
small
Low
High
Low
Low
V
Low structure-low technology.
large
High
Medium
High
High
VI
Low structure-low technology.
small
High
Low
Medium
High
VII
Low structure-high technology.
large
High
High
Low+
Low+
VIII
Low structure-high technology.
small
High
High
Low
Low
12
Project Management: A Contingency Approach
 Emergence of Adaptive Project Management Methods
 An emerging response to these conditions is adaptive methods:
approaches to design, deployment, implementation, and investment
that assume a need to gather information and to learn as one goes.
 Adaptive method require that project staff be able to experiment during
a project without incurring prohibitively high costs.
 Software Development Life Cycles
 Analysis and design
• The traditional process begins with a comprehensive analysis of
requirements, followed by documentation of the desired capabilities of the
system in a form that can be used by system developers to code and
implement the system.
 Construction
• Traditionally, construction was a highly specialized activity that combined
high levels of technological skill with a large dose of art, experience, and
logic.
 Implementation
• Implementing a new IT system involves extensive coordination between
the user and the technologist as the transition is made from the
predominantly technical IT-driven task of construction to user-driven
ongoing management of the completed system.
 Operation and maintenance
• To avoid ongoing problems, operation and maintenance are planned in
advance, ideally during the early stages of requirements definition and
design.
13
Project Management: A Contingency Approach
 Adaptive Methodologies
 Adaptive and prototyping intensive methodologies call for quickly
building a rough preliminary version of the system without going
through a lengthly or formal requirement definition and design.
 Adaptive projects are carried out in a variety of ways, they share five
basic characteristics:
• They are iterative. Design, construction, and implementation occur in small
increments that result from each iteration so that outcomes and
interactions be tested as they appear.
• They rely on fast cycles and require frequent delivery of value so that
incremental implementation does not slow down project.
• They emphasize early delivery to end users of functionality, however
limited, so that feedback can be incorporated into learning and
improvement cycles.
• They require skilled project staff capable of learning and making midcourse
adjustments in the middle of deployment.
• They often resist return on investment (ROI) and other similar tools for
investment decision making that implicitly assume predictability of
outcomes, instead emphasizing “buying of information” about outcomes as
a legitimate expenditure.
 Adaptive Methods and Change Management
 Adaptive projects achieve change management in part by intensely
involving users in evaluating the outcome of each development
iteration and deciding on the next enhancement to be introduced into14
the system.
Process Consistency and Agility in Project Management
 In practice, project management always involves balancing a
tension between process consistency and process agility.
 The tension arises from the fact that the tools used to improve
consistency – specifications, in the middle of a project if necessary,
when business condition require it.
 In the last decade many companies have struggled with this issue,
including many technology companies for which responsiveness to
market and time to market were over-riding concerns.
15
A Minimalist Approach to Process Formalization
 The companies that have been most successful in balancing
discipline and agility have neither eschewed process formalization
altogether nor let process formalization efforts overwhelm them.
These simple tools fall into three categories:
 Flow
 Completeness
 Visibility
16
Chapter Summary
 Firms will continue to experience major disappointments as they
push into new application areas and technologies.
 A firm’s IT development project in the aggregate represent a
portfolio.
 Project management in the IT field is complex and
multidimensional; different types of projects require different
clusters of management tools.
 Executives should consider the following questions as they
attempt to forecast the value of digital business strategies and the
ability of their organizations to execute them:
• Have you established risk assessment procedures to evaluate the
risk of individual projects ? Is such a procedure a standard part of
project approval and status reporting at the company?
• Do our project planning, tracking, and control processes account
adequately for differences in types of projects?
• Have we performed a risk analysis on our portfolio of application
projects?
• Are we exploring emerging project management methodologies to
determine their applicability to our business?
17
Download