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

Slides:



Advertisements
Similar presentations
1 Requirements and the Software Lifecycle The traditional software process models Waterfall model Spiral model The iterative approach Chapter 3.
Advertisements

The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 2- Software Process Models and Project.
Software Process Models
Software Process Models
W5HH Principle As applied to Software Projects
Systems Analysis and Design 9th Edition
Chapter 2.
Chapter 8 Information Systems Development & Acquisition
Chapter 8 Managing IT Project Delivery
Lecture 19 Chapter 10 A Portfolio Approach to Managing IT Projects.
IT Planning.
Fundamentals of Information Systems, Second Edition
1 MODULE 11 : Organizing and Leading the IT Function Matakuliah: J0422 / Manajemen E-Corporation Tahun: 2005 Versi: 1 / 2.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 5 Slide 1 Project management.
© 2008 by Prentice Hall 1 Chapter 2. © 2008 by Prentice Hall 2 Project – a planned undertaking of related activities to reach an objective that has a.
Pertemuan Matakuliah: A0214/Audit Sistem Informasi Tahun: 2007.
4. 2Object-Oriented Analysis and Design with the Unified Process Objectives  Explain the elements of project management and the responsibilities of a.
CHAPTER 9: LEARNING OUTCOMES
© 2005 Prentice Hall2-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
Project Management and MS Project. The project management triangle: Time Resources Scope.
4 4 By: A. Shukr, M. Alnouri. Many new project managers have trouble looking at the “big picture” and want to focus on too many details. Project managers.
Introduction to Systems Analysis and Design
Managing Projects
Project phases and the life cycle
Project Management and Scheduling
Acquiring Information Systems and Applications
Chapter 9. Intro  What is Project Management?  Project Manager  Project Failures & Successes Managing Projects  PMBOK  SDLC Core Process 1 – Project.
Don Cole Risk Assessment and Mitigation Project Management for ARA Engineers and Scientists.
Systems Analysis and Design: The Big Picture
Acquisitions, a Publisher’s Perspective Craig Duncan Development Manager External Development Studio Building the partnership between.
1COM6030 Systems Analysis and Design © University of Sheffield 2005 COM 6030 Software Analysis and Design Lecture 2- Software Process Models and Project.
1 IS 8950 Managing and Leading a Networked IT Organization.
1 Portfolio Management – Agile How to plan like a VP Highsmith, Ch 12 CSSE579 Session 6 Part 2 One company’s software product portfolio.
Chapter 2 The process Process, Methods, and Tools
Software Project Management Introduction to Project Management.
PROJECT RISK MANAGEMENT Presentation by: Jennifer Freeman & Carlee Rosenblatt
Adaptive Processes Project Management Body of Knowledge
Module CC3002 Post Implementation Issues Lecture for Week 1 AY 2013 Spring.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
A Portfolio Approach to IT Projects Chapter 10. Project Risk Consequences of Risk: –Failure to obtain all, or any, of the anticipated benefits because.
GBA IT Project Management Final Project - Establishment of a Project Management Management Office 10 July, 2003.
Chapter 5 : Initiating and Planning Systems Development Projects.
Lecture 19 Chapter 10 A Portfolio Approach to Managing IT Projects.
1 Software Process Models-ii Presented By; Mehwish Shafiq.
ISM 5316 Week 3 Learning Objectives You should be able to: u Define and list issues and steps in Project Integration u List and describe the components.
Chapter 11. Intro  What is Project Management?  Project Manager  Project Failures & Successes Managing Projects  PMBOK  SDLC Core Process 1 – Project.
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Copyright 2008  Project management process groups progress from initiating activities to planning activities, executing activities, monitoring and controlling.
Chapter 3 Project Management Chapter 3 Project Management Organising, planning and scheduling software projects.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Fundamentals of Information Systems, Second Edition 1 Systems Development.
1 - 1 Systems Analysis and Design, Key Ideas Many failed systems were abandoned because analysts tried to build wonderful systems without understanding.
CSPC 464 Fall 2014 Son Nguyen. 1. The Process of Software Architecting, Peter Eeles, Peter Cripss 2. Software Architecture for Developers, Simon Brown.
Unit – I Presentation. Unit – 1 (Introduction to Software Project management) Definition:-  Software project management is the art and science of planning.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Risk management. Definition and Aim  Risk management is examine systematically all risks and react on them, taking into account all the effects of.
Lecture 15 Chapter 8 Managing IT Project Delivery.
INTRODUCTION Mehmet Sait Andaç Web: Office: 431.
MIS Project Management Instructor: Sihem Smida Project Man agent 3Future Managers1.
CHAPTER 2 SYSTEM PLANNING DFC4013 System Analysis & Design.
Chapter 11 Project Management.
Introduction to Systems Analysis and Design
Project Management Process Groups
Tour VII: Change Management
CHAPTER 10 METHODOLOGIES FOR CUSTOM SOFTWARE DEVELOPMENT
Managing IT Project Delivery
Presentation transcript:

1 MODULE 13 : A Portfolio Approach to IT Project Matakuliah: J0422 / Manajemen E-Corporation Tahun: 2005 Versi: 1 / 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 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 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 Source of Implementation Risk  Project Size  Experience with Technology  Project Structure

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