sistem informasi manajemen - it project

8/20/2019 Sistem Informasi Manajemen - IT Project

http://slidepdf.com/reader/full/sistem-informasi-manajemen-it-project 1/23

MANAGEMENT INFORMATION SYSTEM

RESUME CHAPTER 11:

IT PROJECT MANAGEMENT

GROUP 8

FACULTY OF ECONOMICS AND BUSINESS

SEBELAS MARET UNIVERSITY

2015



IT PROJECT MANAGEMENT

It management requires not only knowledge of system development methodologies such

as SDLC, prototyping, "agile" approaches and purchasing life cycle but also "best practices" for

managing proects! he #roect $anagement Institute %#$I&, an international society of proect

management professionals established in '()(, has developed a globally recogni*ed standard for

managing proects! here are nine knowledge areas certified by the #$I+

#roect scope #roect time #roect cost

uman resources -uality management .isk management

#roect communications #rocurement #roect integration

/ proect is a temporary endeavor undertaken to create a unique product or service! It

typically is a one time initiative that can be divided into related activities that require

coordination and control, with a definite beginning and ending!

#roect management is the application of knowledge, skills, tools, and techniques to a

broad range of activities in order to meet the requirements of a particular proect!

/ #rogram $anagement 0ffice %#$0& is an organi*ational unit with full time personnel

to provide a full range of standard approaches to proect management support and services that

are utili*ed across proect, lessons learned from each proect are collected from post proect

reviews and shared across proect managers!

IT PORTFOLIO MANAGEMENT

I portfolio management is typically the responsibility of a committee of senior business

leaders and I leaders who approve and prioriti*e I proect requests for an entire organi*ation

and then monitor progress on approved I proects until they are completed! /n organi*ation1s I

portfolio usually includes investments in new I applications as well as I infrastructure

investments %i!e!, networks, servers, storage equipment, data warehouses& to support these

applications! 2ew I proect requests are typicallu submitted using an organi*ation specific

template for a business case that captures the e3pected business benefits and both the initial

resources costs for maintaining the new system! /s part of the system prioriti*ation process, an

evaluative categori*ation scheme for all proects of a certain si*e is typically applied! 0ne such

scheme, would categori*e proects into four buckets+

• /bsolute $ust! / mandate due to security, legal, regulatory, or end of life cycle I issues!



• ighly Desire45usiness Critical! Include short term proects with good financial returns

and portions of very large proects already in progress!

• 6anted! 7aluable, but with longer time periods for returns on investment %more than a '8

month period&!

• 2ice to ave! #roects with good returns but with lower potential business value!

In most organi*ations proects in the top two categories would most likely be funded for the

budget year in which they were submitted!

PROJECT MANAGEMENT ROLES

9very I proect will have at least one formal I proect manager and one proect

sponsor! In addition to these two formal roles, many I proects also need a proect "champion"!

'! #roect $anager

/ systems proect is typically led by an I proect manger who has demonstrated

both technical and managerial skills! his manager is responsible for managing

relationships with the proect sponsor and other stakeholders, as well as initiating,

planning, e3ecuting, controlling, and closing a proect! he choice of the proect manager

depends not only on the degree to which the application proect will impact a specific

business unit or division but also on the degree to which the proect requires technical

e3pertise, both internal and e3ternal! he proect manager1s responsibilities in general are

to plan and e3ecute the proect, including controlling for proect risks and ensuring that

necessary business changes have been implemented! his requires several different types

of skills, including team management skills +

Leadership Skills+ Sets e3ample, energetic, vision, delegates, positive attitude!0rgani*ational Skills+ #lanning, goal:setting, analy*ing!

Communication Skills+ Listening, persuading!

eam:5uilding Skills+ 9mpathy, motivation, esprit de corps!

Coping Skills+ ;le3ibility, creativity, patience, persistence!

8! #roect Sponsor and Champion .oles

he proect sponsor role is typically played by a business manager who

financially "owns" the proect %i!e!, the person who "writes the check" for the proect&!

he sponsor oversees in the development of the initial proect proposal, including an

assessment of the feasibility of the proect! he sponsor also argues for the approval of



the systems proect before the committee members responsible for new system proect

approvals! 0nce the systems proect has been initiated, the proect sponsor provides the

funds for the proect and continues to play an oversight role during the life of the proect!

he sponsor also typically takes responsibility for ensuring that the most appropriate

