a portfolio approach in it

7/30/2019 A Portfolio Approach in IT

1/35

Source: Applegate: Corporate

Information Strategy and

Management, Sixth Edition

Emelyn Grace A. ChavezMaster of Technology

Batangas State University


2/35

To enable a company to track the informationnecessary to maximize the value Managing the costs and risks

Most effectively make use of all resourcesavailable

Balance IT services and resources with demand for ITreserves and resources

Drive higher project success rates by tracking andreporting on progress


3/35

IT portfolio management is the application ofsystematic management to large classes ofitems managed by enterprise Information

Technology (IT) capabilities. Examples of IT portfolios would be planned

initiatives, projects, and ongoing IT services(such as application support).


4/35

Despite 40 years of accumulated experience inmanaging information technology (IT) projects, theday of the big disaster on a major IT project has not

passed. Why? An analysis of these examples and apreponderance of research over the last 10 yearssuggest three serious deficiencies that involvegeneral and IT management:

(1) failure to assess the implementation risk ofa project at the time it is funded,


5/35

(2) failure to consider the aggregateimplementation risk of a portfolio of projects,

and (3) failure to recognize that different projects

require different managerial approaches. In this chapter we examine the sources of

implementation risk and suggest strategiesfor managing and mitigating it.


6/35

In discussing implementation risk, we assumethat IT managers have brought appropriatemethods and tools to bear on a project.

Implementation risk, as we define it here, iswhat remains after the application of the propermethods and tools.

While mismanagement is another source of risk,

it is not included in our notion of implementationrisk because it is not inherent in the nature of aproject.


7/35

Ignoring project risk is a profound errorwith significant consequences, such as thefollowing:

Failure to obtain anticipated benefits due toimplementation difficulties

Higher than expected implementation costs Longer than expected implementation time

Resulting systems whose technical performance isbelow plans and requirements

System incompatibility with selected hardware andsoftware


8/35

Three important project dimensions influence inherentimplementation risk:

Project size. The larger the project in monetary terms,

staffing levels, duration, and number of departmentsaffected, the greater the risk. Multimillion-dollar projectsobviously carry more risk than do $50,000 efforts and tend toaffect the company more if the risk is realized. Project sizerelative to the normal size of an IT development group'sprojects is also important.


9/35

Experience with the technology. Project riskincreases when the project team and organizationare unfamiliar with the hardware, operating

systems, database systems, and other projecttechnologies.


10/35

Project structure. In some projects, which weterm high structure, the nature of the task fullyand clearly defines project outputs. From the

project s beginning throughout its duration,outputs remain fixed. Inherent stablerequirements make these projects easier tomanage.


11/35

Project Categories and Degree of Risk


12/35

Project Categories and Degree of Risk


13/35

Managers should not con-sider risk unalterable;instead, its presence should encourage betterapproaches to project management. Questions 5

and 6 in the "Structure Risk Assessment" sectionare good examples of questions that could triggerchanges.

The higher the assessment score, the greater the

need for very senior approval. In the company thatdeveloped this questionnaire, only the executivecommittee can approve projects with very highscores.


14/35

Managers should ask themselves thefollowing questions: 1. Are the benefits great enough to offset the

risks? 2. Can the affected parts of the organization

survive if the project fails?

3. Have the planners considered appropriatealternatives?


15/35

In addition to determining relative risk for singleprojects, a company should develop a profile ofaggregate implementation risk for its portfolio of systemsprojects.

Different portfolio risk profiles are appropriate todifferent companies and strategies.

For example, in an industry where IT is strategic(such as retailing or catalog sales), managers should

be concerned if there are no high-risk projects in theproject portfolio. Such a cautious stance may opena product or service gap through which thecompetition may seize advantage.


16/35

A portfolio loaded with high-risk projects, however,suggests that the company may be vulnerable tooperational disruptions if projects are notcompleted as planned.

Referring back to the strategic grid discussed inearlier chapters, for "support" companies,heavy investment in high- risk projects may notbe appropriate; they should not be taking strategicgambles in the IT arena.

Yet even these companies should have sometechnologically challenging ventures to ensurefamiliarity with leading-edge technology andmaintain staff morale and interest.


17/35


18/35

Conventional wisdom and much of the literatureon how to manage projects suggest that there isa single right approach to project management.

