Presentation is loading. Please wait.

Presentation is loading. Please wait.

1 MODULE 13 : A Portfolio Approach to IT Project Matakuliah: J0422 / Manajemen E-Corporation Tahun: 2005 Versi: 1 / 2.

Similar presentations


Presentation on theme: "1 MODULE 13 : A Portfolio Approach to IT Project Matakuliah: J0422 / Manajemen E-Corporation Tahun: 2005 Versi: 1 / 2."— Presentation transcript:

1 1 MODULE 13 : A Portfolio Approach to IT Project Matakuliah: J0422 / Manajemen E-Corporation Tahun: 2005 Versi: 1 / 2

2 2 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.

3 3 Outline Topic  Source of Implementation Risk.  Project Management : A Contingency Approach.  Process Consistency and Agility in Project Management.  A Minimalist Approach to Process Formalization.

4 4 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.

5 5 Source of Implementation Risk  Project Size  Experience with Technology  Project Structure

6 6 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

7 7 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.

8 8 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

9 9 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.

10 10 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.

11 11 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.

12 12 Project Management: A Contingency Approach  Relative Contribution on Management Tools Project Project Description External Internal Formal Formal Results Type Integration Integration Planning Control I High structure-low technology. LowMedium High High large II High structure-low technology. LowLow Medium High small III High structure-high technology. LowHigh Medium Medium large IV High structure-high technology. LowHigh Low Low small V Low structure-low technology. HighMedium High High large VI Low structure-low technology. HighLow Medium High small VII Low structure-high technology. HighHigh Low+ Low+ large VIII Low structure-high technology. HighHigh Low Low small

13 13 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.

14 14 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 into the system.

15 15 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.

16 16 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

17 17 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?


Download ppt "1 MODULE 13 : A Portfolio Approach to IT Project Matakuliah: J0422 / Manajemen E-Corporation Tahun: 2005 Versi: 1 / 2."

Similar presentations


Ads by Google