business managers and other users are assigned to the proect team and that these proect

team members are empowered to make decisions for the business units they represent! In

addition, the sponsor is often relied on to ensure business personnel who are not formal

team members are made available as needed at certain points in the proect, such as

providing information about current work processes or procedures in the Definition

phase, evaluating screen designs from a user perspective early in a Construction phase,

performing system tests at the end of a Construction phase, or training other users during

an Implementation phase! 0nce the system proect has been completed, the sponsor

should also be held accountable for ensuring that the proected system benefits are

achieved after the system is installed!

he proect champion role is another role associated with successful I proects!

In essentially all situations, the champion role needs to be played by a business manager,

not an I manager, for the following reason+ / manager with high credibility among the

business users who will be impacted by the new system solution will be best able to

prepare workers for the process and workflow changes required! ;or some I proects,

the proect sponsor and the proect champion may even be the same business manager!

owever, for other proects in which the sponsor1s daily responsibilities are far removed

from the business activities to be affected by the new system, the champion role is better

played by a lower level business manager whose direct reports will be highly impacted by

the proect!

FIVE PROCESSES OF AN IT PROJECT MANAGEMENT ARE:

PROJECT INITIATION

he first phase of proect life cycle is the proect initiation phase in which the proect is

formally authori*ed and a determination is made as to whether the proect should actually

proceed or not! / key deliverable for this phase is a proect charter that states in some detail the



proect1s specific obectives, its intended scope, any underlying assumptions and known

constraints, and the estimated benefits based on the feasibility analysis step of the I proect!

he scoping of a proect involves setting boundaries for the proect1s si*e and the range of

business function or processes that will be involved! hree types of feasibility analyses are

typically conducted for systems proects as part of the Definition phase of a systems life cycle+

economic feasibility, operational feasibility, and technical feasibility!

he economic feasibility investigation usually involves a formal cost benefit analysis

based on the overall obectives and scope of the proect as well as an estimate of the proect

budget! ;or proects with benefits that are easily measured, on .0I will be easy to calculate!

owever, for proect that involve a business innovation, such as building a new organi*ational

capability, it is much more difficult to quantify the potential benefits! ;or these types of strategic

application proects, a technique such as rank:ordering the alternatives can be used to overcome

total reliance on .0I measure that could be very difficult to calculate!

.ank /lternatives 9ven if it is not possible to compute

e3plicit numerical values, it may be

possible to estimate with enough accuracy

to rank the alternatives!

Sensitivity /nalysis <se sensitivity analysis to deal with

uncertainties! If a precise value is not

known for a parameter, repeat the analysis

with alternative values!

Several other types of feasibility concerns can also be studied in order to better

understand the best way to manage a systems proect and its interdependencies, including

operational feasibility issues such as schedule feasibility, legal and contractual feasibility, and

political feasibility! Schedule feasibility takes into account the potential impact of e3ternally

imposed deadlines, such as the effective date of new federal regulation or a seasonal date of

importance for competing in a given industry! Legal dan contractual feasibility concerns mightneed to be investigated to understand the issues related to partnering with one or more I

vendors for delivering the product solution! #olitical feasibility involves an assessment of

support for the proposed system on behalf of key organi*ational stakeholder groups, which may

not have been captured as part of an operational feasibility study!



PROJECT PLANNING

he obective of the planning process is to ensure that the proect goals are achieved in

the most appropriate way! he three maor components of proect planning are proect

scheduling, budgeting, and staffing! hese components are obviously interrelated, and poor

planning for one component can severely affect another! /lthough we emphasi*e ne3t some

proven techniques for good proect planning and control, it should also be kept in mind that

e3perienced proect managers will tailor their approaches to match the special circumstances of a

given proect or organi*ational situation! =Scope creep> is often touted as a potential pitfall to

watch out for during proect planning! /ccording to .ussell %8??@&, =scope creep> only becomes

a problem when the proect manager and business stakeholders donAt agree that the scope has

been changed and the impacts of these changes arenAt formally and realistically accounted for in

the proect schedule, budget, and staffing!

Sche!"#$%

Developing a proect schedule typically involves a &'() *(e+)'&$ +$+",-#-+ identifying the

phases and sequence of tasks that need to be accomplished to meet the proect goalsBas well as

the goals for other organi*ational and e3ternal party obligationsBand then estimating the time of