The implication of this way of thinking is thatmanagers should apply the same tools, projectmanagement methods, and organizationallinkages to all such efforts. We disagree.


19/35

Although there may indeed be a set of general-purpose tools that can be used in managing ITimplementation (we describe some later), the

contribution each makes to project planning andcontrol varies widely according to the project'scharacteristics.

Further, the means of involving the user-through

steering committees, representation on the team,or as a team leader-should also vary by projecttype; in short, there is no universally correct wayto run all projects.


20/35

The general methods (tools) for managing projects are of fourprincipal types:

External integration tools include organizational and othercommunication 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 anintegrated unit.

Formal planning tools help structure the sequence of tasks inadvance and estimate the time, money, and technicalresources the team will need for executing them.


21/35

Formal results-control mechanisms help managersevaluate progress and spot potential discrepanciesso that corrective action can be taken.

Results controls have been particularly effective inproject settings with the following characteristics: 1. There is clear knowledge in advance of the desired

results. 2. The individuals whose actions are influenced by the

formal mechanisms can control the desired result, at leastto some extent.

3. Results can be measured effectively.


22/35


23/35

When low-structure/low-technology projectsare well managed, they present low-risk profles.

Indeed, the key to operating this kind of projectlies in effective efforts to involve the users indesign, development, and implementation

Developing substantial user support for a system

design and keeping the users com- mitted to thatdesign are critical


24/35

. Such projects therefore benefit from the following: 1. A user as project leader or as the number two person on the team.

2. A user steering committee to evaluate the design periodically.

3. Breaking the project into a sequence of small, discrete subprojects.

4. Formal user review and approval on all key project specifications.

5. Distributing minutes of all key design meetings to the users.

6. Adhering, when possible, to all key subproject time schedules.Low turnover among users is important here; a consensus reachedwith a user manager's predecessor is of dubious value.


25/35


26/35

1. Analysis and Design

- Traditional Process begins with a comprehensiveanalysis of requirements, followed by thedocumentation of the desired capabilities of thesystem in a form that can be used by systemdevelopers to code and implement the system.


27/35

2. Construction

-Traditionally, construction was a highly specializedactivity that combined high levels of technological skillwith a large dose of art, experience and logic.

-Today, system construction involves selecting

appropriate computer equipment and then creating,buying, and adapting the computer programs neededto meet systems requirements.

Software Development Life Cycles


28/35

3. Implementation-Implementing a new IT system involves extensivecoordination between the user and the technologistas the transition is made from predominantly

technical IT-driven task of construction to user-driven on-going management of the completedsystem.

4.Operation and Maintenance- To avoid on going problems, operation andmaintenance are planned in advance, ideally duringthe early stages of requirements definition and design.

Software Development Life Cycles


29/35

Five Basic Characteristics1. They are iterative2. They rely on fast cycles and require

frequent delivery of value.3. They emphasis early delivery to end users

of functionality.4. They require skilled project staff.5. They open resist ROI.

Adaptive Methodologies


30/35

Examples:1. Cisco rapid, iterative prototyping2. Tektronix 20 waves project3. Extreme programming (or XP)4. Adaptive software development

In essence, Adaptive Approach is to createsomething that works roughly as quickly as

possible, begin to experience unexpectedeffects as soon as possible

Adaptive Methodologies


31/35

Adaptive Methodologies and ChangeManagement

-Adaptive projects achieve changemanagementin part by intensely involving user

in evaluating the outcome of each developmentiteration and deciding on the next enhancementto be introduced into system.

-Adaptive methods are an emerging responseto outcome uncertainty in system development.


32/35

Adaptive Methodologies and ChangeManagement

-The essence of sound change management isto strictly control the migration of system

features from development, through testing intoproduction with a clear understanding of thebenefits and potential for unanticipatedproblems at each stage.


33/35

Process Consistencyand Agility in Project Management

Three Categories of simple management tool

1. Flow can be simple depictions of the

process context that are intended to givedecision makers at specific points in theprocess a sense of overall businesspractice.

2. Completeness can be a simple lists toconvey what is needs to be done, when itneeds to be done, by whom, and whether itis complete.


34/35

Process Consistency and Agility inProject Management

Three Categories of simple management tool

3. Visibility to meet the peoples need to beable to review processes while they arebeing executed to get status information.

> In addition, another category can be added:

>Tools to ensure that project activities areauditable.


35/35

End

a portfolio approach in it

Documents