completion for each task! ;or systems proects, the proect phases as well as the detailed

activities for each step and their sequence can typically be derived from the systems

methodology being used for the proect! ime estimates are typically based on the relevant past

e3periences of the organi*ation or the proect manager, or both! 0ther sources for time estimates

include benchmarking studies for similar proects in other organi*ations, activity estimates

embedded in software estimation packages, and proect databases of system consultants!

he detailed work activity list, the task interdependencies, and the time estimates for each task

are then used to develop a master schedule for the proect that identifies the .('/ec #"e-'$e

dates and deliverables! he level of detail provided in a master schedule depends upon proect

characteristics such as si*e, functional comple3ity, and task interdependencies, as well as

organi*ational practices!



he proect scheduling process is somewhat different when an organi*ation has adopted a

timebo3ing philosophy! he term #e*'#$% refers to an organi*ational practice in which a

system module is to be delivered to the user within a set time limit, such as si3 months! %his

technique is a characteristic of the rapid application development ./D methodology discussed

in Chapter (!& 5ecause the intent of timebo3ing is to deliver new I solutions as rapidly as

possible, a work plan might be designed in which a given module is initially implemented during

the timebo3 without full functionality, and then the functionality is increased in subsequent

releases!

/ common pitfall in developing a master schedule is a failure to understand the

interdependencies among proect tasks and subtasks! Including a customer verification step as

part of the master scheduling process can help identify misunderstandings at an early stage of the

proect planning cycle! /nother common pitfall is estimating task completion times based on a

level of e3pertise associated with an e3perienced worker, rather than the average worker

typically available in the organi*ation!

9ffective scheduling is critical to the proectAs success and is a key input to the proect budgeting

component! owever, the master schedule is also meant to be a living document! / good

planning process therefore also provides for change:control procedures to request schedule

changes! /side from a process to request the necessary management approvals, changes to the

master schedule should be documented with the date of the change, the nature and reason for the

change, and the estimated effects of the change on other proect components %e!g!, budget,

resource allocations& and related proect tasks!

B!%e#$%

he proect budget documents the anticipated costs for the total proect! hese costs are typically

aggregated into meaningful categories at the level at which the proect costs will be controlled!

here are two traditional approaches to estimating proect costs+ bottom:up and top:down! he

proect work plan from the scheduling process is typically used for a bottom: up process+ Cost

elements are estimated for the work plan tasks and then aggregated to provide a total cost



estimate for the proect! /ccording to ;rame %'((E&, a top:down approach =eschews> the cost

details and provides instead estimates for maor budget categories based on historical e3perience!

/ top:down approach %also called parametric cost estimating& could be used in the proect

initiation stage because not enough is known about the proect to do a work breakdown analysis!

owever, once a master schedule has been developed, a bottom:up process is recommended,

especially if the proect is large and comple3! hese two approaches can also be used as checks

for each other!

2o matter which approach is used, the budgeting process needs to build in cost estimates to

cover proect uncertainties associated with changing human resources, immovable proect

deadlines %that could require overtime labor&, as well as changes in technology and contract costs

outside the organi*ationAs control!

Like the master schedule, the proect budget is a living document of anticipated total costs! /

good planning process therefore also provides change:control procedures to request approvals

for deviations from an estimated budget! Changes to the budget should be documented with the

date of change, the nature and amount of the requested budget deviation, the reason for the

change, and the estimated effects of the change on other proect components %e!g!, scope,

schedule, resource allocations&!

/ccording to ;rame %'((E&, ine3perienced estimators typically fall into three estimation traps+

hey %'& are too optimistic about what is needed to do the ob, %8& tend to leave components out,

and %F& do not use a consistent methodology, so they have difficulty recreating their rationales!

Good training in how to estimate proect steps and organi*ational checklists of items to include

in estimates can help the amateur estimator quickly improve!

9ven for the e3perienced proect manager, cost estimations can be complicated by many types of

unknowns, including the lack of precedents, unpredictable technical problems, and shifting

business requirements! #roects that use standard and mature I components are the most likely

to have published estimates available from consultants or other third:party vendors and are

generally the easiest to estimate! 5oth budget padding and lowballing are apparently widely



used, but both of these techniques can also cause dysfunctional consequences %see the bo3

entitled =ighballing 7ersus Lowballing #roect Costs>&!

S+33#$%

#roect staffing involves identifying the I skill mi3 for specialists assigned to the proect,

selecting personnel who collectively have the skills needed and assigning them to the proect,

preparing team members for the specific proect work, and providing incentives for them to

achieve the proect goals!

In proect work, the human resources are a critical production factor! /s part of the proect

planning, the proect manager should be able to estimate the skill type, proficiency level,

quantity, and time frame for personnel to e3ecute each proect phase and critical task! Some

human resources need to be dedicated to the proect full:time, whereas others %e!g!, a database

administrator& will likely be shared with other

proect teams! Still others %e!g!, users who help test a system& might not be formal team members

but will be relied on for their e3pertise at critical points in the proect!

6herever possible, individual employees with the best qualifications for the proect work should

be selected! owever, in an organi*ational setting this is not always possible, due to the si*e and

talent of the specialist pool internal to the organi*ation! 5ecause of the diverse set of specialist

skills that might be needed across proects, it is not uncommon for at least a portion of the team

members to undergo speciali*ed training in anticipation of a proect! Some IS organi*ations use a

skill centers approach in which IS specialists belong to a ce$e( '3 ece""e$ce managed by a

coach who is responsible for developing talent and selecting personnel for proect assignments

based not only on the proectAs needs for specific skill sets but also on individual development

needs %Clark et al!, '((@&! In addition, personnel from a #$0 may be involved to help plan

communications with key stakeholders and other business employees, as well as to ensure that

the most current documents are available to all employees who need access to them!

;or systems proects, it is also not uncommon to hire outside contractors for proect work for

either quality or workload reasons! his is especially desirable if a distinct I specialty is



required for a single proect, but it does not make economic sense to develop and maintain these

speciali*ed resources in:house! It also might be impractical to use internal resources if a proect

requires a significant number of additional personnel for ust a short period of time! he

downside in these situations is that the company can become highly dependent on a talent base

that is temporary! In the late '((?s, many companies began to focus on decreasing dependence

on outside contractors by developing their own I specialist talent! 0ne way to do this is to build

in a requirement for =knowledge transfer> to internal employees from the outside consultants or

contractors as part of the e3ternal vendor contract!

/nother key aspect of systems proect team staffing is the selection of business personnel for the

proect team! 5usiness personnel with enough authority and credibility to work with both

business leaders and other business workers who will be using the new software need to be

selected with the help of the proect sponsor! he careful selection of business employees can

obviously be a critical step in the staffing process! IS specialists are dependent on business users

for their functional e3pertise %referred to as subect matter e3pertise, or S$9&! ;ormal

documented procedures are not always the way that work tasks actually get done, and the proect

team must also be able to elicit these differences from business users as part of the Definition

phase! ;urther, making maor changes in the ways that business personnel get their work done

can be a maor proect obective! Changes in business processes are most common when an

organi*ation is implementing a new software package without modifications %referred to as

=vanilla> implementations&, and the right business personnel need to be part of the proect team

to accomplish this obective! In addition, business personnel who are not formal team members

may have a role as =e3tended> team members to help with defining the systems requirements,

testing, and training over the life of the proect!

9ven after a well:managed selection process, there is sometimes a need for special team:building

e3ercises to build team spirit and to help team members who have not worked together before to

get to know each other quickly! he degree to which team building is needed will depend on the

characteristics of the proect, the prior e3periences of the team members, and the degree to which

the systems methodology or other proect practices will be new to the team members! eam:

building and fostering ongoing motivation for meeting the proect obectives are easiest when



team members are in the same physical location %colocated&, there is a stable roster of team

members, and the proect manager is able to manipulate the appropriate motivating factors! %See

the section =Special Issue+ $anaging 7irtual eams> at the end of this chapter!&

5ecause proect incentives can influence individual performance and productivity, proects that

require especially intense efforts, personal sacrifices %e!g!, postponed vacations&, and possibly

geographic relocation might also have attractive proect:based incentives to help ensure that the

proect goals are achieved! he dot:com I start:up culture within the <nited States in the late

'((?s epitomi*ed this highly intensive lifestyle for which stock options were the primary reward!

Similar motivators are sometimes needed for I proects with highly aggressive schedules in

order to meet proect deadlines! %<nlike a dot:com start:up, however, the duration of the proect

is usually known and the rewards can be more certain!& ;or e3ample, key proect team members

on multiyear enterprise implementation proects could be asked to make commitments to the

proect in return for special proect completion bonuses or even stock options! %See the bo3

entitled =#roect Completion Incentives when the Stakes /re igh >& 6hen designing incentives,

it should also be kept in mind that an individualAs response to a particular incentive can vary over

time due to changing personal needs %e!g!, family pressures for work:life balance&!

P"+$$#$% D'c!e$-

wo documents are typically created from the proect planning phase+ a -+ee$ '3 &'()

4SO6 for the customer and a proect plan to be used by the proect manager to guide, monitor,

and control the e3ecution of the proect plan!

he S06 document is a high:level document that describes what the proect will deliver and

when! It is in effect a contract between the proect manager and the e3ecutive sponsor! It

therefore can be used as a high:level guide for business managers to plan for their own unit

implementation as well as to monitor the proectAs progress toward the proect goals of on:time

completion within budget!

/ll program managers or committees that oversee the proect typically review the proect plan!

;or e3ample, a program manager and other I proect managers may initially review the proect



plan, and then a proect oversight committee of business managers and IS leaders may be asked

to endorse it!

wo types of proect management charts are also typically developed during the planning phase

and used during proect e3ecution+ %'& #9. or C#$ charts and %8& Gantt charts! hese are two

complementary techniques for proect scheduling and resource planning, as described ne3t!

/ #9. chart %a #rogram 9valuation and .eview echnique developed for a missile4submarine

proect in '(H& graphically models the sequence of proect tasks and their interrelationships

using a flowchart diagram! /n alternative method called C#$ %Critical #ath $ethod& was

developed by Du#ont about the same time! /s shown in ;igure ''!), each maor task is

represented as a symbol %here circles&, arrows are used to show predecessor and successor tasks,

and the time period to accomplish each task %here in days&! 5y e3amining these dependencies %or

critical paths&, the sequence of activities that will take the longest to complete can be calculated

%here the path at the top, '( days&! /ny delays in completing the activities on this critical path

will result in slippage on the proect schedule! .esearchers have found that proects in which

C#$ or #9. techniques are used are less likely to have cost and schedule overruns %$eredith

and $antel, '((&!

/ Gantt chart graphically depicts the estimated times %and later, the actual times& for each proect

task against a hori*ontal timescale! asks are presented in a logical order along with a bar graph

depicting the estimated time duration for each task on an appropriate linear calendar %i!e!,

minutes, hours, days, or weeks& for the number of months and years planned for the life cycle of

the proect %see ;igure ''!@&! he precedence relationships in the #9.4C#$ chart are reflected

in the start and end dates of the activities, and overlapping tasks can be easily seen! Gantt charts

are therefore particularly useful for displaying a proect schedule and for tracking the progress of

a set of tasks against the proect plan %as discussed in the =#roect 93ecution and Control>

section ne3t&! /n important proect management skill is to determine at what level of detail to

plan the proect tasks! oo much detail can be stifling and result in too much time being spent on

tracking rather than on more critical proect tasks! oo little detail can result in inadequate

proect management controls and both missed deadlines and cost overruns!



P('/ec Eec!#'$ +$ C'$('"

he documents described in the #lanning section are best recogni*ed as living documents that

need to be refined and reassessed throughout the life of the proect! he obective of the

e3ecution process is to effectively coordinate all resources as the project plan is carried out!

$easuring variances from what was planned versus what progress is actually achieved is part of

the controlling process!

In large, comple3 proects, the planning activities still continue after a proect team has been

selected and some initial tasks have been undertaken, and the revised plan goes through the same

endorsement procedures a few months into the proect, as described previously!

/lthough proects vary by si*e, scope, time duration, and uniqueness, most proects share the

three following life:cycle characteristics %#$I, 8??E&+

'! .isk and uncertainty are highest at the start of the proect!

8! he ability of the proect stakeholders to influence the outcome is highest at the start of

the proect!

F! Cost and staffing levels are lower at the start of the proect and higher toward the end!

#roect management software tools are used to plan and visuali*e proect tasks across the entire

proect management life cycle! $icrosoft #roect is the most commonly used general purpose

software, but more than '?? such products are available today, including hosted 6eb:based

applications! In some cases an organi*ation develops its own proect management tools, or a

consulting firm might provide such a system! 0ur focus here is not on the software tools used,

but on three general proect management practices+ communication, coordination, and measuring

progress!

Communication about the proect to all affected stakeholders and potential users is key to

successful implementation for systems proects in particular! ;or large proects with maor

business impacts, a proect =kickoff> event is frequently scheduled at which the proectAs sponsor



or champion e3plicitly communicates the proect obectives and perhaps also presents some

general ground rules for proect team members to make decisions on behalf of their constituents!

It is the proect managerAs responsibility to have an e3ternal communications plan appropriate for

the proect! his includes formally communicating the proect status on a regular basis %typically

weekly or monthly& to any oversight groups, all key stakeholders, and the user community that

will be affected by the proect! <sing the planning charts mentioned earlier, variances from the

forecasted proect budget and proect milestones can be reported in a way that highlights

deviations from the proect plan and their causes %see ;igure ''!&! 6hen outside consultants are

used, the tracking of consultant costs and utili*ation is also a key proect manager responsibility!

he usage of templates for proect:related communications also contribute to productivity! ;or

e3ample, some organi*ations have also adopted a red:yellow:green %or red:amber:green, ./G&

traffic light approach to signal what is =on track,> potential problem areas, and proect problems

to business oversight groups+

• Green indicates a proect is on track

• Jellow flags potential problems

• .ed means a proect is behind

his type of high:level approach helps ensure that business managers focus on corrective actions

to avoid a bottleneck, or consider maor revisions to the proect plan, to better manage proect

risks!

Successful e3ecution and control also include a process for documenting and approving %or

denying& requests for proect changes! ;igure ''!( is an e3ample of a form that can be used as

part of the change control process!



.ecent research also suggests that all I proects e3perience fluctuations in momentum, both

positive and negative! I proect managers who take steps to proactively stabili*e or counteract

negative spirals in momentum are therefore more likely to lead proects to a successful

completion %2elson and Kansen, 8??(&!

Good communications among the proect team members are also critical for task coordination

and integration! he mechanisms here include both formal activities %e!g!, weekly meetings of

team leaders& and informal %e!g!, e:mail communications and in:the:hall progress reporting&!

.ecently researchers %appelman et al!, 8??)& have provided evidence that potential proect

failures can be avoided if proect managers and team members pay attention to =early warning

signs> of people:related and process:related issues and then take appropriate actions to mitigate

these risks! Some of the people:related early warning signs are+

• Inadequate business stakeholder involvement or participation in the proect

• Subect matter e3perts %S$9s& in the business are overscheduled

Some process:related signs are+

• / lack of documentation of the success criteria for the proect %e!g!, budget, timeline,

high:level system requirements& as well as the e3pected future benefits %the business

case&• eam members have been re:assigned to a higher priority proect

M+$+%#$% P('/ec R#-)-

/ll proects carry some risks, and one of the goals of proect management is to reduce the risk of

failing to achieve the proectAs obectives! Standard risk management practices include+

identification and classification of proect risks, planning how to avoid them, and establishing

plans to otherwise detect, mitigate, and recover from problems if they occur %see the summary in

;igure ''!'?&! he e3tent of risk e3posure for approved proects can vary widely across proects

as well as across organi*ations! he culture of an organi*ation can lead some managers to take a

more defensive approach overall, while managers in a different organi*ation might purposely

pursue high:risk proects because of the potential for higher competitive rewards!



.isk identification should be undertaken at the proectAs outset, based on e3perience with similar

proects! / common risk management approach is to develop a list of risk factors and then to

weight them according to their potential impact! Identified risks are typically classified on

several dimensions, including the nature and cause, the likelihood of occurrence, and the

potential consequences! .isks can be due to a variety of causes, including characteristics of the

proect itself %i!e!, proect si*e, availability of business e3perts, newness of the technologies to be

utili*ed&, as well as characteristics of the e3ternal environment

%i!e!, competitive risk for not completing a proect, e3traordinary economic events&!

he risk assessment for a given proect is then used for decisions about proect staffing or

technical platform alternatives that lower the total risks, beginning with the planning stage! /

potentially serious risk should be addressed by detailed plans and dedicated tasks! Some

e3amples of common strategies for resource decisions are shown in ;igure ''!''! ;or e3ample,

an e3change strategy could result in subcontracting with vendors, and a reduction strategy could

result in allocating the =best and brightest> to a proect team to minimi*e the potential for failure!

Sometimes the proect budget includes monetary resources allocated to a contingency fund that

can be used at the discretion of proect team members to resolve anticipated thorny problems that

cannot be specifically defined at the outset of the proect!

he highest level of proect risk typically occurs at the proectAs outset! 0nce the proect is

underway and the team members learn more about a business unitAs needs, a new technology, or

a vendorAs software package, the proect risks will typically decrease! /fter more resources have

been invested, the organi*ationAs stake in the proect also increases and thus its risk e3posure also

increases+ $ore will be lost if things go wrong! Good risk management depends on accurate and

timely information on proect characteristics that managers view as likely indicators of risk

%amilton, 8???&! Deviations from e3pectations need to be clearly highlighted, and this

information needs to reach the right people at the right time in order for further investigation and

corrective actions to be taken! 0ne of the maor pitfalls in monitoring the risks of proects that

are already underway is to ignore negative feedback+ #roect managers need to be careful not to

=turn a deaf ear> to bad news or to downplay symptoms of what could be maor problems %eil



and .obey, '(((&! /n outside consultant may be needed to evaluate a troubled proect and to

help devise alternative courses of action!

M+$+%#$% B!-#$e-- Ch+$%e

6hen new systems are implemented, they typically involve maor changes in business processes,

which in turn require changes in the way employees do their work and information flows into

and out of their work activities! Ch+$%e +$+%ee$, or the ability to successfully introduce

change to individuals and organi*ational units, is therefore key to successfully implementing a

new system!

6hen a new information system will affect organi*ational power structures, strategies and tactics

to deal with these political aspects of the proect need to be e3plicitly developed! /ccording to

$arkus %'(F&, the sources for resistance to the implementation of a new information system can

often be anticipated by comparing the distribution of power implied by the new system and the

distribution of power e3isting in the organi*ation prior to the new system! ;aced with potential

shifts in organi*ational responsibilities, key stakeholders could consciously, or unconsciously,

employ counterimplementation tactics that result in preventing or delaying the completion of a

new system or in modifying its initial requirements! 93amples of e3plicit or implicit resistance

tactics include+

• withholding the people resources needed for a task %including designating a

representative who is not qualified to make the decisions needed&

• raising new obections about the proect requirements, resulting in schedule delays

• e3panding the si*e and comple3ity of the proect %rescoping&

.ecogni*ing from the beginning of a proect the potential political implications and then

devising solutions to avoid them is usually more effective than overtly trying to overcome

resistance tactics! Devising system solutions that will be viewed as desirable by all stakeholders

is of course an ideal outcome! 0ne key way to achieve this type of win:win situation is to

involve potential obectors in the implementation process so that they participate in negotiating

the requirements as well as the implementation schedule



for a new system! owever, it should also be kept in mind that sometimes resistance also can

occur postimplementation not only at the individual level but also at a department level

%Lapointe and .ivard, 8??H&!

/s business managers have come to recogni*e the importance of change:management practices

in general, researchers have proposed multistage models for managing changes in organi*ations!

$ost of these change models have their roots in a simple three:stage model %originally proposed

by Le&#$7Sche#$6 as described below!

1 U$3(ee9#$% -+%e+ hose individuals who will be significantly affected by the new system

must embrace the need for this change! o help motivate them, a work environment in which it is

=safe to

change> needs to be created! hat is, individuals who need to change have to be convinced that

giving up the old ways of doing things will not personally disadvantage them!

2 M'#$% -+%e+ Change requires knowledge transfer and training! <ntil the knowledge and

skills required for the new roles are acquired, change cannot take place! Information about

changes in work tasks needs to be assimilated, and adequate time needs to be allocated for the

people to learn these new skills and behaviors!

4. Re3(ee9#$% -+%e+ he new behavior becomes the accepted way of doing things! 2ew

incentive systems could be needed to reinforce the new behaviors, and the change might

not be routini*ed until new informal norms have also been adopted within relevant

workgroups across an enterprise! odayAs common wisdom is that modern organi*ations

and their people need to be able to accept change easily! his suggests that one of the new

behaviors to instill in an organi*ation after a maor change initiative is for an

organi*ationAs employees to become =change:ready> %Clark et al!, '((@&+ Change:ready

personnel view change as a desirable, ongoing state for competing in todayAs business

world! If this occurs, the <nfree*ing stage should become less difficult to move through

for future proects involving a lot of workplace change!



ased on a study of successful and failed efforts to transform an organi*ation, otter %'((H& has

proposed an eight:step framework for leaders of maor organi*ational change efforts+

'! 9stablish a sense of urgency

8! ;orm a powerful guiding coalition

F! Create a vision

E! Communicate the vision

hese four steps help bring an organi*ation through the $oving stage %described earlier& by

establishing a sense of urgency for the change and both creating and communicating a vision to

help direct the change effort!

'! 9mpower others to act on the vision

8! #lan for and create short:term wins

F! Consolidate improvements and produce still more change

E! Institutionali*e new approaches

If a new system is first piloted, or implemented in stages, the choice of the pilot or first business

unit to implement the system are very important choices for creating early =wins!> /ccording to

otter, the th step will only occur if the change becomes rooted in the organi*ationAs norms and

values, and this clearly requires top management support!

otter and other change:management researchers have recently emphasi*ed that maor

organi*ational change efforts cannot be entirely planned in advance! Instead, change efforts

should be e3pected to be somewhat =messy> and =full of surprises> %otter, '((H&! / successful

changemanagement effort therefore requires both planned %preplanned& activities as well as

=improvisational> responses to unforeseen circumstances %0rlikowski and ofman, '((@&!

Similar to risk management, then, a maor systems proect trap is to ignore negative feedback!

#aying careful attention to those in the organi*ation who are closest to the people who will be

affected by the systems proect will help avoid implementation failure!

hree maor categories of change:managementactivities have been associated with successful I



proects+ communicating, training, and providing incentives! Communication activities are part

of good proect management, and communicating the need for change %the vision& is one of the

first activities that needs to be addressed! he second category, training, is part of the installation

step in a systems life:cycle implementation phase! /ccording to the practitioner press, however,

the amount of user training required for an initial implementation success is typically

underestimated! he third category, incentive system changes %e!g!, performance rewards&, helps

motivate the attitudes and behaviors needed for the Lewin4Schein moving stage and helps

institutionali*e the behaviors for a .efree*ing stage! Special proect incentives may be used for

high:risk proects and be under the control of the proect manager%s&! owever, long:term

incentive schemes to influence behavioral changes are clearly beyond the scope of a single

proect!

In many situations, the budget for an I proect does not include change:management activities!

2ot allocating sufficient resources for managing business change when the implementation of an

I proect includes maor changes in business processes can be a maor barrier to implementation

success %5rown and 7essey, 8??F&! In organi*ations with a #$0 %or proect office&, specific

activities to ensure =change:readiness> are more likely to be a part of the proect plan! hese

include formal assessments of the proectAs impacts on different types of ob positions! 5ased on

the level of these impacts, resources are then allocated for training workers! his type of

approach was taken by $otorola %in their Semiconductor #roducts sector& in preparation for a

maor 9.# release that affected H,@?? employees worldwide! <nder the leadership of their

change:readiness unit, individual workers were assigned to instructor:led, train:thetrainer: led, or

computer:based training depending on the anticipated impacts of the new system on the

individualAs ob role %.oberts et al!, 8??F&!

SPESIAL ISSUE: MANAGING COMPLE; IT PROJECT

93perienced I proect managers or I program managers are increasingly likely to be asked to

lead large, comple3 systems proects across an enterprise, such as 9.# package implementations!

Consulting firms are also frequently contracted to help with these comple3 proects because of

their e3periences in implementing the same package in other organi*ations! #roect comple3ity

therefore needs to be recogni*ed as a key characteristic of many systems development and



implementation proects in todayAs digital world! / multiyear field review of how large, comple3

proects were implemented led to the identification of three high:level factors that are critical to

success %.yan, 8??F&+

'! he business vision was an integral part of the proect!

8! / testing approach was used at the program level %not ust at the individual application

level&!

F! he proects used a phased:release approach %rather than a single:release rollout

strategy&!

SPESIAL ISSUE: ANAGING VIRTUAL TEAMS

#roect teams with members working at different locations within the same company have

become increasingly common as distributed tools have facilitated working across national and

organi*ational

boundaries! hese so:called =virtual teams> in which team members are not colocated and cannot

regularly meet face:to:face are often formed to take advantage of unique skill sets or knowledge

not available at a single geographic location!



Figure: Project Management Complexity Increases with Off-site and Offshore Resources

!ased on Poria" #$$%&

sistem informasi manajemen - it project

Documents